Subject: Re: RSVP-TE and PW

From: Tony Li <[email-masked]>
Date: Fri, 1 Oct 2004 12:56:07 -0700

Hi Peter,

Following this logic, there are many other LSPs in the network other 
than just PW's.  For example, one might have
a number of TE LSPs also containing best effort traffic, or a number of 
VPN LSPs.  In the scale of network that
you describe, it seems likely that these might well be encapsulated in 
trunk LSPs.  As you note, these trunk
LSPs may well need to be re-multiplexed, which seems quite reasonable 
to me, as I've already seen this done.

In such an environment, there is necessarily a considerable amount of 
TE going on, just because of the mismatch
between the physical plant and the demand matrix.  For the scalability 
of management, wouldn't it be better to
allow the TE layer of the network to perform its functions and not try 
to meld that functionality into the
PW layer?  After all, without the global knowledge of the traffic 
matrix, PW is not likely to achieve an
optimal (or even acceptable) solution, and it would effectively combat 
the TE layer.

Regards,
Tony

On Oct 1, 2004, at 7:46 AM, Busschbach, Peter B (Peter) wrote:

> To answer the question: what problem would RSVP-TE solve:
>
> In the current PWE3 architecture, PEs multiplex multiple PWs onto a 
> PSN tunnel that extends from the ingress PE to the egress PE.
>
> With growing MPLS deployment, it is conceivable that there is not 
> always an end-to-end PSN tunnel between two PEs and that there is a 
> need to "re-multiplex": take PWs out of one tunnel and map them onto 
> another. In fact, I think it is more than conceivable. It is very 
> likely. Service Providers grow through mergers and acquisitions and 
> will have to interconnect independent MPLS islands. And within one 
> network, MPLS will extend  further and further to the edge of the 
> network.
>
> The notion of re-multiplexing PWs is not new. E.g. section 3.5 of 
> draft-ietf-l2vpn-signaling-02.txt shows an achitecture in which it 
> occurs. However, the section leaves big questions about the 
> appropriate control infrastructure to manage this architecture. The 
> text under the figure in 3.5 suggests extensive use of maual 
> provisioning or the use of some undefined discovery protocol. 
> Similarly, another draft that addresses this issue 
> (draft-martini-pwe3-pw-switching-00.txt), strongly suggests that 
> intermediate switching nodes are manually provisioned.
>
> The problem with manual provisioning is that it impacts resiliency. If 
> one intermediate node goes down, it would be good if PWs could be 
> rapidly established via a different route. Also, there are cases in 
> which PW set up needs to be fully automatic. E.g. there are cases in 
> which signaling messages in the client layer (e.g. PNNI messages in 
> the case of ATM) trigger PW setup and the end-to-end connection setup 
> needs to happen without operator interference.
>
> These considerations suggest that it would be helpful to have a PW 
> setup mechanism that allows the ingress node to select a path through 
> one or more intermediate PW Switching nodes to the egress PE and use a 
> single-sided signaling mechanism to establish the PW along that path. 
> One solution would be to use a signaling protocol that carries some 
> kind of Explicit Route Object.
>
> In earlier emails, it was observed that certain application require 
> the PW setup protocol to carry QoS objects.
>
> This brings us to the rationale for RSVP-TE. If you need a protocol 
> that carries an ERO and QoS objects, RSVP-TE is the obvious choice.
>
> Is it absolutely clear that we need RSVP-TE? No. We are at the very 
> beginning of the deployment of PWE. We have little idea how MPLS 
> networks will be deployed five years from now.
>
> With regards to PW Switching, one of the big questions we are 
> struggling with is whether PW Switching is only required at the edge 
> of Autonomous Systems. If that would be the case, RSVP-TE may have 
> little benefit and a combination of BGP and LDP would probably be a 
> better solutions. However, if PW Switching nodes would be required 
> within ASs, RSVP-TE seems to offer a straightforward solution.
>
> Considering this uncertainty, I would echo Richard's request: "I would 
> like to see the RSVP-TE PW signalling approach remain on the table and 
> not be rejected at this time."
>
>
> One last note: I am somewhat surprised by references to RSVP 
> performance problems. I don't think the problem is RSVP. By 
> definition, there are scaleability concerns about PW Switching. PWE 
> introduces large numbers of fine-grained "connections". Any PW 
> Switching solution would have to deal with that. Whether you use LDP 
> or RSVP should not matter. (I assume that the people who decided that 
> CR-LDP should be retired in favor of RSVP-TE were convinced that the 
> two solutions scaled equally well to large numbers of connections.)
>
> Peter
>
>> -----Original Message-----
>> From: Stewart Bryant [mailto:[email-masked]]
>> Sent: Friday, October 01, 2004 2:56 AM
>> To: Sasha Vainshtein
>> Cc: [email-masked]; [email-masked]; [email-masked]'
>> Subject: Re: [PWE3] RSVP-TE and PW
>>
>>
>> Sasha Vainshtein wrote:
>>
>> <snip>
>>
>>> IMHO,if you want to push forward RSVP-TE as one of the PW signaling
>>> protocols, you should first define the problem that this
>> method addresses
>>> and which is not natively addressed by the existing
>> LDP-based protocol.
>>>
>>>
>> This is the key issue here.
>>
>> - Stewart
>>
>>
>> _______________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pwe3
>>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Eric Rosen <[email-masked]>
Date: Mon, 04 Oct 2004 13:40:42 -0400

