Subject: Re: RSVP-TE and PW

From: Stewart Bryant <[email-masked]>
Date: Fri, 01 Oct 2004 07:55:56 +0100

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

---

From: "Nurit Sprecher" <[email-masked]>
Date: Fri, 1 Oct 2004 11:32:38 +0200

Thanks Eric for your response.
Please see my comments/questions in-line.
Nurit.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Wednesday, September 29, 2004 15:13
To: Nurit Sprecher
Cc: [email-masked]
Subject: Re: [PWE3] RSVP-TE and PW 

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: Right, but this would probably not work in inter domain (when tunnel-switching). 

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.

Nurit: Agree. 

If we were sending TCP connections through a TE tunnel, you wouldn't propose
to replace TCP with RSVP-TE, would you?
Nurit: It could be. I guess that you mean to open a TCP session between two PE peers for each tunnel between them. And how does it work with a 1:1 FRR protected tunnel (especially when using the path specific mechanism)? Should we multiplex the TCP session at each detour? And still we should have a mechanism at the Egress to sense from which instance of the tunnel the traffic is actually coming from.
What is the benefit of the TCP over the RSVP-TE? Why is the reason for the strong objection for using RSVP-TE for PWs?

---

From: "Nurit Sprecher" <[email-masked]>
Date: Fri, 1 Oct 2004 11:41:25 +0200

Hi Eric,
I absolutely agree with you that QoS relates to the AC. But when the PW transmits across multiple tunnels (muin ltiple domains), the QOS information is required in order to select the end-to-end best route and to 'allocate resources' within the tunnel. As I said in my previous mail, if the tunnels are considered as point-to point links and their TE attributes and their actual load are distributed via the IGP-TE protocol, maybe using the PCE mechanism, the best end-to end route for the PW's traffic can be selected. 
Nurit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric Rosen
Sent: Wednesday, September 29, 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

---

From: "Nurit Sprecher" <[email-masked]>
Date: Fri, 1 Oct 2004 11:48:40 +0200

In addition to the below, also when using a TCP session within a tunnel, then if the tunnel fails and recovers later, the TCP session should be re-established, and all PW's information should be re-signaled. If the TCP session is established in the IGP network, then the route of the session and the route of the tunnel probably differ (when talking about TE tunnel with TE constraints). Also only one TCP session should be established between a pair of PE peers.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Wednesday, September 29, 2004 15:13
To: Nurit Sprecher
Cc: [email-masked]
Subject: Re: [PWE3] RSVP-TE and PW

Nurit: Agree.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 1 Oct 2004 10:46:20 -0400

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 

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Friday, October 01, 2004 2:56 AM
> To: Sasha Vainshtein
> Cc: [email-masked]; [email-masked]; [email-masked]'

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 1 Oct 2004 21:31:53 +0200

Peter,
Thank you for a prompt and highly informative response.
Please see some comments inline.

Regards,
                  Sasha

-----Original Message-----
From: Busschbach, Peter B (Peter)
To: 'Stewart Bryant'; Sasha Vainshtein
Cc: [email-masked]; [email-masked]; [email-masked]'
Sent: 10/1/2004 4:46 PM
Subject: RE: [PWE3] RSVP-TE and PW

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

[Sasha] I agree that non-existence of an end-to-end PSN tunnel between
[Sasha] a pair of PEs is the problem PW switching tries to address. 
[Sasha] At the same time, if you PE-to-PE tunnels with the desired 
[Sasha] properties exist (as the current architecture assumes), there is
[Sasha] no need for PW switching. I also think that this is what makes PW
[Sasha] switching special to MPLS (as opposed to IP) PSN.

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.

[Sasha] I think that this already happens with2547-based L3 VPNs, 
[Sasha] even if I do not know the details.

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. 

[Sasha] Again, I agree, However,I am not sure RSVP-TE really provides
[Sasha] this kind of resilience. Please see below.

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.

[Sasha] But does it not require pre-knowledge about the potential
[Sasha] PW switching nodes? And is learning these nodes provided via 
[Sasha] RSVP-TE per se?

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.

[Sasha] I think that this is a very good question. The need for intra-AS
[Sasha] PW switching, if it exists, would assume that intra-AS PE-to-PE
[Sasha] tunnels with the desired properties cannot be created.
[Sasha] I do not see at this moment, why this should be the case,
[Sasha] and, IMHO, this point clearly deserves clarification.

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

[Sasha] I would be glad if we could say more, e.g., complie a list of
[Sasha] issues (starting with the need for intra-AS PW switching) that
[Sasha] should be resolved in order to answer the question of
[Sasha] applicability of the RSVP-TE PW signaling approach. 

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

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 4 Oct 2004 17:25:29 +0200

May be this question is out of 3d anyway, how can I cope with multicast
traffic?

There is an ID about multicast extension for RSVP-TE that allows the
creation of p2mp tunnel but AFAIK there is no way (using LDP) to provision
p2mp PW.

So I have a tunnel protocol with the possibility to set-up p2mp but i
haven't the possibility to signal p2mp pw.

Best Regards

Diego

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 04 Oct 2004 17:50:10 +0100

> May be this question is out of 3d anyway, how can I cope with multicast

What sort of multicast traffic?

- Stewart

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 4 Oct 2004 13:55:49 -0400

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
>
>
> Sent: 29. september 2004 15:27
> To: Diego Caviglia

---

From: "David Allan" <[email-masked]>
Date: Mon, 4 Oct 2004 14:37:48 -0400

There's somthing to be learned from the way victors write history.... ;-)

cheers
Dave

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas D. Nadeau
> Sent: Monday, October 04, 2004 1:56 PM
> To: Benny Ammitzboll
> Cc: [email-masked]; pwe3; Stewart Bryant <stbryant
> 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 
> 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
> 
> 
> 
> > Therefore I find the question raised by Diego relevant - 
> although it 
> > is probably too late.
> >
> > /Benny
> >
> >
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of 
> > Eric Rosen
> > But I  don't think there is  any notion of QoS  which is 
> specific  to 
> > the PW
> > 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
> > pass it off. The only QoS  requirement for the PW signaling 
> protocol 
> > is that
> > RSVP-TE has  no advantage over LDP  with respect to the  
> carrying of 
> > objects

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 4 Oct 2004 18:19:38 -0400

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

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.

Peter

> From: Thomas D. Nadeau [mailto:[email-masked]]
> although it is

---

From: [email-masked]
Date: Tue, 5 Oct 2004 10:36:33 +0100

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?

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

> Sent: 04 October 2004 18:56
> To: Benny Ammitzboll

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 5 Oct 2004 12:13:37 +0200

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 5 Oct 2004 13:20:51 +0200

Neil and all,
Please see a brief comment inline below (marked [Sasha]).
I have snipped the parts of the message that, IMO,
do not deal directly with this issue.

Regards,
                     Sasha.

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: 10/5/2004 11:36 AM
Subject: RE: [PWE3] RSVP-TE and PW 

... snipped ...

[Sasha] One point that seems to me to be missing is the implicit 
[Sasha] assumption that co-ps networks work all by themselves. This may be
[Sasha] correct for some of them (e.g., FR) but, IMO, this is de-facto 
[Sasha] incorrect for MPLS (even if you treat it as a co-ps network), 
[Sasha] since it (again, de-facto) exists side-by-side with IP and hence
[Sasha] uses IP (and only IP!) in all its signaling protocols.
[Sasha] To be more specific, most devices I'm aware of can treat MPLS
[Sasha] as an add-on capability on their IP interfaces.
[Sasha] One can argue that this is good or bad architecturally,
[Sasha] but this is more or less the reality, and trying to change
[Sasha] it (if you believe it is bad) would be very expensive.
[Sasha] And it will become even more expensive as various IP-based
[Sasha] things (like LSP ping) become deployed...
[Sasha] At the same time, IMHO, as long as this situation goes on, there
[Sasha] is no real justification for OOB (or, to be more specific, 
[Sasha] OOB-only).
[Sasha] My 2c.
[Sasha] signaling for MPLS.

... snipped to the end ...

---

From: [email-masked]
Date: Tue, 5 Oct 2004 13:40:32 +0100

Sasha et al,

Please see below...

> [Sasha] signaling for MPLS.

I agree that IP and MPLS share an incestuous relationship.  However just because IP & MPLS exist side-by-side does not mean that OOB control is not required/justified.  For example in a standalone MPLS 2547 VPN deployment (i.e. where a provider has built a MPLS network that is used solely to provide 2547 VPNs and nothing else) the IP network is basically just used to control the MPLS network then there is no reason to mandate that the control plane layer network (i.e. IP) has to be inband with the data plane layer network (i.e. MPLS).

IMO the incestuous relationship between IP & MPLS is irrelevant, the reason that it is/would be expensive at the present time to take the control plane OOB is because of the implicit assumption that the control plane is always carried inband (and the amount of kludges/protocols that rely on this assumption).  What we need to start doing is recognising that service providers see a need for OOB control and start moving towards that goal, rather than just carrying on as in the past because it is the path of least resistance.

One final point - the GMPLS folks seem to have managed to get IP (as a control plane) and GMPLS (as a data plane) decoupled.  Given the similarity between MPLS & GMPLS it would not appear to me to be a insurmountable task to get an OOB control plane for MPLS (or any co-ps layer network).

Ben

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 5 Oct 2004 15:02:30 +0200

Ben,
Thank you for a prompot response.

I respectfully disagree with your position on MPLS-IP relationship as
"irrelevant" (leaving aside such qualifiers as "incestous").
IMHO, it is exactly this relationship that makes MPLS a suitable
convergence technology. 

Leaving empotions aside, may I ask how do you envision an MPLS-only 
(without IP) network for 2547 services? E.g., how would it provide PE-to-PE
full mesh connectivity? 

I also am not sure (but I may be wrong, of course) to what exactly do
you refer as the "GMPLS data plane". E.g., if GMPLS is used to
set up SONET/SDH trails? 

Regards,
                   Sasha
-----Original Message-----
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Sent: 10/5/2004 2:40 PM
Subject: RE: [PWE3] RSVP-TE and PW 

Sasha et al,

Please see below...

> [Sasha] signaling for MPLS.

I agree that IP and MPLS share an incestuous relationship.  However just
because IP & MPLS exist side-by-side does not mean that OOB control is
not required/justified.  For example in a standalone MPLS 2547 VPN
deployment (i.e. where a provider has built a MPLS network that is used
solely to provide 2547 VPNs and nothing else) the IP network is
basically just used to control the MPLS network then there is no reason
to mandate that the control plane layer network (i.e. IP) has to be
inband with the data plane layer network (i.e. MPLS).

