Subject: Re: RSVP-TE and PW

From: Eric Rosen <[email-masked]>
Date: Tue, 05 Oct 2004 10:50:25 -0400

This thread  is getting  a bit  repetitive, I'll try  to avoid  repeating my
opinions on issues  that I've already tried to address.   Diego raises a new
issue though: 

> LDP doesn't have mp2p

Did you mean p2mp? 

In  either case,  it's far  from clear  what a  multipoint PW  would  be, we
haven't  actually defined  any such  concept.   (The PWs  we've defined  are
bidirectional.) 

The closest  thing to  a p2mp  PW that we  have is  the VPLS  service, which
already has  two non-interoperable signaling protocols  and probably doesn't
need a third. 

Without more  discussion of just what a  multipoint PW is, it's  hard to say
whether we need to have such things, or just what the signaling protocol for
it should be.

---

From: Luca Martini <[email-masked]>
Date: Wed, 06 Oct 2004 09:48:18 -0600

Diego,

None of these are features or requirements  specific to the PW itself.
So there is no need to have the PW signaling protocol provide them.
Luca

Diego Caviglia wrote:

>Hi Thomas,
>                         actually it seems to me that what we are
>discussing here is if both the protocol solve the same problems and the
>result is that:
>
>LDP doesn't provide QoS
>LDP doesn't have TE features
>LDP doesn't have mp2p
>
>Now may be that feature are useless but may be not.  Moreover as some
>carrier said having two protocol instead only one is not good from an OPEX
>point of view.
>
>I'm not pushing one approach because "...who seem to be motivated solely by
>their marketing departments to hold out for their
>'alternate' approach based on purported technical superiority." I'm just
>trying to understand well this stuff.
>
>Best Regards
>
>Diego
>
>
>
>
>"Thomas D. Nadeau" <[email-masked]> on 04/10/2004 19.55.49
>
>To:    Benny Ammitzboll <[email-masked]>
>cc:    <[email-masked]>, "Stewart Bryant <stbryant" <[email-masked]>,
>       pwe3 <[email-masked]>, "Diego Caviglia" <[email-masked]>
>
>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
>
>  
>