Peter> If one intermediate node goes down,  it would be good if PWs could be
Peter> rapidly established via  a different route. Also, there  are cases in
Peter> which PW set up needs to  be fully automatic. E.g. there are cases in
Peter> which signaling messages  in the client layer (e.g.  PNNI messages in
Peter> the case of ATM) trigger PW setup and the end-to-end connection setup
Peter> needs to happen without operator interference.  

So far, so good.

Peter> These considerations  suggest that it would  be helpful to  have a PW
Peter> setup mechanism that allows the ingress node to select a path through
Peter> one or more intermediate PW Switching  nodes to the egress PE and use
Peter> a  single-sided signaling mechanism  to establish  the PW  along that
Peter> path

These considerations  suggest that  a PW switching  point should be  able to
dynamically determine the  next PW switching point.  I  don't see how you've
drawn any conclusion  about the need for carrying an  explicit path from the
ingress.   In  general,  if  you  want  routing  to  failed  paths  repaired
automatically,  you want  something  which will  route  around the  failure,
rather  than something  which requires  the ingress  to recompute  (based on
what?) an explicit route. 

If the PW egress is to stay the same, while the set of tunnels through which
the  PW passes  is to  change, then  what you  are asking  for is  a routing
protocol that  runs over the tunnel  overlay, and which gives  you the "next
hop" in that overlay for the IP address of the egress. 

Note that the overlay consists not of the PWs, but of the tunnels. 

> if PW Switching nodes would be required within ASs, RSVP-TE seems to offer
> a straightforward solution.  

I would like  to understand better what the antecedent  of this statement is
true.  However, I certainly don't agree with the conclusion, as RSVP-TE does
not  provide the  routing capability  that appears  to be  required  in this
case. 

As  I said, I'd  like to  understand better  the need  for routing  over the
tunnel  overlay.  If  that model  turns  out to  be necessary,  we can  then
discuss whether its needs can or cannot be met with the existing protocols. 

The claim  that RSVP-TE  is preferable whenever  we need to  send parameters
which we call "QoS" or "explicit route" is not a claim which I can take very
seriously.  Generally, if  you have a protocol that  does something, and you
find that you need  to add a new parameter, you just  add the new parameter;
you don't  go looking for another  protocol that already has  a parameter of
the same name!  You first need to  understand which is the tail and which is
the dog.