IMO the incestuous relationship between IP & MPLS is irrelevant, the
reason that it is/would be expensive at the present time to take the
control plane OOB is because of the implicit assumption that the control
plane is always carried inband (and the amount of kludges/protocols that
rely on this assumption).  What we need to start doing is recognising
that service providers see a need for OOB control and start moving
towards that goal, rather than just carrying on as in the past because
it is the path of least resistance.

One final point - the GMPLS folks seem to have managed to get IP (as a
control plane) and GMPLS (as a data plane) decoupled.  Given the
similarity between MPLS & GMPLS it would not appear to me to be a
insurmountable task to get an OOB control plane for MPLS (or any co-ps
layer network).

Ben

---

From: [email-masked]
Date: Tue, 5 Oct 2004 14:29:25 +0100

Sasha,

> (without IP) network for 2547 services? E.g., how would it 

I think you misunderstand my point (or I did not explain it well enough).  In a MPLS-only 2547 network then MPLS is used purely for forwarding customer packets (i.e. MPLS is the data plane) and IP is used purely for carrying control/management traffic for the provider (i.e. IP is the control plane).  AFAIK this is how MPLS 2547 works, it's just that the distinction is not explicitly stated anywhere.  Taking the control plane OOB does not mean that IP is no longer required, just that the IP layer network does not have to operate in band with respect to the MPLS layer network.  Similarly in GMPLS you have the control plane OOB wrt the data plane but IP is still required.  

The difference is that the OOB IP control plane is forced upon you in GMPLS because of the nature of transparent optical networks, what I am saying is that I don't any major difference in this respect betwen MPLS & GMPLS except in GMPLS you are forced to support OOB and in MPLS you have the choice of OOB or inband.

> you refer as the "GMPLS data plane". E.g., if GMPLS is used to

The GMPLS data plane consists of the end-end trails set up by the GMPLS control plane that are used to transport bits end-end (i.e. they are the SONET/SDH trails for TSC, Lambdas for LSC etc.).

Ben

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 5 Oct 2004 16:01:10 +0200

Ben,
Sorry to say, I still do not understand.
If you have and MPLS network that does not run inband IP,
how do you provide connectivity between the PEs? 
By running something like GMPLS and associated CSPF-TE in 
the OOB control network? 

Would you also deploy dedicated BGP-MP RRs in this OOB
control network for making BGP-based label distribution scalable?
What else?

And all this for just removing IP as the control plane from the
network that carries (private) IP in the data plane?

If anything, this approach looks to me like the direct opposite of the
network convergence paradigm.

Regards,
                   Sasha
-----Original Message-----
From: [email-masked]
To: Sasha Vainshtein; [email-masked]
Cc: [email-masked]
Sent: 10/5/2004 3:29 PM
Subject: RE: [PWE3] RSVP-TE and PW 

Sasha,

> (without IP) network for 2547 services? E.g., how would it 

I think you misunderstand my point (or I did not explain it well
enough).  In a MPLS-only 2547 network then MPLS is used purely for
forwarding customer packets (i.e. MPLS is the data plane) and IP is used
purely for carrying control/management traffic for the provider (i.e. IP
is the control plane).  AFAIK this is how MPLS 2547 works, it's just
that the distinction is not explicitly stated anywhere.  Taking the
control plane OOB does not mean that IP is no longer required, just that
the IP layer network does not have to operate in band with respect to
the MPLS layer network.  Similarly in GMPLS you have the control plane
OOB wrt the data plane but IP is still required.  

The difference is that the OOB IP control plane is forced upon you in
GMPLS because of the nature of transparent optical networks, what I am
saying is that I don't any major difference in this respect betwen MPLS
& GMPLS except in GMPLS you are forced to support OOB and in MPLS you
have the choice of OOB or inband.

> you refer as the "GMPLS data plane". E.g., if GMPLS is used to

The GMPLS data plane consists of the end-end trails set up by the GMPLS
control plane that are used to transport bits end-end (i.e. they are the
SONET/SDH trails for TSC, Lambdas for LSC etc.).

Ben

---

From: [email-masked]
Date: Tue, 5 Oct 2004 15:19:38 +0100

Sasha,

I'm not sure how else to explain it.  I was only trying to use MPLS 2547 as *an example* to demonstrate that a service provider could/may want to deploy an MPLS based service where IP is only used for control/management but I obviously managed to make the situation less clear.  

In my example I assume that we are talking about a MPLS layer that is co-ps and therefore the PE-PE LSPs would be signalled using a co-ps signalling protocol (i.e. RSVP-TE).

Forget about specific applications/services - the point I am trying (and failing) to emphasise is that just because MPLS requires IP for its control plane does not automatically lead to a justification for the IP control plane to be carried inband wrt the MPLS data plane.

Ben

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: 05 October 2004 15:01
> To: Niven-jenkins,B,Ben,XGH5 R; [email-masked] '
> Cc: Harrison,N,Neil,IKR2 R

---

From: [email-masked]
Date: Tue, 5 Oct 2004 15:37:21 +0100

Hi Sasha,  we do fully understand the points you have made......but you
may have to trust me on that one.

<snipped>
 
> If anything, this approach looks to me like the direct
> opposite of the network convergence paradigm.

NH=> That maybe because you have not seen further than what is here and
now.....there are alternative ways of doing things that do have
convergence (but not maybe as you think of it) as a central theme.
However, it is not appropriate, nor am I at liberty, to fully discuss
these topics here.  However, as a hint, the really big problem facing
operators is all about the fundamental economics of networking, ie the
large build/run costs of networks vs the small costs of usage.  Having
the right network arch is an enabler to this bigger commercial problem.
Have a look at this paper which describes the problem (but not the
solutions): "Pricing and architecture of the Internet: Historical
perspectives from telecommunications and transportation", A. M. Odlyzko.
A copy can be found at http://www.dtc.umn.edu/~odlyzko/doc/networks.html

regards, Neil

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 5 Oct 2004 16:34:11 +0200

Neil,
Thank you for a prompt response and an interesting
reference. I'll look it up.

Regards,
                        Sasha 

-----Original Message-----
From: [email-masked]
To: Sasha Vainshtein; [email-masked]; [email-masked]
Sent: 10/5/2004 4:37 PM
Subject: RE: [PWE3] RSVP-TE and PW 

<snipped>

regards, Neil

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 5 Oct 2004 18:03:53 +0200

Hi Eric,
                 first of all let me say thanks to  you and to all the
other guys involved in thuis thread, as I said in my first e-mail I'm
pretty new to this stuff.

Other stuff in-line.

Diego

Eric Rosen <[email-masked]> on 05/10/2004 16.50.25

Please respond to [email-masked]

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 5 Oct 2004 18:11:05 -0400

Diego, Eric,

Regarding p2mp PWs:

There are concerns that in VPLS or HVPLS solutions, the number of MAC entries in the (N-)PE could become excessively large. Therefore, it could make sense to move to a DVPLS model (as described in draft-ietf-l2vpn-signaling-02.txt, section 3.5).

In this model, the link between U-PE and N-PE carries all PWs that originate in the U-PE. Therefore, multicast or broadcast packets would be replicated multiple times on the same link. However, since the link may have limited bandwidth, this replication of identical packets might cause concerns. Hence, it could make sense to have some form of p2mp PWs, where the N-PE splits the traffic coming from the U-PE onto multiple branches.

