Subject: Re: RSVP-TE and PW

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 5 Oct 2004 07:39:19 -0400

On Oct 4, 2004, at 6:19 PM, Busschbach, Peter B (Peter) wrote:

> Tom,
>
> I currently have problems with email access and lack of time to answer 
> email. Therefore, I am not yet able to respond to other emails on this 
> topict. However, I can't let this one go unchallenged.
>
> I am not having the CR-LDP vs RSVP-TE debate again. It has been 
> decided. The answer is RSVP-TE. Did you see me propose CR-LDP??

	I didn't mean literally; rather, the flavor of the arguments
are the same as were provided before during the old debates.

> Just to be clear: I personally don't see any reason why you would use 
> RSVP-TE for the existing PW architecture that consists of single-hop 
> PWs over end-to-end PSN tunnels between PEs.
>
> My previous email was based on the premise that perhaps, at some point 
> in the future, we may find that the current PW architecture does not 
> scale well and that enhanced solutions are needed.
>
> Going back in time: RIP was a protocol "well understood, deployed in 
> real code". According to your logic, we should never have developed 
> OSPF and IS-IS.

	Not exactly. In that case there are clear advantages
over RIP in OSPF or IS-IS. In this case, it is not clear
what if any advantages there are for using RSVP-TE over
LDP for signaling PWs.

	--Tom

>
> Peter
>
>> -----Original Message-----
>> From: Thomas D. Nadeau [mailto:[email-masked]]
>> Sent: Monday, October 04, 2004 1:56 PM
>> To: Benny Ammitzboll
>> Cc: [email-masked]; pwe3; Stewart Bryant <stbryant
>> Subject: Re: [PWE3] RSVP-TE and PW
>>
>>
>>
>> 	There seems little logical relevance as to whether
>> you should use one protocol or the other because you have
>> already implemented one or the other. The fact is
>> that if you are building an LSR (or enhancing an
>> existing one), you should be building in both RSVP-TE and LDP anyway
>> (or have both there already).  To me, the most
>> germane point is what Eric said earlier -- LDP signaling
>> for PWs already is well understood, deployed in real
>> code and solves what seems to be the same problems solved by
>> an RSVP-TE-based approach.  Call me cynical, but it seems
>> that this argument really boils down to is the old RSVP-TE
>> vs. CR-LDP argument (again) -- both protocols solve the
>> same problems, with the majority implementing/deploying
>> one approach, while the other approach is pushed by a small
>> number of vendors or vendor who seem to be motivated solely by
>> their marketing departments to hold out for their
>> 'alternate' approach based on purported technical
>> superiority.
>>
>> 	--Tom
>>
>>
>>
>>> May I add that if you already have RSVP-TE to set up your
>> TE tunnels
>>> there
>>> seems to be little advantage in implementing yet another
>> protocol to
>>> carry
>>> the same kind of objects from one endpoint to another.
>>>
>>> Therefore I find the question raised by Diego relevant -
>> although it is
>>> probably too late.
>>>
>>> /Benny
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of
>>> Eric Rosen
>>> Sent: 29. september 2004 15:27
>>> To: Diego Caviglia
>>> Cc: pwe3; Stewart Bryant <stbryant
>>> Subject: Re: [PWE3] RSVP-TE and PW
>>>
>>>
>>>
>>>> given that RSVP-TE has some advantage w.r.t LDP (e.g. QoS)
>>>
>>> The "some advantage" is not relevant in this context.
>>>
>>> The network  layer tunnels  through which  the PWs flow  may have
>>> QoS.  The
>>> attachment circuits which are connected to each other via a PW may
>>> have QoS.
>>> But I  don't think there is  any notion of QoS  which is
>> specific  to
>>> the PW
>>> itself, rather than to the network layer or the attachment circuits.
>>>
>>> Therefore, any QoS  parameter carried in the PW  setup
>> protocol would
>>> really
>>> be just an opaque object to that protocol.  A PW endpoint
>> might want
>>> to pass
>>> this object  to the network layer, saying  in effect "put this  PW
>>> through a
>>> tunnel that has this QoS".  A PW  endpoint might want to pass this
>>> object to
>>> the NSP layer, saying in effect  "set up the attachment circuit
>>> according to
>>> these  QoS parameters".   But  the  PW setup  protocol  doesn't
>>> actually  do
>>> anything itself  with the QoS parameter,  other than to carry  it
>>> around and
>>> pass it off. The only QoS  requirement for the PW signaling
>> protocol
>>> is that
>>> it  be able to  carry an  opaque QoS  object from  one endpoint  to
>>> another.
>>> RSVP-TE has  no advantage over LDP  with respect to the
>> carrying of
>>> objects
>>> from one endpoint to another.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> pwe3 mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: Chris Chase <[email-masked]>
Date: Tue, 05 Oct 2004 10:49:14 -0400

Tom,

I know that this has probably been dicussed before, but I don't keep up 
with the list.

Is there a concern about how many simultaneous LDP sessions can run on a 
PE?  I know of TCP/IP stacks and vendors that have problems with getting 
more than one or two thousand BGP sessions running on their routers and 
it often has to do with limits in their TCP/IP stacks (e.g., file 
descriptor length limits, inefficient poll or select).  With LDP for PW 
signaling we can be adding on the order of 500 sessions easily. 

Looking at a very large FR/ATM network I know and giving you rough 
numbers: there are almost 500 remote terminating nodes for some 
switches.  In fact, there are hundreds of switches that have several 
hundred remote node terminations (over a hundred have more than 400 
remote node terminations).

Is not this one area where RSVP for PW signaling has an advantage?

Chris Chase