Subject: RSVP-TE and PW

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 29 Sep 2004 09:50:52 +0200

Hi all,
              l I'm pretty new on this stuff so I apologise if my question
has been alredy discussed.

Why it is not foreseen to use RSVP-TE in order to set-up PW?

Best Regards

Diego

------------------------------------------
Diego Caviglia
Marconi - Optical Networks
ASTN/GMPLS - System Design Manager
Via A. Negrone 1/A
16153 Genoa - Italy
Phone: +390106003736

"Timeo Danaos et Dona Ferentes"

---

From: "Nurit Sprecher" <[email-masked]>
Date: Wed, 29 Sep 2004 10:52:27 +0200

Hi,
I can list some benefits in using RSVP-TE for signaling PWs even in
intra domain. For example:
1. For TE environment, TE tunnels could be considered as point-to-point
TE links and IGP-TE could distribute the actual load of them and CSPF
could be used to select (automatically) the most appropriate TE tunnel
to transmit the PW's TE traffic. Today this should be manually defined
via the MPLS PW MIB).
2. There is no way to identify at the Egress side on which specific TE
Tunnel the traffic from the MPLS network is coming. Such information
could be useful in the switches to support enhanced modes of QoS (to
know the amount of BW expected to come from each port). Since the Egress
has no idea from which tunnel the PW's traffic would come, the Egress hs
no idea from which port the PW's traffic would come (it potentially may
come from each port). If RSVP-TE is used to signal the PWs, the Egress
node could identify from which specific ports to expect the traffic. 
3. Etc. 
Please note that there are some issues that should be addressed (like
FRR, etc.) but I guess there are solutions.

Of course for inter domain RSVP-TE for PWs can be useful, where each
tunnel is considered as a point-to-point TE link, and the PCE can be
used, etc.
Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tony Li
Sent: Wednesday, September 29, 2004 10:20 AM
To: Diego Caviglia
Cc: [email-masked]
Subject: Re: [PWE3] RSVP-TE and PW

Well, IMHO, RSVP-TE is best confined to a single routing domain, where 
the
IGP can carry appropriate information.  RSVP-TE on a inter-domain basis
is still an open topic and basing one open topic on another open topic
is not the means to a quick consensus.

Yes, one COULD set PW with RSVP alone, if that's what you meant, but to
what end?  Again, in the inter-domain case, you do not have detailed 
path
information, nor does anyone that I know of anticipate propagating full
information, so the 'signaling' is not going to get you an explicit 
path.

If you don't need hop-by-hop signalling, there are FAR better ways of 
doing
things than with RSVP.

So, again IMHO, I would say that RSVP(-TE) doesn't provide interesting
capabilities in the most general situation.

Tony

On Sep 29, 2004, at 12:50 AM, Diego Caviglia wrote:

> _______________________________________________
> 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: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 29 Sep 2004 08:29:08 -0400

There is already a draft that proposes to use RSVP-TE for PW establishment:
draft-raggarwa-rsvpte-pw-00.txt.