Note that the GVPLS solution (draft-radoaca-ppvpn-gvpls-02.txt (I couldn't find a newer draft)) supports such a broadcast/multicast feature. This is not a true example of p2mp PWs, but it illustrates the idea.

Peter

> From: Diego Caviglia [mailto:[email-masked]]
> Sent: Tuesday, October 05, 2004 12:04 PM
> To: [email-masked]
> Cc: pwe3
> To:    "Diego Caviglia" <[email-masked]>
> cc:    [email-masked]
> 
> 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?
> [dc] Yes it was a typo.
> 
> 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.)
> [dc] Ok so you think that p2mp (and unidirectional PW) could 
> be something
> that will be addressed by PWE3 WG in the future?
> 
> 
> 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.
> [dc] Yes but in VPLS you have to split traffic at the PE that 
> may be is not
> the best place to do that.
> 
> 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.
> [dc] I agree I was trying to understand if it something 
> interested in p2mp
> PW.
> 
> 
> 
> 
> 
> 
> 
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 Oct 2004 00:34:33 +0100

Hi all,

PMFJI. I try to whenever I see the G-word used.

RSVP-TE is a control plane signaling technology used to install MPLS LSPs in packet
switching networks.

The "GMPLS data plane" is not a very useful term IMHO because GMPLS-RSVP-TE signaling can
be used to install LSPs in a variety of network technologies. Popularly, this is
considered to be limited to optical networks (lambda switching and TDM) but this is not
the case. GMPLS signaling is fully applicable to a wide range (or hierarchy) of switching
technology from (at the coarsest granularity) port switching, down through waveband and
lambda switching, passed TDM and layer 2 switching, to MPLS packet switching (at the
finest granularity).

This last point is very important since it says that GMPLS signaling technology can be
used to install LSPs in packet switched networks.

Yet, GMPLS signaling (which is built upon RSVP-TE) includes some of the mechanisms
described as necessary and missing. Not least among these is the ability to signal in
control plane channels that are both logically and physically diverse from the data plane
channels.

But don't think that GMPLS signaling is some radical new signaling technique. It isn't. It
is just a logical (some would say evolutionary) development of RSVP-TE.

Thus, there is no need to talk about getting MPLS to do the same 'decoupling' as GMPLS has
achieved. GMPLS *is* the decoupling that you want.

GMPLS is worked on by the CCAMP working group who would, I'm sure, be happy to discuss
your requirements and to suggest ways that GMPLS signaling could provide the functional
support needed by PWE3.

Cheers,
Adrian

Sasha...
> I also am not sure (but I may be wrong, of course) to what exactly
> do you refer as the "GMPLS data plane". E.g., if GMPLS is used to
> set up SONET/SDH trails?

Ben...
> One final point - the GMPLS folks seem to have managed to get
> IP (as a control plane) and GMPLS (as a data plane) decoupled.
> Given the similarity between MPLS & GMPLS it would not appear
> to me to be a insurmountable task to get an OOB control plane for
> MPLS (or any co-ps layer network).

---

From: [email-masked]
Date: Wed, 6 Oct 2004 08:33:27 +0100

Hi Adrian....rather glad you 'PMFJI'd' on this topic.....some additional
remarks below.

> Behalf Of Adrian Farrel
> Sent: 06 October 2004 00:35
> To: [email-masked]
> RSVP-TE is a control plane signaling technology used to 
> install MPLS LSPs in packet switching networks.
> 
> The "GMPLS data plane" is not a very useful term IMHO because 
> GMPLS-RSVP-TE signaling can be used to install LSPs in a 
> variety of network technologies.
NH=> I think it is actually rather important to be clear about the
data-plane aspects......as there are some important diffences between
the 3 modes.  However, a key observation is that with co-cs mode
technologies (like SDH and OTNs) the control and management protocols
are forced to reside in their own co-cs network partition that is
disjoint to the traffic's co-cs data-plane network.  Now this has very
significant implications across all the functional components of *each*
data-plane.....and in particular the control/management protocols are
likely to be using a cl-ps mode of operation in their network partition,
but they act to set-up/take-down/manage co-cs trails in the traffic
data-plane, ie there are 2 fundamentally different network designs
operating in the same 'technology'.

> Popularly, this is 
> considered to be limited to optical networks (lambda 
> switching and TDM) but this is not the case. GMPLS signaling 
> is fully applicable to a wide range (or hierarchy) of 
> switching technology from (at the coarsest granularity) port 
> switching, down through waveband and lambda switching, passed 
> TDM and layer 2 switching, to MPLS packet switching (at the 
> finest granularity).
> 
> This last point is very important since it says that GMPLS 
> signaling technology can be used to install LSPs in packet 
> switched networks.
NH=> I agree.  I tried to make this same point in an earlier posting, ie
a similar control/management-plane design philosophy can be applied to
the co-ps mode as the co-cs mode....and there are indeed some important
benefits from doing so.  There are, however, some key differences
between the 2 modes in the traffic data-plane, eg the link-connection
IDs are abstract in the co-ps mode but they must take on a
time/space/freq semantic in the co-cs mode, there are no QoS classes in
the co-cs mode (this is a *very* significant simplification), the
defects are different (and so the OAM required is a little different),
etc......however, I do agree with you that one can apply a very similar
OOB design philosophy for the control/management-plane in the co-ps mode
as one can (and is indeed forced to do) for the co-cs mode.
> 
> Yet, GMPLS signaling (which is built upon RSVP-TE) includes 
> some of the mechanisms described as necessary and missing. 
> Not least among these is the ability to signal in control 
> plane channels that are both logically and physically diverse 
> from the data plane channels.
NH=> Its not just the control-plane protocol but also the
management-plane protocols.  This is an important observation (eg for
security) and is something we are very keen to see adopted as a general
principle in core co-cs and co-ps networks.
> 
> But don't think that GMPLS signaling is some radical new 
> signaling technique. It isn't. It is just a logical (some 
> would say evolutionary) development of RSVP-TE.
NH=> Agreed.  But the co-cs mode does force things like OOB.
> 
> Thus, there is no need to talk about getting MPLS to do the 
> same 'decoupling' as GMPLS has achieved. GMPLS *is* the 
> decoupling that you want.
NH=> I can but agree....nice to hear someone else saying this!
> 
> GMPLS is worked on by the CCAMP working group who would, I'm 
> sure, be happy to discuss your requirements and to suggest 
> ways that GMPLS signaling could provide the functional 
> support needed by PWE3.
NH=> Yes please Adrian......but please note that the stuff I have been
harping on about since as long as I can remember must also be
considered, eg like the OAM is different in the 3 modes, like the
client/server adaptation functions are not the same for all modal
combinations, like there are no QoS/traffic classes in the co-cs modes,
etc.  Further, its not for fun that we are very strong advocates of
functional modelling (ie the G.805/809 stuff for the data-plane and
G.8080 for the control-plane), and it would be great if folks could try
and understand/use this stuff more.

regards, Neil
> > you refer as the "GMPLS data plane". E.g., if GMPLS is used 
> to set up 
> > SONET/SDH trails?
> 
> Ben...

---

From: [email-masked]
Date: Wed, 6 Oct 2004 11:19:42 +0100

Folks,

One last comment on this topic.

> NH=> I can but agree....nice to hear someone else saying this!

Agreed.  However the problem is IMO somewhat larger than just MPLS/GMPLS.  Folks need to start moving away from the 'IP-based mindset' that leads to the assumption that control/management will be carried inband (and therefore move away from producing fixes/features that rely on that assumption).  I would expect/hope all GMPLS folks understand this, but I'm not so sure that all MPLS & PWE3 folks do.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 6 Oct 2004 19:45:20 +0100

Hi Neil,

> rather glad you 'PMFJI'd' on this topic

Well, it's my pleasure :-)

> some additional remarks below.

> > The "GMPLS data plane" is not a very useful term IMHO
> > because GMPLS-RSVP-TE signaling can be used to install
> >LSPs in a variety of network technologies.

>NH=> I think it is actually rather important to be clear about
> the data-plane aspects......as there are some important diffences
> between the 3 modes.  However, a key observation is that with
> co-cs mode technologies (like SDH and OTNs) the control and
> management protocols are forced to reside in their own co-cs
> network partition that is disjoint to the traffic's co-cs data-plane
> network.

'Disjoint' is a word we have to use carefully. Consider the fact that one could squeeze
singaling into overhead bytes (bleah!), dedicate timeslot or lambda, run a parallel 10/100
wire, etc., etc.

Thus it is useful to distinguish out-of-band and out-of-fiber.

I think that what you are saying is that non-packet technologies necessarily require that
the control plane is out-of-band.

> Now this has very
> significant implications across all the functional components
> of *each* data-plane.....and in particular the control/management
> protocols are likely to be using a cl-ps mode of operation in their
> network partition, but they act to set-up/take-down/manage co-cs
> trails in the traffic data-plane, ie there are 2 fundamentally different
> network designs operating in the same 'technology'.

OK. No argument with that.
And we can follow this model even if the data plane happens to use the same technology as
the control plane.

> OOB design philosophy for the control/management-plane in the co-ps
> mode as one can (and is indeed forced to do) for the co-cs mode.

OK. Sounds like moderately violent agreement.

> management-plane protocols.  This is an important observation
> (eg for security) and is something we are very keen to see
> adopted as a general principle in core co-cs and co-ps networks.
>

> NH=> Agreed.  But the co-cs mode does force things like OOB.

Absolutely.
As I say, however, OOB is not necessarily out-of-fiber.

Maybe the point (in packet networks) is to notice that GMPLS operates on TE links. The
topology of TE links does not need to follow the IP topology at all. Thus, although it is
possible (maybe even current practice) to exactly overlay the data and control networks in
a packet environment, it is in no way compulsory and it is a network management choice.

> NH=> I can but agree....nice to hear someone else saying this!

Hoorah! May I sell you some of this apple pie I made earlier?

> > GMPLS is worked on by the CCAMP working group who
> > would, I'm sure, be happy to discuss your requirements and to
> > suggest ways that GMPLS signaling could provide the functional
> > support needed by PWE3.
>
> NH=> Yes please Adrian.

OK. looking forward to seeing the emails.

>.....but please note that the stuff I have been
> considered, eg like the OAM is different in the 3 modes,
> like the client/server adaptation functions are not the same for
> all modal combinations, like there are no QoS/traffic classes in
> the co-cs modes, etc.

Agreed that all of these things need further investigation and clarification.

> Further, its not for fun that we are very strong advocates of
> G.8080 for the control-plane), and it would be great if folks could
> try and understand/use this stuff more.

Followers of CCAMP will know that a fair amount of effort has been put into understanding
exactly how G.8080 and G.7713/5 relate to GMPLS.

Cheers,
Adrian

---

From: Peter Willis <[email-masked]>
Date: Thu, 07 Oct 2004 17:16:46 +0100

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

The early phone network just connected wires to wires in a provisioned mode 
i.e. call the operator and they connected 2 wires together. And that was not a 
network?!

And if by "static mode" you mean we enter static configuration to stitch 
together millions of wires in hundreds of boxes then that would be a massive 
step backwards for service providers.

Peter Willis,
Office of the BT Group CTO.

---

From: Peter Willis <[email-masked]>
Date: Fri, 08 Oct 2004 09:05:54 +0100

So in other words are we saying that to do anything useful with PW stitching 
i.e. create a network, we need to go to the L2VPN WG? 

Is anything happening in the L2VPN WG to address PW stitching?

Peter.
> Peter,
> 
> I just want to add to Tom's comment , that I believe this is just a 
> starting point. Like PW where used to build VPLS, or MPLS to build GMPLS.
> There should be nothing in the pw-switching draft preventing anyone from 
> creating a new network layer if they wish.
> PW switching connects wires with only only going to one fixed 
> destination, which does not change. That would make a pretty boring 
> phone network wouldn't it ?
> :-)
> Anyway I believe that the PW switching draft should be targeted as an 
> informational RFC, as it does not really even create a new protocol.
> Whether it is useful or not is a matter of personal opinion.
> 
> Luca
> 
> 
> Thomas D. Nadeau wrote:
> 
> >
> >     Peter, I don't think that is the point he was
> > making, at least not as I understood it.
> > I don't see stitching PWs together as anything
> > different than bridging/patching two enet segments
> > together.  This seems to fit well within the PWE3
> > charter of p2p pwe3s.  HOWEVER, if we start talking about
> > automatically patching these together, then this requires
> > more intelligence such as the form of some
> > routing protocol. This is the purview
> > of the L2VPN WG, which I do agree constitutes
> > another 'layer'.
> >
> >     --Tom
> >
> >
> >>
> >>>>

---

From: [email-masked]
Date: Fri, 8 Oct 2004 09:47:41 +0100

Tom,

> together.

I must admit I am quite shocked by this response. I fail to see how you can consider PW stitching to be analogous to bridging/patching two Ethernet segments together.

- (Transparent) bridging occurs in the data plane using MAC addresses and allows connectionless flows to be transmitted between different Ethernet segments. No configuration or control plane functions are required at the Ethernet layer other than spanning tree to protect against loops and the actual physical connection (also requires VLAN configuration if employed).

- PW stitching requires control/management plane functions to establish a P2P connection and allows MPLS packets to be transmitted between the connections source/sink termination points. Before any packets can be forwarded MPLS labels must be signalled or manually configured and before that a route/path between the source/sink PW termination points must be calculated/selected if alternative switching points between the source and sink exist.

Considering the fact that:

Control/management plane configuration/maintenance = operational cost

please can you clarify why it is that you consider the differences between the two to be insignificant, and also explain what the similarities are (beyond the fact that two network partions are being connected).

