Subject: Re: RSVP-TE and PW

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

> if you  also re-read Eric's last mail  (04 October 2004 18:41)  he is also
> reinforcing the point  we in BT have been making from  the outset here, ie
> PW switching will create a new layer network 

No, I was saying that Peter's message seemed to presuppose that model, but

a. I didn't see the justification for it, and 

b. I don't see explicit routing as either necessary or sufficient to support
   that model.

---

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

Neil,

See inline.
Also as a general comment I do not see this general thread going 
anywhere at this time , so I'm going to dedicate very little time to it. 
( it's going round and round again and again )
Luca

[email-masked] wrote:

>Tom...point taken.  But if you also re-read Eric's last mail (04 October
>2004 18:41) he is also reinforcing the point we in BT have been making
>from the outset here, ie PW switching will create a new layer network
>(though Eric is not explicitly expressing it like this)....so all the
>functions any layer network requires (which vary dependent on the mode
>considered) will require to be developed yet again.  But for what
>compelling reason?
>
>  
>
Neil, I think the problem is the definition of a network. PW switching 
just connects wires 1 to 1 in a static mode. I see it as a wire 
extension. Now if you develop autoprovisioning for the switching points 
, with some other protocol, take BGP as an example, then you create an 
new layer network. This work maybe valid and useful but it needs to be 
added to the autodiscovery/autoprovisioning work in L2VPN. I do not see 
anything in the pw-switching draft that impedes this extension work from 
happening.

>Now, without labouring the point too heavily (yet again) the cl-ps mode
>is functionally not the same as the co-ps mode and neither is
>functionally the same as the co-cs mode.  So if you really want to point
>the finger at where the root problem lies it is here.  Once folks grok
>that the so-called peer-model notion of 'functionally crunching' all the
>modes from IP to optics is a broken idea the rest follows. 
>
>It is also interesting to observe that some folks want RSVP-TE as *the*
>prescriptive signalling protocol for the co-cs mode (eg SDH/OTN), and
>note also it has to work OOB wrt to the traffic data-plane as this is
>forced requirement of the co-cs mode......well, that may be so, but it
>is not a logically forced choice for the signalling component once folks
>grok the peer-model coulping idea is a broken idea.
>
>A signalling protocol is a signalling protocol is a signalling
>protocol....some are better functionally specified than others, ie there
>are only so many ways to do this function (just like OAM if you also
>recall that 'discussion' ;-)).  Of course, the message set is a little
>different for the co-ps mode and the co-cs mode (largely due to the fact
>that the link-connection IDs are abstract in the co-ps mode and
>real/physical in the co-cs mode).....but things like taking the
>signalling (and management-plane) protocols logically OOB wrt to the
>traffic ought to be a key requirement for both modes (simply from the
>enhanced security and stability considerations of a best-of breed
>solution here).  However, this is not perhaps something that obviously
>springs to mind for folks used to only dealing with the cl-ps mode.
>
>The targeted spin of LDP signalling is more like a session protocol IMO,
>ie it only conveys parameters between 2 fixed end-points and does not
>flex connectivity between those 2 end-points.  So whilst this remains
>'the problem being addressed' this is fine. This is also very closely
>  
>
I agree. as I said above we need to solve the problem using what we have 
built so far. This is not something that PWE3 is chartered to solve , 
and most likely LDP is not the autodiscovery/provisioning protocol 
across administrative domains.

>related to another point I have made many times in the past regarding
>the nature of the PW entity itself, ie its an adaptation function
>between 2 layer networks....with the additional spin that XoverIP is
>somehow the same as XoverMPLS.  This is clearly not true of course, but
>it seems to keep some folks happy ;-) 
>
>But if one now wants to flex connectivity you need the full range of
>functions to make the PW entity a layer network, ie addressing,
>discovery/route-calculation, signalling, OAM, etc.  So I think the gripe
>of those arguing for RSVP-TE here is that targeted LDP does not flex
>connectivity....as its not a proper signalling protocol.  However, our
>gripe is that:
>-	we don't need yet another 'PW' layer network being
>created....please just fix MPLS
>-	and please try and grok functional architecture and how this
>applies to the 3 modes better so that errors-of-judgement like this
>don't keep being made.
>
>regards, Neil
>
>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Thomas D. Nadeau
>>Sent: 04 October 2004 18:56
>>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
>>
>>    
>>
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>
>
>  
>