> From: Nurit Sprecher [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2004 4:52 AM
> To: Tony Li; Diego Caviglia
> Cc: [email-masked]
> Subject: RE: [PWE3] RSVP-TE and PW
> 
> 
> Hi,

---

From: [email-masked]
Date: Wed, 29 Sep 2004 13:33:59 +0100

Stewart....what about the new notion of PW switching here?  This for
sure will create a new PW layer network (though I am not sure if this is
obvious to all folks).  (Targeted) LDP looks as though it would have to
be more than a 'PE only based' parameter exchange protocol here does it
not?  Ditto the PW entity itself, ie no longer a simple adaptation
function, but now a layer networked entity itself.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: 29 September 2004 13:03
> To: Diego Caviglia
> Cc: [email-masked]
> What do you mean by setup?
> 
> PWE3 specifies how the PEs are set up. Is says nothing about 
> the underlying MPLS PSN, other than to take some anti-ECMP 
> precautions.
> 
> LDP is used to exchange parameters between the PEs. The PEs
> can then use any method they wish to carry the PW packet - 
> either an LDP signalled path or an RSVP-TE signalled path.
> 
> Whilst their may be an advantage in using RSVP-TE to carry
> the packets, there is no clear reason to use it as an 
> alternative parameter exchange protocol.
> 
> - Stewart
> 
> Diego Caviglia wrote:
> 
> >Hi all,
> >              l I'm pretty new on this stuff so I apologise if my 
> >question has been alredy discussed.
> >

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 29 Sep 2004 14:42:25 +0200

Hi Stewart,
            thank you for your reply please see my comments in line.

Best Regards.

Diego

Stewart Bryant <[email-masked]> on 09/29/2004 02:02:41 PM

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Sep 2004 09:13:12 -0400

Nurit> I can list some benefits in using RSVP-TE for signaling PWs even in
Nurit> intra domain. For example: 

Nurit> 1. For TE environment, TE tunnels could be considered as point-to-point
Nurit> TE links and IGP-TE could distribute the actual load of them and CSPF
Nurit> could be used to select (automatically) the most appropriate TE tunnel
Nurit> to transmit the PW's TE traffic. Today this should be manually defined
Nurit> via the MPLS PW MIB). 

This seems to be confusing the PSN tunnels through which PWs travel with the
PWs  themselves.  Sending  the PW  data through  an RSVP-TE  tunnel,  even a
dynamically chosen RSVP-TE tunnel, does  not require using RSVP-TE to set up
and maintain the PWs. 

Nurit> 2. There is no way to identify at the Egress side on which specific TE
Nurit> Tunnel the traffic from the MPLS network is coming. Such information
Nurit> could be useful in the switches to support enhanced modes of QoS (to
Nurit> know the amount of BW expected to come from each port). Since the Egress
Nurit> has no idea from which tunnel the PW's traffic would come, the Egress hs
Nurit> no idea from which port the PW's traffic would come (it potentially may
Nurit> come from each port). If RSVP-TE is used to signal the PWs, the Egress
Nurit> node could identify from which specific ports to expect the traffic. 

Again, binding  a PW  to a particular  tunnel does  not require that  the PW
setup and maintenance protocol be the  same protocol as the tunnel setup and
maintenance protocol.

If we were sending TCP connections through a TE tunnel, you wouldn't propose
to replace TCP with RSVP-TE, would you?

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 29 Sep 2004 14:24:28 +0100

Neil

[email-masked] wrote:

>Stewart....what about the new notion of PW switching here?  
>
Diego's question said nothing about switching, and I was answering in 
terms of
work that the WG has approved to date.

However I note your points and I am thinking about them.

Stewart

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 29 Sep 2004 15:38:20 +0200

Eric,
           I see your point and I can agree with you but what I was
actually meaning is: given that RSVP-TE is better than LDP for set-up
tunnel in the PSN network (do you agree?) and there no advantage, at list i
don't see any advantage, in using LDP in order to set-up PW why not use
RSVP-TE for both PW and Tunnel set-up?

The botton line is why I have to implement two different signalling
protocol in my box?

Regards

Diego

Eric Rosen <[email-masked]> on 09/29/2004 03:27:03 PM