Thanks,
Richard

---

From: [email-masked]
Date: Fri, 8 Oct 2004 10:50:22 +0100

Luca,

> There should be nothing in the pw-switching draft preventing 
> anyone from creating a new network layer if they wish.

If a provider uses PW-switching they are creating a new network layer whether they wish to or not.

Please consider the following simple examples that illustrate server layer topologies/trails (i.e. tunnel LSPs), which may be used for carrying switched PWs:

(i)  [U-PE1]----[S-PE1]-----U-PE2]

(ii) [U-PE1]----[S-PE1]-----U-PE2] 
         \                   /
          \-----[S-PE2]-----/

To establish a MH-PW in (i), because there is only one switching node, only one path/route exists (i.e. there is no need for route/path selection) but the route/path must still be determined either by using dynamic protocols, manual methods or OSS, i.e. the PW switching node must be identified before the two separate PWs can be 'stitched' together.

To establish a MH-PW in (ii), two alternate route/paths exist and therefore the best route must be calculated and selected before establishing the two separate PWs and stitching them together. 

Anyway, whether you consider PW switching to create a new layer or not, PW switching introduces new requirements that do not apply to single hop PWs. From a technical perspective PW switching requires:

o Switching node discovery
o Route calculation and selection if alternative switching nodes exist
o Stitching separate PWs together
o Interworking at switching points, including:
  - Data plane interworking (e.g. L2TP to MPLS)
  - Control plane interworking (e.g. L2TP to LDP)
  - OAM message interworking

>From a business perspective, each of these new functions that are required adds operational cost, especially if an operator needs to develop their own OSS to provision/maintain switched PWs.

I'm not saying that there isn't a need for PW switching. On the contrary, if providers decide to push MPLS out to the edge aggregation layer resulting in a network with tens of thousands of PEs, then PW switching offers one potential solution to scale end-to-end PWs in the control plane (whilst keeping access aggregation device costs at a feasible level). 

I'm just saying that whether you believe PW switching creates a new layer or not, it introduces a number of new requirements that must be addressed for PW switching to become a viable solution. Hopefully these will be identified in the PW switching requirements draft that is currently being worked on.

Regards,
Richard

---

From: [email-masked]
Date: Fri, 8 Oct 2004 10:56:48 +0100

Luca,

> phone network wouldn't it ? :-)

I don't think this analogy makes sense, you are comparing connection hold times to network functionality, i.e. you are comparing apples to pears.

The above could be re-written "Voice switching connects wires only going to one fixed destination, which does not change." With the 'does not change' referring to the duration of the call.

- Prior to call setup, a user selects which number they want to call, once the call is made and the connection established, the connection to the fixed destination exists until the call is taken down.

- Prior to PW establishment, an operator selects which U-PEs they need to connect, once the PW is established, the connection to the fixed destination exists until the PW is taken down.

The connection hold times may be different, but the network functionality (i.e. the ability to establish a connection between source/sink termination points) is the same.

Regards,
Richard

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 8 Oct 2004 20:23:50 +0200

Richard and all,
Please see a few comments inline below (marked [Sasha]).
I've snipped some text to make the message readable.

Regards,
          Sasha

-----Original Message-----
From: [email-masked]
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Sent: 10/8/2004 11:50 AM
Subject: RE: [PWE3] RSVP-TE and PW

... snipped ...

Anyway, whether you consider PW switching to create a new layer or not,
PW switching introduces new requirements that do not apply to single hop
PWs. From a technical perspective PW switching requires:

o Switching node discovery
o Route calculation and selection if alternative switching nodes exist
o Stitching separate PWs together
o Interworking at switching points, including:
  - Data plane interworking (e.g. L2TP to MPLS)
  - Control plane interworking (e.g. L2TP to LDP)
  - OAM message interworking
[Sasha] I agree with these points and would even add a few, e.g.:
[Sasha] o Detection of the switching node failure and appropriate
[Sasha]   correvtive actions to provide resilientce (note that PW segments
[Sasha]   presumably can rely on the PSN resilience mechanisms, but
[Sasha]   stitching node failures are different)
[Sasha] o Per-segment OAM mechanisms as opposed to end-to-end
[Sasha]   PW OAM)
[Sasha] There can be more... and, IMHO, just as these problems EXIST [Sasha]
regardless of whether PW stitching is called a new network
[Sasha] layer or not, neither is the SOLUTION provided 
[Sasha] by adopting this or that terminology. 

... snipped ...

I'm just saying that whether you believe PW switching creates a new
layer or not, it introduces a number of new requirements that must be
addressed for PW switching to become a viable solution. Hopefully these
will be identified in the PW switching requirements draft that is
currently being worked on.

[Sasha] I would be happy to join you in this hope. But I have
[Sasha] not seen much progress yet.

---

From: [email-masked]
Date: Tue, 12 Oct 2004 10:44:40 +0100

Stewart,

> PWE3 is only concerned with the provision and operation of the
> wire emulation. The formation of a collection of wires into a
> network is the domain of L2VPN WG.

Please can you tell me where (i.e. which charter/draft/RFC) this is stated.

Also, please can you confirm exactly what is in scope and what is out of scope? Are you saying that:

(i)  PW switching is out of scope of PWE3
(ii) Signalling of individual PWs used to create switched multihop PWs is in scope, but the routing, end-to-end signalling, and interworking are out of scope?

I assume its not (i), otherwise why was the PW switching draft allowed to be submitted to PWE3, why was it agreed to start a PW switching requirements draft, and why are we discussing it on this mailing list?

If (ii) and consensus is reached that PW switching is a requirement, then due to switched PW requirements for data/control plane interworking, OAM message mapping, end-to-end signalling, etc. existing PWE3 drafts will need expanding or completely new drafts covering the same topics will need to be written in the L2VPN WG. 

I personally think it would make more sense to make PW switching requirements/solutions the superset and single hop PWs a subset of those requirements/solutions and to do the work in the same WG.

Regards,
Richard

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 12 Oct 2004 15:24:18 +0200

Richard, Stewart and all,

I would like to present a somewhat different point of view.

IMHO a multi-hop PW is still a single PW even if it is composed of multiple
segments.

If we can agree on that, PROVISIONING - all the way through a known set of
"switching nodes" - 
and OPERATION of multi-hop PWs would remain in the scope of the PWE3 WG.
E.g.,
if we decide that, in addition to the current PE-to-PE VCCV mechanism, we
need an OAM
mechanism limited to a single segment of a multi-hop PW, I would expect that
the definitions
would be provided by the PWE3.

At the same time, DISCOVERING the set of switching nodes that will be used
by a given
multi-hop PW would be  out of scope of the PWE3. I am not sure that this
falls within the 
scope of the L2VPN WG either, but this is a different issue.

My 2 c.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 12, 2004 11:45 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Also, please can you confirm exactly what is in scope and 
> what is out of scope? Are you saying that:
> 
> (ii) Signalling of individual PWs used to create switched 
> multihop PWs is in scope, but the routing, end-to-end 
> signalling, and interworking are out of scope?
> 
> I assume its not (i), otherwise why was the PW switching 
> draft allowed to be submitted to PWE3, why was it agreed to 
> start a PW switching requirements draft, and why are we 
> discussing it on this mailing list?
> 
> If (ii) and consensus is reached that PW switching is a 
> requirement, then due to switched PW requirements for 
> data/control plane interworking, OAM message mapping, 
> end-to-end signalling, etc. existing PWE3 drafts will need 
> expanding or completely new drafts covering the same topics 
> will need to be written in the L2VPN WG. 
> 
> I personally think it would make more sense to make PW 
> switching requirements/solutions the superset and single hop 
> PWs a subset of those requirements/solutions and to do the 
> work in the same WG.
> 
> Regards,
> Richard
> 
> 
>  
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 12 Oct 2004 09:38:45 -0400

> Sent: Monday, October 11, 2004 8:05 AM
> To: Luca Martini
> Cc: Thomas D. Nadeau; [email-masked]; 
> [email-masked]; Peter
> Willis; [email-masked]; [email-masked]
> Luca Martini wrote:
> > Peter Willis wrote:
> >> So in other words are we saying that to do anything useful with PW 
> >> stitching i.e. create a network, we need to go to the L2VPN WG?
> >>  
> >>
> > yes.
> > 
> > Luca
> 

Stewart,

In my view, a Multi-hop PW is a single wire, not a collection of wires. That is one reason why I think the work belongs in PWE3 and not in L2VPN. More importantly, however, the aspects of MH-PWs that require further standardization, have nothing to do with the emulated service. 

E.g.

- L2VPN works on the discovery of PEs that participate in a L2 service. On the other hand, MH-PWs require a discovery/routing mechanism to determine intermidiate switching points, independent of the L2 service.

- L2VPN works on the signaling of l2vpn related information. MH-PWs require a signaling solution to tie together multiple segments, independent of the L2 service.

Peter

Peter
 
> >>> starting point. Like PW where used to build VPLS, or MPLS 
> to build 
> >>> GMPLS.
> >>> There should be nothing in the pw-switching draft 
> preventing anyone 
> >>> from creating a new network layer if they wish.
> >>>>> And if by "static mode" you mean we enter static 
> configuration to 
> >>>>> stitch
> >>>>> together millions of wires in hundreds of boxes then 
> that would be 
> >>>>> a massive

---

From: [email-masked]
Date: Tue, 12 Oct 2004 14:58:33 +0100

Hi Peter,
> > PWE3 is only concerned with the provision and operation of the wire 
> > emulation. The formation of a collection of wires into a network is 
> > the domain of L2VPN WG.
> 
> Stewart,
> 
> In my view, a Multi-hop PW is a single wire, not a collection 
> of wires. That is one reason why I think the work belongs in 
> PWE3 and not in L2VPN. More importantly, however, the aspects 
> of MH-PWs that require further standardization, have nothing 
> to do with the emulated service. 
> 
> E.g.
> 
> - L2VPN works on the discovery of PEs that participate in a 
> L2 service. On the other hand, MH-PWs require a 
> discovery/routing mechanism to determine intermidiate 
> switching points, independent of the L2 service.
> 
> - L2VPN works on the signaling of l2vpn related information. 
> MH-PWs require a signaling solution to tie together multiple 
> segments, independent of the L2 service.
> 
> Peter
NH=> You have nicely described the behaviour of a layer network here
(that is also independent of it's client).  If folks managed to get
their head round what is going on here in func arch terms it is this:

In the 'old' PW 1-hop world we had a (single) client X link-connection
supported off a MPLS trail (or IP connectionless trail).

In the proposed 'new' PW N-hop world we have a (single) client X
link-connection supported off a PW trail, where *each* PW
link-connection (there are N in the PW trail) is in turn now supported
off a MPLS trail (or IP connectionless trail).

regards, Neil

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Oct 2004 18:14:28 +0100

> Please can you tell me where (i.e. which charter/draft/RFC) this is stated.

 From the PWE3 charter

"The basic idea of this working group is to develop standards for
the encapsulation and service emulation of pseudo wires: encapsulating
service-specific PDUs arriving at an ingress logical port and carrying
them across a tunnel, managing their timing, order or other aspects
entering and leaving the tunnel, to emulate the behavior and
characteristics of the service as well as possible."

"From the customer perspective, the pseudo wire is perceived as an
unshared link or circuit (or the appropriate unit) of the chosen
service (although it will not be a perfect emulation of the service)."

 From the L2VPN charter

"2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
point-to-point Ethernet) across an IP and an MPLS-enabled IP network."