Please respond to [email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 29 Sep 2004 14:58:27 +0100

Exactly

- Stewart

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 29 Sep 2004 10:00:44 -0400

....and that exactly is what is proposed in 
draft-shah-pwe3-pw-qos-signaling-00.txt.

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2004 9:27 AM
> To: Diego Caviglia
> Cc: pwe3; Stewart Bryant <stbryant
> > 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. 
> 
> 
> 
> 
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 29 Sep 2004 16:01:31 +0200

Neil,
           could you please explain me what do you mean with PW switching?

Does it means something similar to HO and LO relationship (or VC, VP in
ATM) in SDH?

Thanks

Best Regards

Diego

[email-masked]@ietf.org on 09/29/2004 02:33:59 PM

Sent by:    [email-masked]

---

From: Benny Ammitzboll <[email-masked]>
Date: Wed, 29 Sep 2004 16:40:17 +0200

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

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.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 29 Sep 2004 15:40:42 +0100

http://www.ietf.org/internet-drafts/draft-martini-pwe3-pw-switching-00.txt

- Stewart

Diego Caviglia wrote:

>To:    <[email-masked]>
>cc:    [email-masked]

---

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 29 Sep 2004 10:47:43 -0400

Eric,

-> 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.

  Then why does draft-ietf-pwe3-arch-07.txt, PWE3 Architecture
  considers QoS in section 5.1.3.

5.1.3.  Quality of Service Considerations

   Where possible, it is desirable to employ mechanisms to provide PW
   Quality of Service (QoS) support over PSNs.

Venkata.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Sep 2004 10:55:50 -0400

Eric> But I  don't think there is  any notion of QoS  which is specific  
Eric> to the PW itself, rather than to the network layer or the 
Eric> attachment circuits.

Venkata>   Then why does draft-ietf-pwe3-arch-07.txt, PWE3 Architecture
Venkata>   considers QoS in section 5.1.3.

>    Quality of Service (QoS) support over PSNs. 

Since it talks of "Quality of  Service support over PSNs", I've always taken
it to refer to mechanisms for telling the network layer either that a given PW
needs to be routed along a  TE tunnel with particular characteristics, or to
mechanisms for determining how to the DSCP or EXP bits.  I.e., network layer
QoS.

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 29 Sep 2004 17:06:00 +0200

Hi Eric,
                I've understood from ccamp stuff that TE is an important
thing for Carriers isn't it?

So my answer is: I have to implement RSVP-TE in order to set-up LSP with TE
because my customer wants to have TE features in their network and I have
to implement LDP for set-up PW because PWE3 standardise it.

So at the end I have to implement two signalling protocol RSVP-TE in order
to make money and LDP dor be standard.

Given that it is more diffucult to convince Carriers to change their mind I
try to use RSVP-TE to do all the work.

Regards.

Diego

Eric Rosen <[email-masked]> on 09/29/2004 04:44:05 PM

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 29 Sep 2004 17:10:33 +0200

> However, RSVP-TE does have some refresh overhead that becomes nasty when
> there are many tunnels...

I agree with that but you have ways to manage that RFC 2961 even if my
feeling is that refresh mechanis is in conflict with the statement that
control plane failure must not affect data plane.

What about if cc plane fails but traffic still flow?  I have to delete a
10Gb LSP just because I've miss some refresh messages?

But of course that is another story and is out of the scope of this thread.

Regards

Diego

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 29 Sep 2004 08:26:04 -0700

Eric,

> > given that RSVP-TE is better than LDP for set-up tunnel in the PSN network
> > (do you agree?) 
> 
> Only if the tunnel is traffic engineered. 
> 
> Well, if  you're building a  box, you should  know that there are  many more
> deployments of LDP than of RSVP-TE. 
> 
> But one could equally  well ask, "if I have implemented LDP  as the PW setup
> and  maintenance  protocol,  as specified  by  the  PWE3  WG, why  should  I
> implement  a  second PW  setup  and maintenance  protocol,  when  it is  not
> necessary to do so in order to solve any problems?"

One could also equally well ask "if an operator uses RSVP-TE for PE-PE
tunnels, then why would the operator use yet another PW setup and
maintenance protocol, when it is not necessary to do so in order
to solve any problems" ?

Yakov.

---

From: [email-masked]
Date: Wed, 29 Sep 2004 16:35:06 +0100

Stewart,

> As Peter says there is a proposal before the WG, but I don't see what 
> advantage
> this would add over using the LDP mechanism that we have 
> already defined in
> conjunction with RSVP-TE in the datapath.

The advantage from an operators perspective would be support for functional convergence, i.e. if an operator uses RSVP-TE for  signalling MPLS labels for tunnels, then using RSVP-TE for signalling MPLS labels for PWs instead of LDP removes any operational overhead associated with using LDP (i.e. training on LDP, LDP protocol upgrades, LDP documentation, etc.).

Saying that, an operators case for using RSVP-TE for PWs just because its used for tunnels could be considered by some to be weakened if the operator supports RFC2547 and therefore uses BGP for distributing labels as well.

Regards,
Richard

---

From: Benny Ammitzboll <[email-masked]>
Date: Wed, 29 Sep 2004 17:34:19 +0200

This was in fact an attempt to research the facts now that mails were going
back and forth about the issue. You have provided that, thank you, and my
apologies.

I still feel however, that having two protocols solving more or less the
same problem is a waste of implementation and understanding bandwidth.

/Benny

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: 29. september 2004 16:50
To: Benny Ammitzboll
Cc: Diego Caviglia; [email-masked]
Subject: Re: [PWE3] RSVP-TE and PW

> Isn't the case simply that Cisco had developed LDP and tried to push this
> for TE tunnels, but lost to RSVP-TE?

Nothing could be further from the truth!

Cisco and Juniper pushed RSVP-TE for  TE tunnels, Nortel and IBM (along with
many small vendors) pushed LDP for  TE tunnels.  Obviously you have not even
made an attempt to research the facts here.

> In comes PW setup and voila - LDP is back in the game

LDP was  never "out of  the game" because  most MPLS deployments do  not use
traffic engineering.

---

From: [email-masked]
Date: Wed, 29 Sep 2004 16:55:16 +0100

Diego,

Put simply, it is the difference between a 1-hop (and only ever 1 hop)
connection and a multi-hop network connection.  In other words, the
former has no flexibility in the (networked) access points it can
connect, whereas the latter does.  If you are familar with G.805 func
arch (and I know many folks in Marconi are) its like comparing a trail
composed of a single fixed link-connection with a trail composed of a
concatenation of subnetwork (read as nodes in the limit) and fixed
link-connections (between nodes).

Now, a pukka layer network can, of course, have a degenerate trail of 1
hop.  This is a special case. 

Consider now an adaptation function between 2 layer networks.  The
nature of the required adaptation function will depend on both the mode
of the client and server layer networks considered.  A PW is a largely
general adaptation that regards XoverMPLS similar to XoverIP.....where X
is the client layer network and MPLS or IP is the server layer network.
Note carefully it is MPLS and IP that are the layer network entities
here and not the PW....as stated, that is only an adaptation function. 

Compare now a degenerate 1 hop network connection with a PW.....they are
rather similar.

Some folks are however talking about multi-hop PWs.  This means that all
the functional components that a layer network requires (which are also
a function of its mode) need to be added to the PW entity, ie it is no
longer a simple adaptation function.

Note - A similar issue has been proposed in the past for GFP....where
GFP is an adaptation function that can be applied to a co-cs server
layer network (eg SDH VC4 say) for the purpose of traffic unit
delineation of either a cl-ps or co-ps client layer network.  GFP is
clearly not a layer network in this context (ie just a 1 hop adaptation
function), and to make it a layer network would require adding lots of
additional functionality. So far we have considered we do not need this.

Hope that helps.

regards, Neil

> From: Diego Caviglia [mailto:[email-masked]] 
> Sent: 29 September 2004 15:02
> To: Harrison,N,Neil,IKR2 R
> Cc: pwe3
> This for sure will create a new PW layer network (though I am 
> not sure if this is obvious to all folks).  (Targeted) LDP 
> looks as though it would have to be more than a 'PE only 
> based' parameter exchange protocol here does it not?  Ditto 
> the PW entity itself, ie no longer a simple adaptation 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Stewart Bryant
> > PWE3 specifies how the PEs are set up. Is says nothing about the 
> > underlying MPLS PSN, other than to take some anti-ECMP precautions.
> >
> can then 
> > use any method they wish to carry the PW packet - either an LDP 
> > signalled path or an RSVP-TE signalled path.
> >
> > Whilst their may be an advantage in using RSVP-TE to carry the 
> > packets, there is no clear reason to use it as an alternative 
> > parameter exchange protocol.
> >
> > - Stewart
> >
> > Diego Caviglia wrote:
> >
> > >Hi all,

---

From: [email-masked]
Date: Wed, 29 Sep 2004 17:32:25 +0100

Stewart,

> Suppose we do persue the RSVP approach on the table. The standard IETF
> approach would be to declare one of them mandatory. Given 
> that LDP should
> be an RFC by the time RSVP PW signalling even gets to the IESG, the
> mandatory  protocol would almost certainly be LDP. So you would end up
> with two PW signalling protocols on your box to make it conformant.

This doesn't seem to agree with the PWE3 architecture document which reads "The definition of the information that PWE3 needs to be signalled is within the scope of PWE3, but the signalling protocol itself is not." This sentence is actually in the context of PSN signalling, but if the standard IETF approach is to declare one approach mandatory, why mandate a PW signalling protocol but not a tunnel signalling protocol? Failure to support either a common PW or tunnel signalling protocol between solutions from different vendors will have the same effect, i.e. the vendors solutions won't be able to interoperate.

Also, the debate here on using RSVP-TE vs LDP for PW signalling has brought up a number of the same points raised during the BGP vs LDP debate for VPLS, e.g. one protocol is better than two, if an operator already uses X for Y then it makes sense to use X for Z if it performs the same function as the alternative, etc. The outcome of that debate was that both proposals were progressed to WG document status and both have been deployed out in the field but I'm not aware of either one being declared mandatory. Again, why mandate a PW signalling protocol but not a VPLS signalling protocol (I'm aware this question is out of scope of the PWE3 WG, but it is related because the L2VPN WG uses PWs).

Regards,
Richard

---

From: "Francois Le Faucheur \(flefauch\)" <[email-masked]>
Date: Wed, 29 Sep 2004 18:31:54 +0200

Hello Richard, 

>> The advantage from an operators perspective would be support 
>> for functional convergence, i.e. if an operator uses RSVP-TE 
>> for  signalling MPLS labels for tunnels, then using RSVP-TE 
>> for signalling MPLS labels for PWs instead of LDP removes 
>> any operational overhead associated with using LDP (i.e. 
>> training on LDP, LDP protocol upgrades, LDP documentation, etc.).
>> 
>> Saying that, an operators case for using RSVP-TE for PWs 
>> just because its used for tunnels could be considered by 
>> some to be weakened if the operator supports RFC2547 and 
>> therefore uses BGP for distributing labels as well.

Agreed.

My perception is that the most common MPLS deployment scenario today is
indeed 2547 with BGP for VPN label distribution, and LDP for IGP label
distribution.
Also, in quite a few of the 2547 networks where RSVP-TE has also been
deployed (in particular for FRR), LDP is still used since RSVP-TE
tunnels are not always end-to-end PE-to-PE.

So I would personnaly say the operational overhead argument (training on
protocol, protocol upgrades, protocol documentation) is (at least
currently) clearly in favor of LDP.