"As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG."

When we only had single hop wires it was therefore quite clear
PWE3 owned pt-pt wires, and L2VPN owned forming them into network.
Now we are considering joining two wires end to end for various
operational/administrative reasons. I think that so long as the
object is basically a "repeater" it belongs in PWE3, but as
soon as you want to automatically create it, then it belongs
in L2VPN.

> (i)  PW switching is out of scope of PWE3

Yes - I think that belongs in L2VPN

> (ii) Signalling of individual PWs used to create switched multihop 
> PWs is in scope, but the routing, end-to-end signalling, and 
 > interworking are out of scope?

Yes, although in the specific case of a "wire splice" I am not sure.
Luca's draft is really just putting into place the things that
you need to "splice" or "repeat" a wire under static configuration.
As such I think it belongs in PWE3.

> 
> I assume its not (i), otherwise why was the PW switching draft 
> allowed to be submitted to PWE3, why was it agreed to start a PW 
> switching requirements draft, and why are we discussing it on 
> this mailing list?

You have to start somewhere.

> 
> If (ii) and consensus is reached that PW switching is a requirement, 
> then due to switched PW requirements for data/control plane 
> interworking, OAM message mapping, end-to-end signalling, etc. 
> existing PWE3 drafts will need expanding or completely new drafts 
> covering the same topics will need to be written in the L2VPN WG. 

The Internet ADs and WG chairs need to figure out what work
should be done in which WG.

> 
> I personally think it would make more sense to make PW switching 
> requirements/solutions the superset and single hop PWs a subset 
> of those requirements/solutions and to do the work in the same WG.
> 

There is a difference between the wires and the control plane that
instructs their creating and interconnection, so that's not clear.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Oct 2004 18:29:04 +0100

Neil

> supported off a MPLS trail (or IP connectionless trail).

Correct

> off a MPLS trail (or IP connectionless trail).

Correct if we do switching rather than splicing (splicing
was Luca's original proposal). Most networks have splices without
introducing a new full-blown network layer, although I do admit
they mostly have OAM issues of various sorts.

So how would structue the work if:

a) We just do splicing/repeating and no more.

b) We do PW switching (which as far as I can see is not chartered
anywhere in IETF).

- Stewart

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 12 Oct 2004 13:29:39 -0400

Hi Eric,

It is a little late, but I had a few comments on your email from last week.

Peter

> Sent: Monday, October 04, 2004 1:41 PM
> To: Busschbach, Peter B (Peter)
> Cc: 'Stewart Bryant'; Sasha Vainshtein; [email-masked];
> [email-masked]'
> 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.

I am afraid that my formulation has given the wrong impression. I did not mean to suggest that the ingress PE should identify the entire end-to-end path. In my view, two things are necessary:

a) The signaling message must identify the egress PE (which would require an ERO, even if it would only contain the end point of the path).

b) The ingress PE must be able to select autonomously the first PW switching point to which it forwards the signaling message.

It is possible that a signaling message identifies more than one PW switching point, but I think it would be more likely that the first PW switching point uses the node id of the egress PE to determine the next PW switching point, and so on. 

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

Perhaps my use of the word "solution" was inappropriate. However, if you read my entire email instead of the single line that you quote, it must be clear that my point was that RSVP-TE as a *signaling* protocol has properties that could make it suitable for MH-PW setup within a Service Provider network. I did not claim in any way that it is a sufficient solution to the entire problem. Obviously, the routing aspects of MH-PW setup are not met by RSVP-TE. 

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

I agree that we need to get a better understanding of the problem to be solved before we evaluate solutions.

Just to put things into context: I wrote my email in response to an email thread in which one of the overriding arguments seemed to be that it would make sense to use RSVP-TE for today's single-hop PWs because of RSVP-TE's role in the setup of PSN tunnels. I don't agree with that argument and I thought it would be helpful to give other reasons why RSVP-TE might be considered in the future.

So, how about the claim that RSVP-TE is preferable?

If you only look at PEs, I agree with your statement. Current implementations are based on LDP and it does not make much sense to introduce a different protocol just because there is a need to carry QoS- and/or ERO-related objects.

However, if you  add QoS- and ERO-related objects to LDP, it becomes CR-LDP. That may not matter much for PE implementations, but it seems to me that it does have impact on IP/MPLS networks in general.

PW switching points perform label switching based on PW labels. Therefore, they treat MH-PWs as they do any regular LSP. (There are minor differences: label merging and PHP is not allowed on MH-PWs, and for scaleability reasons it is preferable to tunnel MH-PWs through larger PSN tunnels). Do we really want to end up in a situation in which LSRs support RSVP-TE to set up regular LSPs and CR-LDP if they act as PW switching points?

>From an implementation perspective, it might not be a big deal. Many switches may support CR-LDP already as a left-over from the days when the RSVP-TE - CR-LDP controversy was still undecided. But going forward, do we really want to require support for both protocols? 

As mentioned before, the requirements for MH-PWs are not clear yet. However, to summarily dismiss concerns about the re-introduction of CR-LDP seems short-sighted.

---

From: [email-masked]
Date: Tue, 12 Oct 2004 21:28:09 +0100

Stewart,

> was Luca's original proposal). 

I haven't read Luca's original proposal for PW splicing, can you tell me how it differs from his PW switching draft?

> Most networks have splices without introducing a new 
> full-blown network layer, although I do admit they mostly 
> have OAM issues of various sorts.
> 

Again, what is the difference between splicing/repeating and switching? Surely in both cases a splicing/switching node must perform a label lookup on ingress to determine the egress? If so, whether a packet is repeated or switched a switching/splicing node must still be configured with or dynamically learn what the next hop/egress interface is for an incoming packet.

This brings us back to the question over the routing/discovery functions. An operator must perform these functions in order to establish a multi-hop PW, the only question is over how the functions are performed, the options being via manual configuration, OSS, or dynamic protocols.

So is it the case that option a) above means that routing/discovery for multi-hop PWs is out of scope, and therefore must be performed using manual configuration, OSS or dynamic protocols defined in another WG? If so, what about other PW splicing requirements such as interworking (i.e. MPLS<->L2TP), resilience (e.g. to protect against splicing node failure), and OAM?

Regards,
Richard

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 12 Oct 2004 16:38:55 -0400

Hi Tony,

Sorry for the late response.

I agree with your general observation, but do have some questions regarding the details.

In my earlier emails, I have implicitly made the assumption that a Multi-hop PW is essentially an LSP in its own right. It exists between two PEs and it is aggregated in Tunnel LSPs. Since the Tunnel LSPs may not extend end-to-end, there is a need for intermediate nodes that do PW switching (i.e. label switching based on the PW Label).

If I understand you correctly, you propose to stick with Single-Hop PWs and to solve the scaleability problems related to Tunnel LSPs. With an increasing number of PEs, and thus with an increasing number of Tunel LSPs, it could make sense to aggregate multiple Tunnel LSPs into higher-order LSPs.

If my understanding is correct, then the two solutions look practically the same. The difference is that the PW switching solution requires a two-label stack (PW Label and Tunnel LSP Label), whereas yours requires a three-label stack (ditto plus higher-order LSP label)

Is my understanding correct and if so, why do you think that it is a better approach? Why would the PW layer combat the TE layer? I wasn't aware of any restrictions in the PWE3 architecture that would prevent the merging of PW traffic and non-PW traffic on the same Tunnel LSPs. Therefore, I didn't think there would be any conflict between allocating bandwidth to MH-PWs and to other non-PW LSPs.

Peter

> From: Tony Li [mailto:[email-masked]]
> Sent: Friday, October 01, 2004 3:56 PM
> Cc: [email-masked]; [email-masked]; [email-masked]'; Sasha
> Vainshtein; 'Stewart Bryant'
> 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:
> 
> > 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.
> >
> > 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.
> >
> > rapidly established via a different route. Also, 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 
> > 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.
> >
> > 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.
> >
> > 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
> >

---

From: Tony Li <[email-masked]>
Date: Tue, 12 Oct 2004 14:51:27 -0700

>
> Is my understanding correct and if so, why do you think that it is a 
> better approach? Why would the PW layer combat the TE layer? I wasn't 
> aware of any restrictions in the PWE3 architecture that would prevent 
> the merging of PW traffic and non-PW traffic on the same Tunnel LSPs. 
> Therefore, I didn't think there would be any conflict between 
> allocating bandwidth to MH-PWs and to other non-PW LSPs.
>

Perhaps I'm misunderstanding then.  If you agree with the heirarchical 
model, then what is the purpose of using RSVP for
signalling?  All of the functionality that RSVP provides would be 
handled by lower layers (as they should be, IMHO ;-) and
PW can continue to operate in a manner oblivious to such details as 
path selection.

Put more generally, I'm trying to suggest the obverse to the end-to-end 
principle: if the middle of the network has to
do something to make things work, then the end systems shouldn't 
participate.

Tony

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 12 Oct 2004 18:33:37 -0400

Hi Tony,

I am afraid we are talking past each other. Unfortunately, I don't see how to clarify my point without writing a long, long email. 

Let's drop this issue for now. I will keep your "obverse end-to-end principle" in mind in future discussions on Multi-hop Pseudo Wires.

Peter

> Sent: Tuesday, October 12, 2004 5:51 PM

---

From: [email-masked]
Date: Wed, 13 Oct 2004 09:16:09 +0100

Richard/Stewart,

Spencer,R,Richard,XGH5 R wrote 12 October 2004 21:28

> I haven't read Luca's original proposal for PW splicing, can 
> you tell me how it differs from his PW switching draft?
> 
> Again, what is the difference between splicing/repeating and 
> switching?
NH=> Functionally the answer is 'none'.....at least in the context of
this issue (a 'repeater' in the context of ethernet is different). Do
you remember the point Peter (Willis) made about the fact that once upon
a time we used a human (an 'operator') to 'splice' PSTN link-connections
together.....well, that person was the routing/signalling/cross-connect
function.  Later Almon Strowger automated this process as he thought he
was losing business to his rivals (if folks don't know the story have a
look at http://www.wordiq.com/definition/Almon_Strowger for example).

> Surely in both cases a splicing/switching node 
> must perform a label lookup on ingress to determine the 
> egress? If so, whether a packet is repeated or switched a 
> switching/splicing node must still be configured with or 
> dynamically learn what the next hop/egress interface is for 
> an incoming packet.
> 
> This brings us back to the question over the 
> routing/discovery functions. An operator must perform these 
> functions in order to establish a multi-hop PW, the only 
> question is over how the functions are performed, the options 
> being via manual configuration, OSS, or dynamic protocols.
NH=> I suppose we could find gainful employment for a bunch of
'operators' again ;-)
> 
> So is it the case that option a) above means that 
> routing/discovery for multi-hop PWs is out of scope, and 
> therefore must be performed using manual configuration, OSS 
> or dynamic protocols defined in another WG? If so, what about 
> other PW splicing requirements such as interworking (i.e. 
> MPLS<->L2TP), resilience (e.g. to protect against splicing 
> node failure), and OAM?
NH=> This is a slippery slope.  The fact of the matter is that a new
layer network will be created.....you can't get away from that no matter
how folks try and dress it up (though to be fair I am not sure all folks
will readily grasp this point as many don't have any functional arch
background).  That said, then all the functions one needs for a layer
network (and BTW its a co-ps mode network if anyone was wondering) will
need to be developed *if* one thinks its going to be successful.  One
can, of course, plan for failure from the outset and not do a proper
design at t=0.

regards, Neil

---

From: [email-masked]
Date: Wed, 13 Oct 2004 09:16:12 +0100

Tony/Peter,

Tony Li wrote 12 October 2004 22:51

> do something to make things work, then the end systems shouldn't 

NH=> If we assume the core technology is going to be MPLS then PW
switching is a complete nonsense IMO.  That is, one is simply using MPLS
as the switching technology.  So I agree with Tony on this point....and
AFAI can tell Peter was saying something rather similar in the snipped
bit of his mail (viz "In my earlier emails, I have implicitly made the
assumption that a Multi-hop PW is essentially an LSP in its own
right.").  However, if one wants to carry on the pretence that IP==MPLS
with the misguided egalitarian objective that 'whatever we do for MPLS
we must also do for IP' then PW switching (or at least peer-partition PW
interworking) will rear its head.

I also think there maybe some 'non-technical' reasons at play here.  For
example, I could postulate that some folks have 'done' an LDP-based
solution and LDP is not really a good signalling protocol.  So what to
do?  Can't go back and resurrect CR-LDP can we (?)....ergo the fudging
of 'PW st/witching' etc.

If there are scaling concerns, then perhaps folks ought to look hard at
why there are scaling concerns, eg are the signalling protocols at our
disposal really right for the job being asked?  (But don't confuse this
with the need for hierarchy)

regards, Neil

---

From: Benny Ammitzboll <[email-masked]>
Date: Wed, 13 Oct 2004 11:31:56 +0200

Neil,

Well said, I fully agree.

/Benny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 13. oktober 2004 10:16
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [PWE3] RSVP-TE and PW

Tony/Peter,

regards, Neil

---

From: Eric Rosen <[email-masked]>
Date: Wed, 13 Oct 2004 10:09:00 -0400

> It is  a little late,  but I had  a few comments  on your email  from last

It's never too late to try to address the substantive technical issues; this
would  be  a   much  shorter  thread  if  we   eliminated  all  the  useless
pontificating about  grand architectural issues  (not to mention  the various
attempts on all sides to question the motives of others), and focused on the
detailed technical issues.  (Peter, this complaint is not directed at you.)

> The signaling message must identify  the egress PE (which would require an
> ERO, even if it would only contain the end point of the path).  

If we merely need  to identify the ultimate endpoint of the  path, we do not
need anything like  an ERO, nor would we choose  one signaling protocol over
another simply because it provides an ERO object.  After all, it is the rare
protocol that does not provide an endpoint identifier of some sort.

> It  is possible  that  a signaling  message  identifies more  than one  PW
> switching point,  but I think  it would be  more likely that the  first PW
> switching point uses the node id of the egress PE to determine the next PW
> switching point, and so on.  

This seems reasonable, it's the  typical routing model, and does not require
an ERO.  

> if you add QoS- and ERO-related objects to LDP, it becomes CR-LDP

People keep saying that, but that just isn't true.  RSVP-TE was preferred to
CR-LDP  because  RSVP  was  already  used for  applying  network  layer  QoS
characteristics to  paths through the  network.  Unless one is  proposing to
use  LDP  for this  purpose,  one  is not  proposing  CR-LDP.   If the  only
enhancements to  LDP are the  introduction of an  opaque QoS object  and the
introduction of an endpoint identifier (wait, LDP already has that!), then I
don't think we have to worry about CR-LDP returning from the dead.

> Do we really want  to end up in a situation in  which LSRs support RSVP-TE
> to set up regular LSPs and CR-LDP if they act as PW switching points?  

I object to the formulation of  this question, as I think the "CR-LDP" stuff
is a red herring.  But of course, one could equally well ask: 

     "do we really want  to end up in a situation in  which LSRs support LDP
     to  set   up  regular  LSPs   and  RSVP-TE  if  they   support  traffic
     engineering?"  

Whoops,  that  question has  already  been answered  ;-)  So  how about  the
question: 

     "do we really want  to end up in a situation in  which LSRs support LDP
     to set up regular PWs and RSVP-TE to set up switched PWs?" 

or

     "do we really want  to end up in a situation in  which LSRs support LDP
     to set up regular LSPs and RSVP-TE to set up switched PWs?" 

I don't think that this path will  lead to any conclusion, which is why I've
been  trying to  focus on  whether RSVP-TE  actually lets  you  do something
easily  which  could not  be  easily done  with  the  existing PWE3  control
protocol.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 13 Oct 2004 11:14:02 -0400

Eric>   If the  only enhancements to  LDP are the  introduction of an 
Eric>   opaque QoS object  and the introduction of an endpoint
Eric>   identifier (wait, LDP already has that!), then I
Eric>   don't think we have to worry about CR-LDP returning from the dead.
End-point identifier: are you referring to the FEC, or is there another LDP object that can be used to identify an endpoint?

Opaque QoS: It is not opaque!! In the case of MH-PWs with associate QoS characteristics, the PW switching nodes must allocate resources to each PW. I still believe that: *if* there is a need for MH-PWs within a Service Provider network and *if* there is a need to associate QoS characteristics with PWs, then such a MH-PW looks exactly like any other traffic-engineered LSP. If RSVP-TE is the appropriate protocol to set up such LSPs, it should be the appropriate tool to set up MH-PWs with QoS characteristics.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 13 Oct 2004 12:48:18 -0400

> End-point identifier:  are you referring to  the FEC, or  is there another
> LDP object that can be used to identify an endpoint?

The  FEC  identifies  the  endpoint.   If the  currently  defined  FECs  are
insufficient for this purpose when PW  switching is done, we can discuss how
to augment them. 

> In the case of MH-PWs with associate QoS characteristics, the PW switching
> nodes must allocate resources to each PW.  

Could  you  be  specific  about  what  these resources  are  and  how  their
allocation is to be affected by the QoS parameter?

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 13 Oct 2004 13:02:25 -0400

> Sent: Wednesday, October 13, 2004 12:48 PM

Fair enough.

> allocation is to be affected by the QoS parameter?  

I meant that a PW Switching node must make sure that the bandwidth, packet loss and delay characteristics of the PW are met. In other words: if the PW switching node can switch a certain amount of bandwidth, it must allocate some of this bandwidth to the PW.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 13 Oct 2004 14:12:06 -0400

Peter,

I believe that by using a target-PE TLV in optional field
of PWE3 control signaling, one can achieve what you are 
looking for. This additional target-PE TLV will contain the 
IP address of target-PE and some other stuff, if needed.

This along with QOS TLV as defined in shah-pwe3-pw-qos-signaling
draft would enable each intermediate PE to find the next hop
and a suitable transport tunnel to the next hop, all the way to
the destination PE. In short, starting from source, based on 
the destination, each PE hop forwards the pwe3 control signal to 
the next hop and responds to the previous hop with the pw label,
and programs the FIB for PW label switching.

Do you think this meets the requirements?

/himanshu

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: Wednesday, October 13, 2004 11:14 AM
> To: [email-masked]'
> Cc: [email-masked]; [email-masked]'; Sasha 
> Vainshtein; 'Stewart
> Bryant'
> End-point identifier: are you referring to the FEC, or is 
> there another LDP object that can be used to identify an endpoint?
> 
> Opaque QoS: It is not opaque!! In the case of MH-PWs with 
> associate QoS characteristics, the PW switching nodes must 
> allocate resources to each PW. I still believe that: *if* 
> there is a need for MH-PWs within a Service Provider network 
> and *if* there is a need to associate QoS characteristics 
> with PWs, then such a MH-PW looks exactly like any other 
> traffic-engineered LSP. If RSVP-TE is the appropriate 
> protocol to set up such LSPs, it should be the appropriate 
> tool to set up MH-PWs with QoS characteristics.
> 
> 
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 13 Oct 2004 14:55:44 -0400

> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Wednesday, October 13, 2004 2:12 PM
> To: 'Busschbach, Peter B (Peter)'; [email-masked]'

Hi Himanchu,

We still don't have a clear formulation of the requirements. Therefore, I can't answer the last question.

Would your proposal meet the hypothetical requirements that we have been discussing? Of course. But that is not the point. I don't have any doubt that you can enhance LDP to make it do what we want to do. The question is, once all is set and done, haven't we recreated a signaling protocol that does the same as RSVP-TE? And if so, is that acceptable?

Peter

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 13 Oct 2004 15:05:01 -0400

It is one thing to marginally extend the pwe3 control signaling
and other thing to replace with new signaling protocol (that is
still evolving - as per discussions in this thread it seems scalability
of hierarchical RSPV-TE signagling is still not fully understood)

There are pros and cons for both.

/himanshu