Cheers

Francois

---

From: [email-masked]
Date: Wed, 29 Sep 2004 17:55:22 +0100

Yakov Rekhter wrote 29 September 2004 16:26
> 
> Eric,
> 
> > > given that RSVP-TE is better than LDP for set-up tunnel 
> in the PSN 
> > > network (do you agree?)
> > 
> > Well, if  you're building a  box, you should  know that there are  
> > many more deployments of LDP than of RSVP-TE.
> > 
> > But one could equally  well ask, "if I have implemented LDP 
>  as the PW 
> > setup and  maintenance  protocol,  as specified  by  the  PWE3  WG, 
> > why  should  I implement  a  second PW  setup  and maintenance  
> > protocol,  when  it is  not necessary to do so in order to 
> solve any 
> > problems?"
> 
> One could also equally well ask "if an operator uses RSVP-TE 
> for PE-PE tunnels, then why would the operator use yet 
> another PW setup and maintenance protocol, when it is not 
> necessary to do so in order to solve any problems" ?
> 
> Yakov.
NH=> You can take Yakov's point further......  If an operator is using
RSVP-TE for GMPLS then why not also use this for MPLS?  A signalling
protocol is a signalling protocol....just like we don't need lots of
technologies in each network mode neither do we need lots of functional
components doing a largely similar job (signalling being one of those,
but also applies to OAM ;-)).  We can also start to consider moving
internal/sensitive control/management protocols OOB wrt the
traffic....as has to be the case in GMPLS.  Further, there are
operational/opex advantages in trying to reduce the number of
technologies per mode and striving for the best-of-breed functional
components per mode.....for sure the functional components need to be
slightly different per mode but there is no need for wholesale
change-out.

regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 29 Sep 2004 19:50:04 +0100

>mechanisms for determining how to the DSCP or EXP bits.  I.e., network layer

That is what it is supposed to mean.

- Stewart

---

From: Chris Metz <[email-masked]>
Date: Wed, 29 Sep 2004 12:26:23 -0700

I can appreciate striving for a single protocol supporting
PSN and PW setups. My general comments are:

- LDP is the defacto standard out there already running
on a whole bunch of boxes ... for not only PW setups but
is also the predominant PSN tunnel setup protocol.

- Nothing to be gained by enhancing RSVP-TE to
distribute PW labels. You would have a single protocol in name
only performing two discrete functions ... one for
coarse, infrequent PSN TE tunnel setup, the other for
many inter-PE PW setups muxed into those PSN TE tunnels.
In the latter I guess we might have to enhance RSVP-TE
pass along all the PW-specific gunk and behave like
TCP at the transport layer.

- What happens if my PSN does not run
RSVP-TE but we want to support PW setups?
Do we now need to extend RSVP-TE to emulate
the independent FEC/label distribution?

- Decoupling edge-specific functions (i.e. creating,
maintaining PW state) from core functions (i.e.
building PSN tunnels) permits each to
evolve independent from the other. (I am invoking
the end-to-end argument here :-)

Cheers ...

---

From: [email-masked]
Date: Thu, 30 Sep 2004 09:38:38 +0100

Chris,

> TCP at the transport layer.

Why is it OK to use LDP to perform two discrete functions "one for coarse, infrequent PSN tunnel setup, the other for many inter-PE PW setups muxed into those PSN tunnels" but not RSVP-TE? Why is it OK to enhance LDP to "pass along all the PW-specific gunk and behave like TCP at the transport layer" but not RSVP-TE? 

> RSVP-TE but we want to support PW setups?

I don't understand the relevance, the same question could be asked about LDP, i.e. "What happens if my PSN does not run LDP but we want to support PW setups? 

If your network supports RSVP-TE for PW setup then it will work with any PSN tunnel signalling protocol (i.e. RSVP-TE or LDP) as they are independent of each other. If your network doesn't support RSVP-TE at all then obviously you need to use something else for PW and tunnel setup, i.e. LDP. 

> the independent FEC/label distribution?

I don't understand the question. If the network supports RSVP-TE for PW signalling but not for tunnel signalling then you just need to use another tunnel signalling protocol, i.e. LDP. Why would you need to extend RSVP-TE to emulate independent FEC/label distribution?

> the end-to-end argument here :-)

I fail to see the relevance of this argument. Firstly, if the functions are decoupled what has that got to do with the choice of protocol? If you are suggesting that the two functions should be carried out by two different protocols (i.e. LDP for PWs RSVP-TE for tunnels) then we shouldn't use LDP for PWs and LDP for tunnels then. Secondly, PWs are created/maintained PE to PE and PSN tunnels are created/maintained PE to PE, so why is one a core function and one an edge function? Both functions are required at the edge in the PE, just because tunnel setup involves P routers as well I don't think this justifies defining one as a core function and the other as an edge function.

Regards,
Richard

---

From: Chris Metz <[email-masked]>
Date: Thu, 30 Sep 2004 05:17:47 -0700

At 09:38 AM 9/30/2004 +0100, [email-masked] wrote:
>Why is it OK to use LDP to perform two discrete functions "one for coarse, 
>infrequent PSN tunnel setup, the other for many inter-PE PW setups muxed 
>into those PSN tunnels" but not RSVP-TE? Why is it OK to enhance LDP to 
>"pass along all the PW-specific gunk and behave like TCP at the transport 
>layer" but not RSVP-TE?

Hey Richard-
LDP already solves the inter-PE PW setup problem and runs on top of TCP. 
Unless there is a compelling
reason I see no need to duplicate the effort in RSVP-TE.