> Sent: Wednesday, October 13, 2004 2:56 PM
> To: Shah, Himanshu; [email-masked]'
> We still don't have a clear formulation of the requirements. 
> Therefore, I can't answer the last question.
> 
> Would your proposal meet the hypothetical requirements that 
> we have been discussing? Of course. But that is not the 
> point. I don't have any doubt that you can enhance LDP to 
> make it do what we want to do. The question is, once all is 
> set and done, haven't we recreated a signaling protocol that 
> does the same as RSVP-TE? And if so, is that acceptable?
> 
> Peter
> 
> 
> > 
> > /himanshu
> > 
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 13 Oct 2004 15:09:10 -0400

> 
> > I meant that a PW Switching node must make sure that the 
> bandwidth, packet
> > loss and delay  characteristics of the PW are met. In  
> other words: if the
> > PW  switching node  can  switch a  certain  amount of  
> bandwidth, it  must
> > allocate some of this bandwidth to the PW.  
> 
> I don't think so.   The switching node just assigns the PW  
> to an LSP tunnel
> with appropriate QoS characteristics.  The  data plane model 
> is that packets
> move from one  tunnel to the next by dint of  ordinary MPLS 
> switching.  Thus
> the  relevant QoS characteristics  are characteristics  of 
> the  LSP tunnels.
> There are no  resources or queuing strategies that are  under 
> the control of
> the PW control plane. 
> 

Just to make sure that we talk about the same model: a PW Switching node terminates one Tunnel LSP, switches based on the PW label and forwards the traffic over another Tunnel LSP.

In that model, the Tunnel LSPs have the same function as any other physical or logical interface. The determination of which PWs are forwarded over which LSP Tunnels is determined by the QoS characteristics of each PW. Therefore, I do believe that there are resources and queuing strategies under the control of the PW control plane.

Note: a PW Switching node would need hierarchical scheduling, since the Tunnel LSPs themselves need the appropriate resources.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 13 Oct 2004 15:13:31 -0400

> Note: a PW Switching node would need hierarchical scheduling, 
> since the Tunnel LSPs themselves need the appropriate resources.

I take this back. It is not necessarily true. 

> Sent: Wednesday, October 13, 2004 3:09 PM
> To: [email-masked]'
> Just to make sure that we talk about the same model: a PW 
> Switching node terminates one Tunnel LSP, switches based on 
> the PW label and forwards the traffic over another Tunnel LSP.
> 
> In that model, the Tunnel LSPs have the same function as any 
> other physical or logical interface. The determination of 
> which PWs are forwarded over which LSP Tunnels is determined 
> by the QoS characteristics of each PW. Therefore, I do 
> believe that there are resources and queuing strategies under 
> the control of the PW control plane.
> 
> Note: a PW Switching node would need hierarchical scheduling, 
> since the Tunnel LSPs themselves need the appropriate resources.
> 
> 
>

---

From: [email-masked]
Date: Thu, 14 Oct 2004 01:21:19 +0100

Eric,

> to an LSP tunnel with appropriate QoS characteristics.  
> The data plane model is that packets move from one  tunnel  
> to the next by dint of ordinary MPLS switching. Thus the  
> relevant QoS characteristics  are characteristics  of the  
> LSP tunnels. There are no  resources or queuing strategies 
> that are  under the control of the PW control plane. 
> 
> I think it is  appropriate to say that the QoS object  is 
> "opaque" to the PW control  protocol,  because  the  PW  
> control  protocol  does not  need  to understand  the 
> queuing or  other resource  allocation strategies  needed to
> provide the  QoS.  Providing the  necessary QoS is  the 
> function of  the LSP tunnels.

I think the definition of whether a QoS object is opaque to the PW signalling protocol or not is dependant on the what functions are being performed on the QoS object, and what mechanisms are performing those functions.

For example, in a network that uses single hop PWs, CAC may be performed (for leased line/CBR type services) based on the bandwidth required by the attachment circuit as part of the provisioning process to ensure that an egress (PE-PE) TE tunnel has enough bandwidth available before signalling a PW.

In a (hypothetical) network that uses PW switching with TE tunnels between switching nodes, to ensure bandwidth is available for any given PW end-to-end across multiple TE tunnels, CAC would need to be performed at each switching node as part of the provisioning process. As switching nodes are not directly attached to attachment circuits, they would need to receive the PW bandwidth information through the PW signalling protocol.

With single hop PWs, CAC is performed prior to PW signalling and therefore it can be performed by a separate mechanism (i.e. not the signalling protocol), but what about the switched PW case? For switched PWs CAC would need to be performed at switching nodes during the signalling process. So either the signalling protocol would need to perform the CAC function, or the signalling protocol would need to send the bandwidth information to a separate CAC mechanism and wait for a response before continuing. 

If the PW signalling protocol performs the CAC function then obviously the bandwidth information could not be considered to be opaque, if on the other hand the CAC function was performed by a separate mechanism, then the bandwidth information could be considered to be opaque. Saying that, the two methods perform exactly the same functionality, I think its more of an implementation/standards specification issue as to whether the CAC function is considered to be part of the signalling mechanism or separate.

Regards,
Richard

---

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 14 Oct 2004 08:53:14 +0200

Eric,
            I've a question, what is the difference between having a PW
signalled with LDP in a MPLS Tunnel signalled with RSVP-TE and having two
nested LSP signalled with RSVP-TE?

Or having an LSP acting as PW and a tunnel (e.g. VC4) signalled both with
G.RSVP-TE?

I mean from the service I'm offering to the final customer.

One more question: if I use the PWE3 encapsulation IDs to encapsulate
traffic but I set up both the PW and the Tunnel with e.g. G.RSVP-TE can I
say that I'm offering a VPLS service?

Regards

Diego

Eric Rosen <[email-masked]>@ietf.org on 13/10/2004 20.51.00

Sent by:    [email-masked]

---

From: [email-masked]
Date: Thu, 14 Oct 2004 11:40:10 +0100

Richard,

I agree with what you are saying in general, but I think that we can
achieve this with relatively simple extensions to T-LDP.

We already have a proposal for a way to signal traffic parameters in
draft-shah, and I think it would be simple to enable T-LDP to signal the
ultimate target PE (either usings one of the existing FECs, or a new one).
If a PE can maintain a binding of  ingress and egress T-LDP sessions, then
we can also effectively crankback PW setup attempts that fail or block at
an intermediate switching node.

Best regards,

Matthew

|---------+--------------------------->
|         |           richard.spencer@|
|         |           bt.com          |
|         |           Sent by:        |
|         |           pwe3-bounces@iet|
|         |           f.org           |
|         |                           |
|         |                           |
|         |           14/10/2004 01:21|
|         |                           |
|---------+--------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |        To:      <[email-masked]>, <[email-masked]>                                                                   |
  |        cc:      [email-masked], [email-masked], [email-masked]                                                           |
  |        Subject: RE: [PWE3] RSVP-TE and PW                                                                                     |
  >-------------------------------------------------------------------------------------------------------------------------------|

Eric,

> function of  the LSP tunnels.

I think the definition of whether a QoS object is opaque to the PW
signalling protocol or not is dependant on the what functions are being
performed on the QoS object, and what mechanisms are performing those
functions.

For example, in a network that uses single hop PWs, CAC may be performed
(for leased line/CBR type services) based on the bandwidth required by the
attachment circuit as part of the provisioning process to ensure that an
egress (PE-PE) TE tunnel has enough bandwidth available before signalling a
PW.

In a (hypothetical) network that uses PW switching with TE tunnels between
switching nodes, to ensure bandwidth is available for any given PW
end-to-end across multiple TE tunnels, CAC would need to be performed at
each switching node as part of the provisioning process. As switching nodes
are not directly attached to attachment circuits, they would need to
receive the PW bandwidth information through the PW signalling protocol.

With single hop PWs, CAC is performed prior to PW signalling and therefore
it can be performed by a separate mechanism (i.e. not the signalling
protocol), but what about the switched PW case? For switched PWs CAC would
need to be performed at switching nodes during the signalling process. So
either the signalling protocol would need to perform the CAC function, or
the signalling protocol would need to send the bandwidth information to a
separate CAC mechanism and wait for a response before continuing.

If the PW signalling protocol performs the CAC function then obviously the
bandwidth information could not be considered to be opaque, if on the other
hand the CAC function was performed by a separate mechanism, then the
bandwidth information could be considered to be opaque. Saying that, the
two methods perform exactly the same functionality, I think its more of an
implementation/standards specification issue as to whether the CAC function
is considered to be part of the signalling mechanism or separate.

Regards,
Richard

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 14 Oct 2004 14:05:10 +0200

matthew,

as of today, i don't see why/how T-LDP QoS extensions can be qualified 
as "relatively simple" or "marginal extensions" (as i have seen this 
argument used many times on this list) without any real proposal on the 
table for this purpose (i don't speak about the point-to-point exchange 
of QoS AC parameters as in draft-shah where only ultimate PEs are 
involved) ?

this said, what is the QoS model and AC model that is associated to LDP 
signaling on ultimate and intermediate switching PEs ? so, as you are a 
bit evasive on how you would "transform" a point-to-point non-QoS 
capable protocol into an end-to-end QoS capable protocol, would you 
please clarify ?

the next question is how end-to-end and/or partial re-routing of such 
switched PW entities will be achieved in case of switching PE node failure ?

much thanks for your clarifications,
- dimitri.

[email-masked] wrote:

> .

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 14 Oct 2004 08:39:04 -0400

As you suggest and I agree that it is fruitless to engage
in detailed discussions without a proposal on the table.

Although, a couple of question that you have posted can 
be clarified. As Eric has pointed out many times with
clarifications, I don't see why "qos model" and "AC model" 
is necessary for the underlying LDP signaling protocol.

The (opaque) QOS TLV that is singalled to/through each PE hop is used 
to select the suitable underlying transport tunnel (TE-LSP
or other) between PE hops, to perform the CAC and/or to apply 
appropriate traffic shaping and policing for traffic between PW switch
points. 

As for partial or end-to-end rerouting - we need to wait for 
the requirements to be hammered out.

/himanshu

> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: Thursday, October 14, 2004 8:05 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> >-------------------------------------------------------------
> ------------------------------------------------------------------|
> >   |                                                         
>                                                               
>         |
> >   |        To:      <[email-masked]>, 
> <[email-masked]>                                       
>                             |
> >   |        cc:      [email-masked], [email-masked], 
> [email-masked]                                            
>                |
> >   |        Subject: RE: [PWE3] RSVP-TE and PW               
>                                                               
>         |
> >   
> >-------------------------------------------------------------
> ------------------------------------------------------------------|
> > 
> > 
> > 
> > 
> > Eric,
> > 
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 14 Oct 2004 09:28:17 -0400