>I don't understand the relevance, the same question could be asked about 
>LDP, i.e. "What happens if my PSN does not run LDP but we want to support 
>PW setups?
>
>If your network supports RSVP-TE for PW setup then it will work with any 
>PSN tunnel signalling protocol (i.e. RSVP-TE or LDP) as they are 
>independent of each other. If your network doesn't support RSVP-TE at all 
>then obviously you need to use something else for PW and tunnel setup, 
>i.e. LDP.
>
>I don't understand the question. If the network supports RSVP-TE for PW 
>signalling but not for tunnel signalling then you just need to use another 
>tunnel signalling protocol, i.e. LDP. Why would you need to extend RSVP-TE 
>to emulate independent FEC/label distribution?

Just carrying the argument one step further ... if targeted LDP can be 
replaced by
RSVP-TE for inter-PE PW setup are we next going to
suggest that RSVP extensions advertise prefix/label bindings
in the way that hop-by-hop LDP between P routers does today?
I think not ...

>I fail to see the relevance of this argument. Firstly, if the functions 
>are decoupled what has that got to do with the choice of protocol? If you 
>are suggesting that the two functions should be carried out by two 
>different protocols (i.e. LDP for PWs RSVP-TE for tunnels) then we 
>shouldn't use LDP for PWs and LDP for tunnels then. Secondly, PWs are 
>created/maintained PE to PE and PSN tunnels are created/maintained PE to 
>PE, so why is one a core function and one an edge function? Both functions 
>are required at the edge in the PE, just because tunnel setup involves P 
>routers as well I don't think this justifies defining one as a core 
>function and the other as an edge function.

Yes a PE by definition is a member of the core set of network nodes.
But the respective edge-specific functions (i.e. MP-BGP, PW signaling) and
core-specific functions (i.e. IGP routing) are designed and managed
separately. RSVP-TE is a core-specific function.

It can be further enhanced for optimal core performance
independent of any edge functions that may benefit. Likewise
the converse is true.

Cheers ...

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 30 Sep 2004 22:11:55 +0200

Richard and all,
Please see a brief comment inline.
I have snipped the parts of the message that are not relevant.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2004 6:32 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
... snipped ... This sentence is 
> actually in the context of PSN signalling, but if the 
> standard IETF approach is to declare one approach mandatory, 
> why mandate a PW signalling protocol but not a tunnel 
> signalling protocol? 
>
[Sasha] Tunnel signaling protocols are, IMHO, "general purpose", not
in the least because the tunnels themselves are "general purpose".
There is no restriction for using the same tunnel for carrying "public" IP,
"private" IP (L3 VPNs) and PW traffic. Just as there is no prohibition on
separating these kinds of traffic to different tunnels. It is a matter of
choice.
>
> Failure to support either a common PW or 
> tunnel signalling protocol between solutions from different 
> vendors will have the same effect, i.e. the vendors solutions 
> won't be able to interoperate.
>
[Sasha] Failure to support a common "tunnel signaling" protocol would 
mean that the network in question cannot operate MPLS. 
Failure to support the common PW signaing protocol would only mean
that the SP cannot provide PW services but it does not stop him from
providing other MPLS-based services (e.g., L3 VPNs).
> 
> Also, the debate here on using RSVP-TE vs LDP for PW 
> signalling has brought up a number of the same points raised 
> during the BGP vs LDP debate for VPLS, e.g. one protocol is 
> better than two, if an operator already uses X for Y then it 
> makes sense to use X for Z if it performs the same function 
> as the alternative, etc. The outcome of that debate was that 
> both proposals were progressed to WG document status and both 
> have been deployed out in the field but I'm not aware of 
> either one being declared mandatory. Again, why mandate a PW 
> signalling protocol but not a VPLS signalling protocol (I'm 
> aware this question is out of scope of the PWE3 WG, but it is 
> related because the L2VPN WG uses PWs).
>
[Sasha] Well, neither method has been accepted as an RFC yet.:-)
And the L2 VPN people have invested substantial effort in splitting the
problem
space so that each method addresses its own part of it... and only then
accepted the two drafts as WG documents. 
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.