> Sent: Thursday, October 14, 2004 8:39 AM
> To: [email-masked]'; [email-masked]

How can an object be both opaque AND be used for CAC and tunnel selection?

I suggest you read Richard's email again. His analysis is right on.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 14 Oct 2004 09:45:36 -0400

It is NOT opaque for intermediate PE nodes.

As I had indicated in the earlier email, 
PWE3 control signal is terminated, processed and 
re-signaled at each intermediate PE hop, all 
the way to the destination PE.

The word 'opaque' was used in the context of 
LDP, CR_LDP, and use of RSVP-TE to build transport
lsp as well as multi-hop PW.

Hope this clears up the confusion.

/himanshu

> Sent: Thursday, October 14, 2004 9:28 AM
> To: Shah, Himanshu; [email-masked]';
> [email-masked]
> [email-masked]; [email-masked]; [email-masked]

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 14 Oct 2004 09:51:27 -0400

Himanchu,

I am afraid your last email has left me even more confused than the first.

Are you saying that the QoS object is opaque if you use CR-LDP or RSVP-TE to establish a MH-PW, but not if you terminate control signaling at intermediate nodes? What difference do you see between "terminating and resignaling" versus the regular RSVP-TE procedure of processing and forwarding of signaling messages?

Peter

> Sent: Thursday, October 14, 2004 9:46 AM
> To: 'Busschbach, Peter B (Peter)'; [email-masked]';

---

From: Eric Rosen <[email-masked]>
Date: Thu, 14 Oct 2004 10:39:39 -0400

> if  on  the other  hand  the  CAC function  was  performed  by a  separate
> mechanism,  then  the bandwidth  information  could  be  considered to  be
> opaque.   Saying  that,  the   two  methods   perform  exactly   the  same
> functionality,   I   think  its   more   of  an   implementation/standards
> specification issue  as to  whether the CAC  function is considered  to be
> part of the signalling mechanism or separate.

I agree with  this analysis, but I think there are  pretty strong reasons to
keep  CAC and related  functions part  of the  tunnel setup  and maintenance
protocol, rather than part of the PW setup and maintenance protocol. 

- There  are many applications  whose data packets  may travel through  a TE
  tunnel. Pseudowires  is just one such  application.  If CAC  is handled at
  the  PW layer,  then  presumably  every application  which  can send  data
  through a TE tunnel would have  to have its own CAC function.  Somehow all
  these independent CAC  functions would have to work  together to share the
  tunnel. 

- Many  of the  data packets traveling  through a  TE tunnel will  belong to
  applications that do not have  control points at the tunnel endpoints.  So
  the  tunnel   mechanism  itself  has  to   be  able  to   handle  the  CAC
  functionality. 

- If CAC or other  QoS functionality is really thought of as  part of the PW
  layer, then it would seem to be  a major mistake to bind it tightly to the
  QoS capabilities of any particular PSN.

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 14 Oct 2004 10:45:15 -0400

If the word opaque is confusing you - then drop it.
It is not relevent in this discussion or what I
was suggesting on how one can use PWE3-control (ie targeted LDP)
also to signal MH PW along with QOS information.

The main difference between terminating+resignaling and
processing+forwarding, the way I see it is this.

Lets take a simple example of only one switching hop.
When switching PE1 receives PWE3-control msg from 
source PE, he can respond back with his PW label (but
PW status down). He then would signal to target PE
using the information received from source PE plus
PE1's own label. When the response comes back from
target PE (and since he is target he would send PW status up),
PE1 would,
1) program the FIB for PW label switching 
2) send PW status to source PE if both tunnels are up and
   target PE indicated that PW status is up

May be the difference is subtle. Lets not hung up on that.
The objectives are,
1) static configuration of intermediate PEs is not required
2) QOS information is taken into consideration
3) And most importantly we are still using established PWE3-
   control signaling.

if you need to discuss more, we can do that offline.

/himanshu (not himanchu...:)

> Sent: Thursday, October 14, 2004 9:51 AM
> Are you saying that the QoS object is opaque if you use 
> CR-LDP or RSVP-TE to establish a MH-PW, but not if you 
> terminate control signaling at intermediate nodes? What 
> difference do you see between "terminating and resignaling" 
> versus the regular RSVP-TE procedure of processing and 
> forwarding of signaling messages?
> 
> Peter
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 14 Oct 2004 11:47:02 -0400

Hi Himanshu,

Sorry for repeatedly mispelling your first name. (It must be the abundance of 'ch's in my own name that lead my fingers to the wrong keys.)

Thanks for your offer to continue this discussion off-line. However, I think it is important to discuss this on the list.

The point is: the mechanism that you propose is wrong. An intermediate PE should not respond to the initiator of the PW before forwarding a setup message to the destination PE. The reason is that there are interface parameters that need to be exchanged between the two end points and must be passed unchanged across PW switching points.  See section 6 of draft-martini-pwe3-pw-switching-00.txt for a correct description of the procedure.

This may be a minor oversight, but to me it is an example of the lack of rigor that appears frequently in the MH-PW discussions on this mailing list. When people talk about a MH-PW as a collection of wires that are patched together, they seem to underestimate what it takes to create a robust set of standards.

Peter

> Sent: Thursday, October 14, 2004 10:45 AM
> > > > > > as of today, i don't see why/how T-LDP QoS 
> extensions can be 
> > > > > > qualified 
> > > > > > signaling on ultimate and intermediate switching 
> PEs ? so, as 
> > > > > > you are a 
> > > > > > switched PW entities will be achieved in case of 
> switching PE 
> > > > > > node failure ?
> > > > > > 
> > > > > > > draft-shah, and I think it would be simple to 
> enable T-LDP 
> > > > > > to signal the
> > > > > > > ultimate target PE (either usings one of the 
> existing FECs, 
> > > > > > or a new one).
> > > > > > > If a PE can maintain a binding of  ingress and 
> egress T-LDP 
> > > > > > sessions, then
> > > > > > > For example, in a network that uses single hop 
> PWs, CAC may 
> > > > > > be performed
> > > > > > > (for leased line/CBR type services) based on the 
> bandwidth 
> > > > > > required by the
> > > > > > > In a (hypothetical) network that uses PW 
> switching with TE 
> > > > > > tunnels between
> > > > > > > end-to-end across multiple TE tunnels, CAC would 
> need to be 
> > > > > > performed at
> > > > > > > each switching node as part of the provisioning 
> process. As 
> > > > > > switching nodes
> > > > > > > bandwidth information could not be considered to 
> be opaque, 
> > > > > > if on the other
> > > > > > > two methods perform exactly the same 
> functionality, I think 
> > > > > > its more of an
> > > > > > > implementation/standards specification issue as 
> to whether 
> > > > > > the CAC function

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 14 Oct 2004 12:13:25 -0400

It is fruitless to continue discussing further until there
is a proposal that you can shoot holes in it. So you will
have to wait.

Since you have not fully understood the proposal (partly
because there is no written proposal), it would be a mistake
to call it a 'wrong mechanism'. 

It is possible that you have put more thought into this and
you see your proposal to be the only right way to solve this
problem. However, it would be a mistake to declare that rest
of the WG lack 'rigor' to create a robust set of standards.

Now, it is possible that when everything is said and done, 
hierarchical RSVP signaling is a better way to go. That is fine. 
However, what is not OK is to refuse to look at other alternatives.

/himanshu

> Sent: Thursday, October 14, 2004 11:47 AM
> Sorry for repeatedly mispelling your first name. (It must be 
> the abundance of 'ch's in my own name that lead my fingers to 
> the wrong keys.)
> 
> Thanks for your offer to continue this discussion off-line. 
> However, I think it is important to discuss this on the list.
> 
> The point is: the mechanism that you propose is wrong. An 
> intermediate PE should not respond to the initiator of the PW 
> before forwarding a setup message to the destination PE. The 
> reason is that there are interface parameters that need to be 
> exchanged between the two end points and must be passed 
> unchanged across PW switching points.  See section 6 of 
> draft-martini-pwe3-pw-switching-00.txt for a correct 
> description of the procedure.
> 
> This may be a minor oversight, but to me it is an example of 
> the lack of rigor that appears frequently in the MH-PW 
> discussions on this mailing list. When people talk about a 
> MH-PW as a collection of wires that are patched together, 
> they seem to underestimate what it takes to create a robust 
> set of standards.
> 
> Peter
> 
> [mailto:[email-masked]]
> > > > > > > as "relatively simple" or "marginal extensions" 
> (as i have 
> > > > > > seen this 
> > > > > > > > I agree with what you are saying in general, 
> but I think 
> > > > > > that we can
> > > > > > > > we can also effectively crankback PW setup 
> attempts that 
> > > > > > > fail or block at
> > > > > > > > attachment circuit as part of the provisioning 
> process to 
> > > > > > > ensure that an
> > > > > > > > it can be performed by a separate mechanism 
> (i.e. not the 
> > > > > > signalling
> > > > > > > > either the signalling protocol would need to 
> perform the 
> > > > > > > CAC function, or
> > > > > > > > the signalling protocol would need to send the 
> bandwidth 
> > > > > > > information to a

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 14 Oct 2004 12:43:08 -0400

> However, what is not OK is to refuse to look at other alternatives.

I thought that my reference to draft-martini-pwe3-pw-switching-00.txt was clear evidence that I am willing to look at other alternatives.

> Sent: Thursday, October 14, 2004 12:13 PM
> > > > > > > > capable protocol into an end-to-end QoS capable 
> protocol, 
> > > > > > would you 
> > > > > > > > please clarify ?
> > > > > > > > 
> > > > > > > > > We already have a proposal for a way to 
> signal traffic 
> > > > > > > parameters in
> > > > > > > > > egress (PE-PE) TE tunnel has enough bandwidth 
> available 
> > > > > > > > before signalling a
> > > > > > > > > PW.
> > > > > > > > > 
> > > > > > > > > are not directly attached to attachment 
> circuits, they 
> > > > > > > would need to
> > > > > > > > > If the PW signalling protocol performs the 
> CAC function 
> > > > > > > > then obviously the
> > > > > > > > > bandwidth information could be considered to 
> be opaque. 
> > > > > > > > Saying that, the
> > > > > > > > > is considered to be part of the signalling 
> mechanism or 
> > > > > > separate.
> > > > > > > > > 
> > > > > > > > > Regards,
> > > > > > > > > Richard
> > > > > > > > >