Subject: Re: Scaling hierarchical LDP/PW stitching

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 01 Aug 2004 17:10:37 -0700

Busschbach, Peter B (Peter) wrote:

> Hi Chris,
> 
> You ask an important question. I don't have the answer. I don't know if there
> are documents that describe requirements for inter-provider services. If not,
> it would be good if service providers got together to produce one.
> 
> As I wrote in my email to Mustapha, I believe that inter-provider services
> form a special case. We should be careful not to mix a general discussion of
> multi-hop PWs with the special requirements that apply when you cross
> provider boundaries.

I concur with this statement. Motivations for PW-switching to reduce the number 
of control connections, shared secrets between peers, etc. within a single 
administrative domain can be very different from those for PW-switching deployed 
at administrative boundaries. As such, the ideal mechanisms for each may be 
quite different.

> 
> Two comments on your email:
> 
> 1) draft-ayyangar-ccamp-inter-domain-rsvp-te-00.txt discusses extensions to
> RSVP-TE to make it suitable for inter-domain connection setup. The draft
> acknowledges that at the provider boundary there may be a need to stitch
> tunnels rather than to create a contiguous end-to-end tunnel. Therefore,
> applying LSP Hierarchy does not prevent a provider from confining the PW
> control channnel to inter-AS neighbors and ASBRs.
> 
> 2) I don't know how much providers care about the advertisements of specific
> IP addresses. After all, through BGP they advertise all addresses.
> Furthermore, in the IP VPN inter-AS scenarios described in 2547bis I don't
> see any attempt to hide the PE's IP address when crossing the AS boundary.

Using L2TP (RFC 2661) deployments as an example, it is common to see tunnel 
switches deployed at administrative boundaries for a variety of reasons. Hiding 
internal network topology (sometimes referring to as "tunnel grooming") are 
among the reasons I have seen cited for this.

- Mark

> 
> Peter
> 
> 
>> -----Original Message----- From: Chris Metz [mailto:[email-masked]] Sent:
>> Friday, July 30, 2004 1:12 PM To: Busschbach, Peter B (Peter) Cc: 'Mustapha
>> Aissaoui'; [email-masked]; [email-masked]; [email-masked]' Subject:
>> RE: [PWE3] Scaling hierarchical LDP/PW stitching
>> 
>> 
>> At 04:49 PM 7/27/2004 -0400, Busschbach, Peter B (Peter) wrote:
>> 
>> <snip>
>> 
>> 
>>> My contention is: we already have a topology discovery
>> 
>> mechanism. If you
>> 
>>> identify a MH-PW with the IP addresses of its ingress and
>> 
>> egress PE and
>> 
>>> you use the principles of
>> 
>> draft-ietf-mpls-lsp-hierarchy-08.txt, you have a
>> 
>>> solution.
>> 
>> Hey Peter- I do find the use of LSP hierarchy intriguing ... but it seems
>> to me that if the ultimate source PE of the MH-PW in one AS must "learn"
>> the IP address of the ultimate target PE in another AS, then we are at risk
>> of exposing one provider's internal addressing structure to another. I note
>> that these addresses are used to establish the PW control channels ... be
>> they RSVP or LDP or whatever. They are separate from whatever PW ID scheme
>> (i.e. TAII) that might be used.
>> 
>> I find some merit in the idea that PW control channels are confined to 
>> intra-AS PE neighbors and ASBR peering points. Is this the case with LSP 
>> hierarchy?
>> 
>> Cheers ...
>> 
>> 
>> 
>> 
>> 
>>> Peter
>>> 
>>> 
>>> 
>>>> -----Original Message----- From: Mustapha Aissaoui
>>>> [mailto:[email-masked]] Sent: Tuesday, July 27, 2004
>>>> 3:26 PM To: Busschbach, Peter B (Peter) Cc: [email-masked]';
>>>> [email-masked]; [email-masked]; [email-masked]' Subject: Re:
>>>> [PWE3] Scaling hierarchical LDP/PW stitching
>>>> 
>>>> 
>>>> Peter, I added a few comments below.
>>>> 
>>>> Regards, Mustapha. --------- "Busschbach, Peter B (Peter)" wrote:
>>>> 
>>>>> Hi Mustapha,
>>>>> 
>>>>> I agree with your last point, i.e. that we need to
>>>> 
>>>> understand the requirements before we decide which solution is best
>>>> suited. However, IMO your email  obscures some important issues.
>>>> 
>>>>> Peter
>>>>> 
>>>>> 
>>>>>> -----Original Message----- From: Mustapha Aissaoui
>>>>>> [mailto:[email-masked]] Sent: Monday, July 26, 2004
>>>>>> 5:20 PM To: Busschbach, Peter B (Peter) Cc: [email-masked]';
>>>>>> [email-masked]; [email-masked]; [email-masked];
>>>>>> [email-masked]' Subject: Re: [PWE3] Scaling hierarchical
>>>>>> LDP/PW stitching
>>>>>> 
>>>>>> 
>>>>>> Peter, in networks where end-to-end traffic engineering of PWs
>>>> 
>>>> is required,
>>>> 
>>>>>> or where any intermediate LSR could act as a stitching
>>>> 
>>>> node, the use
>>>> 
>>>>>> of RSVP-TE for PW setup makes a lot sense.
>>>>> 
>>>>> One of the things I was trying to get across in earlier
>>>> 
>>>> emails is that >every LSR _can_ function as a stitching node. A MH-PW
>>>> is nothing more >than a pt-to-pt LSP between two PEs and the stitching
>>>> points are nothing >more than LSRs that switch PW labels.
>>>> 
>>>> MA> If every LSR could function as a stitching node, which implies that
>>>> it would keep state for each PW and know how to
>> 
>> forward it, why
>> 
>>>> bother carrying PWs over a tunnel LSP? The reachability
>> 
>> information
>> 
>>>> required by the PW will be exactly the same as that of the tunnel LSP. 
>>>> In my view, we cannot start with the assumption that every node could
>>>> be a stichting node as this has the consequence of degenerating into an
>>>> all PW routable network.
>>>> 
>>>> 
>>>>> RSVP-TE is the appropriate tool for the setup of such
>>>> 
>>>> pt-to-pt LSPs. CR-LDP is an alternative.
>>>> 
>>>>> I don't think it is correct to say that RSVP-TE only makes
>>>> 
>>>> sense if you >need to do traffic engineering. RSVP-TE makes sense
>>>> anyway. The fact that >it can be used for traffic engineering is an
>>>> added benefit.
>>>> 
>>>> MA> I said RSVP-TE made sense in this case. I do not
>> 
>> think it is the
>> 
>>>> only case. Have you thought of other cases?
>>>> 
>>>> 
>>>>>> However, in many cases this will not be a requirement. There will
>>>>>> be a few
>> 
>> stiching nodes
>> 
>>>>>> which are known a priori.
>>>>> 
>>>>> I am not sure what your point is. You are saying that in
>>>> 
>>>> many cases there is no need for a scaleable solution. But in other
>>>> cases there is. Should we just ignore the latter?
>>>> 
>>>> MA> My starting point is different from yours. I am looking into a 
>>>> network where most of the label switching is performed at
>> 
>> the tunnel
>> 
>>>> LSP level and where a few nodes act as stitching points. So the 
>>>> forwarding information is mostly based on the tunnel LSP routing 
>>>> information. I need to use a policy to decide how a stitching node 
>>>> should move a PW from one tunnel LSP to another one. I do
>> 
>> not need a
>> 
>>>> routable PW label to perform a local forwarding operation in a few 
>>>> stiching nodes.
>>>> 
>>>> 
>>>>> The other problem I have with this statement is your
>>>> 
>>>> suggestion that >stitching nodes are known a priori and that 
>>>> (therefore?) we can get away >with simple solutions. As far as I can
>>>> see, every solution that uses a >hierarchy of LSPs requires certain
>>>> a-priori policies.  But that is not >the point. The crux of the
>>>> discussion between Du Ke and Richard Spencer >was that you need to have
>>>> mechanisms to find an end-to-end path between >two PEs. Therefore, even
>>>> if a PE would have the choice between only two >stitching nodes, it 
>>>> needs to select one of the two. And if the primary >selection fails, it
>>>> has to be able to switch over to the secondary node.
>>>> 
>>>> MA> How is this different from a node dual-homed to a network? A local
>>>> policy in the node states which is the primary node and if 
>>>> load-balancing is allowed over both links. This node does not need to
>>>> participate in the exchange of reachability
>> 
>> information with the
>> 
>>>> rest of the network.
>>>> 
>>>> 
>>>>> draft-martini-pwe3-pw-switching-00.txt assumes that the
>>>> 
>>>> stitching point >is manually configured. That could create problems for
>>>> protection >switching. draft-yudong-pwe3-control-protocol-ext-00.txt
>>>> adopts a
>>>> 
>>>>> solution that is at least capable of routing around
>>>> 
>>>> failures, but it >assumes that the operator assigns an absolute
>>>> priority to the stitching >nodes. That would nto work well if the
>>>> operator is interested in load >balancing.
>>>> 
>>>> MA> I am not sure why this should not work for load balancing. How is
>>>> this different from a node which performs load-balancing over 
>>>> dual-homed links? Unless you are thinking of load balancing PWs
>>>> end-to-end
>> 
>> over a set
>> 
>>>> of tunnel LSPs. In this case you want to traffic engineer
>> 
>> your PWs.
>> 
>>>>> I am sure that LDP-based proposals can be enhanced to deal
>>>> 
>>>> with these >issues, but why not use an existing protocol for which
>>>> these issues have >already been investigated and solved? And not only
>>>> that. It already has >solutions for traffic engineering, fast reroute
>>>> and graceful restart as >well.
>>>> 
>>>> MA> Again, you can take advantage of all this but you
>> 
>> really did not
>> 
>>>> need the tunnel LSPs and just let the PWs be routable across the 
>>>> network.
>>>> 
>>>> 
>>>>>> For instance, one may want to stitch PWs over a set of
>>>> 
>>>> intra-domain
>>>> 
>>>>>> tunnel LSPs which may or may not have been separately traffic 
>>>>>> engineered inside their own domain. The stitching
>> 
>> nodes will be a
>> 
>>>>>> few ASBRs.
>>>>> 
>>>>> I consider inter-AS scenarios (and especially,
>>>> 
>>>> inter-provider scenarios) as a special case and I can see that we adopt
>>>> a different solution for inter-AS cases than for intra-AS cases.
>>>> 
>>>>> I agree that we need to uderstand the target applications.
>>>> 
>>>> I would just be careful in making general statement based on an
>>>> inter-AS example. It can easily lead you in the wrong
>> 
>> direction.
>> 
>>>>>> Thus, having a solution based on Targeted LDP which removes
>>>>>> pre-configuration at the stitching node is
>> 
>> desirable. One
>> 
>>>>>> possible solution is to use the "Self-Mode" described in 
>>>>>> draft-yudong-pwe3-control-protocol-ext-00.txt where
>> 
>> the boundary
>> 
>>>>>> routers act as the stitching nodes.
>>>>>> 
>>>>>> So, the targetted application one wants to address should be 
>>>>>> examined to understand which solution is best suited.
>>>>>> 
>>>>>> Regards, Mustapha. -----------
>>>>>> 
>>>>> 
>>>>> [snipped]
>>>> 
>>> _______________________________________________ pwe3 mailing list 
>>> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
>> 
> 
>

---

From: [email-masked]
Date: Mon, 2 Aug 2004 18:27:27 +0100

Peter,

I agree that using FA-LSPs as described in draft-ietf-mpls-lsp-hierarchy-08.txt (which I must admit I hadn't read) is one solution to the MH-PW provisioning issue. It solves the next-hop/routing problem by having PW switching nodes advertise FA-LSPs as next-hops to PE loopback IP addresses via the IGP. Routing policies/metrics could be used to ensure that the PW next hop was always via the best directly connected FA-LSP.

However, the above solution requires that FA-LSPs are provisioned between PW switching capable nodes, what about providers that use LDP signalling for tunnel LSPs? I believe an alternative solution is required in this case.

Regards,
Richard

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: 27 July 2004 21:50
> To: 'Mustapha Aissaoui'
> Cc: [email-masked]'; [email-masked]; [email-masked];
> Spencer,R,Richard,XGH5 R
> Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching
> 
> 
> > In my view, we cannot start with the assumption that every node
> > could be a stichting node as this has the consequence of
> > degenerating into an all PW routable network.
> 
> Hi Mustapha,
> 
> Every LSR *can* be a PW stitching node. It is not an 
> assumption. It is a simple observation based on the 
> recognition that a MH-PW is really nothing more than an LSP.
> 
> That does not mean that every LSR *should* be used as a 
> stitching node. That would eventually not result in a 
> scaleable solution. Operators will use Transport LSPs to 
> aggregate PWs. They will identify specific nodes that will 
> function as stitching nodes and they will set policies that 
> prompt those nodes to establish the segments of a MH-PW 
> through the Transport LSPs.
> 
> I think that thus far we agree. We seem to disagree on how 
> you actually determine the end-to-end route.
> 
> You write: "I need to use a policy to decide how a stitching 
> node should move a PW from one tunnel LSP to another one. I 
> do not need a routable PW label to perform a local forwarding 
> operation in a few stiching nodes."
> 
> By saying that there are only a few nodes, you imply that 
> there is no need for a true routing solution. I disagree. The 
> question is: when the first stitching node receives a PW 
> setup request from a PE, how does it know what the next hop 
> on the path is? Or, in your words, the PW has to be moved to 
> the next tunnel, but which tunnel? You say: there are 
> policies. What kind of policies? Are you suggesting that the 
> operator manually provisions a routing table? Something like: 
> for AGI=X and AII=Y, the next hop is Z?
> 
> I thought that the email exchange between Richard Spencer and 
> Du Ke illustrated this problem very well and after a few 
> emails up and down, Du Ke acknowledged that there is a need 
> for some topology discovery mechanism.
> 
> mechanism. If you identify a MH-PW with the IP addresses of 
> its ingress and egress PE and you use the principles of 
> draft-ietf-mpls-lsp-hierarchy-08.txt, you have a solution.
> 
> Peter
> 
> 
> > -----Original Message-----
> > From: Mustapha Aissaoui [mailto:[email-masked]]
> > Sent: Tuesday, July 27, 2004 3:26 PM
> > To: Busschbach, Peter B (Peter)
> > Cc: [email-masked]'; [email-masked]; [email-masked];
> > [email-masked]'
> > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching
> > 
> > 
> > Peter,
> > Regards,
> > Mustapha.
> > ---------
> > "Busschbach, Peter B (Peter)" wrote:
> > > 
> > > Hi Mustapha,
> > > 
> > understand the requirements before we decide which solution 
> > is best suited. However, IMO your email  obscures some 
> > important issues.
> > > 
> > > Peter
> > > 
> > > > -----Original Message-----
> > > > From: Mustapha Aissaoui [mailto:[email-masked]]
> > > > Sent: Monday, July 26, 2004 5:20 PM
> > > > To: Busschbach, Peter B (Peter)
> > > > Cc: [email-masked]'; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]'
> > > > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching
> > > >
> > > >
> > > > Peter,
> > > > in networks where end-to-end traffic engineering of PWs 
> > is required,
> > emails is that >every LSR _can_ function as a stitching node. 
> > A MH-PW is nothing more >than a pt-to-pt LSP between two PEs 
> > and the stitching points are nothing >more than LSRs that 
> > switch PW labels.
> > 
> > MA> If every LSR could function as a stitching node, which implies
> > that it would keep state for each PW and know how to forward it, why
> > bother carrying PWs over a tunnel LSP? The reachability information
> > In my view, we cannot start with the assumption that every node
> > could be a stichting node as this has the consequence of
> > degenerating into an all PW routable network.
> >  
> > sense if you >need to do traffic engineering. RSVP-TE makes 
> > sense anyway. The fact that >it can be used for traffic 
> > engineering is an added benefit.
> > 
> > MA> I said RSVP-TE made sense in this case. I do not think it is the
> > > > However, in many cases
> > > > this will not be a requirement. There will be a few 
> stiching nodes
> > many cases there is no need for a scaleable solution. But in 
> > other cases there is. Should we just ignore the latter?
> > 
> > network where most of the label switching is performed at the tunnel
> > should move a PW from one tunnel LSP to another one. I do not need a
> > (therefore?) we can get away >with simple solutions. As far 
> > as I can see, every solution that uses a >hierarchy of LSPs 
> > requires certain a-priori policies.  But that is not >the 
> > point. The crux of the discussion between Du Ke and Richard 
> > Spencer >was that you need to have mechanisms to find an 
> > end-to-end path between >two PEs. Therefore, even if a PE 
> > would have the choice between only two >stitching nodes, it 
> > needs to select one of the two. And if the primary >selection 
> > fails, it has to be able to switch over to the secondary node.
> > 
> > MA> How is this different from a node dual-homed to a network? A
> > local policy in the node states which is the primary node and if
> > load-balancing is allowed over both links. This node does not need
> > to participate in the exchange of reachability information with the
> > rest of the network. 
> > 
> > stitching point >is manually configured. That could create 
> > problems for protection >switching. 
> > draft-yudong-pwe3-control-protocol-ext-00.txt adopts a 
> > failures, but it >assumes that the operator assigns an 
> > absolute priority to the stitching >nodes. That would nto 
> > work well if the operator is interested in load >balancing.
> > 
> > MA> I am not sure why this should not work for load balancing. How
> > is this different from a node which performs load-balancing over
> > dual-homed links?
> > Unless you are thinking of load balancing PWs end-to-end over a set
> > of tunnel LSPs. In this case you want to traffic engineer your PWs.
> >  
> > with these >issues, but why not use an existing protocol for 
> > which these issues have >already been investigated and 
> > solved? And not only that. It already has >solutions for 
> > traffic engineering, fast reroute and graceful restart as >well.
> >  
> > MA> Again, you can take advantage of all this but you really did not
> > > > engineered inside their own domain. The stitching nodes 
> will be a
> > > > few ASBRs.
> > > 
> > inter-provider scenarios) as a special case and I can see 
> > that we adopt a different solution for inter-AS cases than 
> > for intra-AS cases.
> > > 
> > I would just be careful in making general statement based on 
> > an inter-AS example. It can easily lead you in the wrong direction.
> > > 
> > > > Thus, having a solution based on Targeted LDP which
> > > > removes pre-configuration at the stitching node is 
> desirable. One
> > > > draft-yudong-pwe3-control-protocol-ext-00.txt where the boundary
> > > > Regards,
> > > > Mustapha.
> > > > -----------

---

From: [email-masked]
Date: Mon, 2 Aug 2004 18:29:00 +0100

Dimitri,

> > b. FA-LSP are mandated to connect SNs. This is restrictive in my 
> > view. It is not clear to me how non FA-LSPs could be used as tunnel 
> > LSPs.
> 
> the questions turns out to be if i have a set of FA-LSPs and a set of
> tunnels LSPs, the former being advertized as FA links but not 
> the latter
> how does the global mechanism work ?
> 
> the response is be setting up a routing adjacency on top of 
> the tunnels 
> LSPs that can not be advertized as FA LSPs
> 
> so, on one side, advertize these LSPs as simple IP/MPLS links so that 
> the non-FA capable nodes see these links (also i assume here 
> that a FA 
> capable node is also "non-FA" capable)
> 
> and on the other side, for non-FA capable nodes to see established FA 
> LSPs, mandate that FA link advertisement are beforehand 
> translated into 
> common IP/MPLS link advertisement
> 
> note: as we're at the bottom of the stack here there is also 
> no level issue

Please can you elaborate as to how this solves the problem Mustapha raises? If I understand correctly, Mustapha is raising the issue that if non FA-LSPs (e.g. LDP LSPs) are used then they are not advertised via the IGP as tunnels (P2P links), and therefore can not be used in the same way that FA-LSPs can be used to establish MH-PWs. This would be the case if a provider only used LDP LSPs or used LDP LSPs in conjunction with TE LSPs for different traffic types. In the latter case, some PWs will need to be tunnelled over the FA-LSPs, and some of the PWs will need to be tunnelled over the LDP LSPs, i.e. they will follow separate paths.

Your solution appears to just mandate that FA link advertisements are advertised as common IP/MPLS link advertisements so that they can be processed by non-FA capable nodes. This still requires FA-LSPs to be provisioned and therefore does not address the issue of using non-FA LSPs for tunnelling PWs.

Thanks,
Richard

---

From: [email-masked]
Date: Tue, 3 Aug 2004 00:50:40 +0100

Dimitri,

> there are several point to clarify from the above, in particular re - 
> stating the question that was "how non FA-LSPs could be used 
> as tunnel LSPs." the question boils down to "how a set of FA-LSPs and a set of 
> tunnel LSPs (i.e. non FA-LSPs), the former being advertized 
> as FA links but not the latter how does the global mechanism work ?"

I believe this is your (mis)interpretation of the question and is not the question Mustapha raised.

> on the other side the question turns out to be having established a FA-LSP 
> how do i make the existence of the correspond link information to 
> nodes that do not under stand "FA links"

Again, I believe this is a question that you have raised. PEs and PW switching nodes are the only nodes that need to set up FA-LSPs (to be able to support MH-PWs), if they don't support FA-LSPs then the solution Peter describes won't work making this a non-issue. If you disagree, please can you explain how MH-PWs can be established using PEs/PW switching nodes that don't support FA-LSPs?

> - you're making another distinction which is for the non-FA LSPs are 
> they "TE LSPs" or "LSPs" and the response is that it only dependent 
> on the PE capability to advertize the corr. link that can further be 
> used by other nodes to tunnel PWs coming to your last statement, it 
> boils down to what you do today, more precisely, the fact that FA-LSPs are provisioned 
> or triggered doesn't impact the non-FA LSPs are used for tunneling PWs

Sorry Dimitri but I don't understand the relevance of your response or the point you are trying to make. I wrote "This still requires FA-LSPs to be provisioned and therefore does not address the issue of using non-FA LSPs for tunnelling PWs." No one is suggesting that using FA-LSPs impacts non-FA LSPs used for tunnelling PWs, the question again is - If non-FA LSPs are used for tunneling PWs, how can the PE and PW switching node (or PW layer) topology be discovered and paths calculated/selected.

Regards,
Richard

---

From: "David Allan" <[email-masked]>
Date: Mon, 2 Aug 2004 20:34:44 -0400

I think FA-LSPs is the wrong concept to be using in this discussion, the
creation of FA-LSPs that would superficially appear to be superior routes to
direct PE-PE PSN LSPs in order to force desired behavior, and share a common
routing instance between the PW and PSN layers, would have rather bizarre
ramifications.

One implication is that routing may change over time, and therefore each PW
requires a switch table entry in every PW-Switch as it may be a viable
alternate path to either going directly to the PE or transiting a different
PW switch.

IMO if you are tandeming PWs in the middle of the network, you have a pinned
mid-point and it needs to be forced to be pinned in order to achieve useful
behavior....this is different semantics than that of an FA-LSP. You will
have distinct topologies for the PW and the PSN layers.

cheers
Dave

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, August 02, 2004 7:51 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Again, I believe this is a question that you have raised. PEs 
> and PW switching nodes are the only nodes that need to set up 
> FA-LSPs (to be able to support MH-PWs), if they don't support 
> FA-LSPs then the solution Peter describes won't work making 
> this a non-issue. If you disagree, please can you explain how 
> MH-PWs can be established using PEs/PW switching nodes that 
> don't support FA-LSPs?
> 
> Sorry Dimitri but I don't understand the relevance of your 
> response or the point you are trying to make. I wrote "This 
> still requires FA-LSPs to be provisioned and therefore does 
> not address the issue of using non-FA LSPs for tunnelling 
> PWs." No one is suggesting that using FA-LSPs impacts non-FA 
> LSPs used for tunnelling PWs, the question again is - If 
> non-FA LSPs are used for tunneling PWs, how can the PE and PW 
> switching node (or PW layer) topology be discovered and paths 
> calculated/selected.
> 
> Regards,
> Richard
> 
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 3 Aug 2004 01:01:37 -0400

> Sent: Friday, July 30, 2004 6:03 PM
> Cc: [email-masked]; [email-masked]; [email-masked]'
> Let us decompose the problem to gain more insight into the issue.
> Sorry for the lengthy message. Any comments are appreciated. 
> 
> I will be using the following diagram as an example to help walk
> through the various functions required to set up a MH-PW. I
> abstracted the network to only show the PEs and the Stitching Nodes
> (SNs). These nodes are inter-connected over a set of Tunnel LSPs
> (TLSPs). For now, assume these are FA-LSPs. Also, let us assume that
> all these nodes are in a single domain.
> 
> |PE1|--(TLSP)--|SN1|--(TLSP)------|SN3|--(TLSP)---|PE2|
>   |              |                  |               |
>   |              |---------------|  |               |
>   |                              |  |               |
>   |              |---------------|--|               |
>   |              |               |                  | 
>   |---(TLSP)---|SN2|---(TLSP)---|SN4|--(TLSP)-------|
> 
> 1. The first thing to do is to discover the nodes which are capable
> of acting as "stitching nodes". This will allow a specific PE or
> stitching node to know which nodes it can direct the PW signaling
> messages to. There may be several ways to do that including the
> possibility you mentioned in which any node can act as a stitching
> node and therfore you can skip to (2) below.
> 
> 2. When SN1 receives a PW signaling message, RSVP-TE or Targeted LDP
> (TLDP), from PE1, it needs to figure out which is the next-hop SN.
> Assume that either a Explicit Route object or a local reachability
> lookup indicates SN2. An explicit route object can be received in a
> RSVP-TE path message. A local reachability lookup is used in the
> case of TLDP PW signaling and is based on the destination PE address
> which needs to be included in the PW signaling message. The local
> lookup selects SN2 as a result of a FA-LSP advertisement.

Hi Mustapha,

This is the crux of the matter. How do you envision the local reachability look-up in case of TLDP?

In my view there are two options:

1) SN1 uses the IP address of PE2 to determine that SN2 is the next hop on the path.

2) SN1 uses AGI and AII to determine that SN2 is the next hop on the path.

To me solution 1) seems to have an obvious advantage: all nodes in the network run IP routing protocols already. To support 2) in an automatic fashion (i.e. not manually provisioned by the service provider) you need to use some form of autodiscovery protocol, so that SNs learn how to route AGIs and AIIs. That is not impossible. E.g. draft-hlmu-l2vpn-bgp-discovery-00.txt describes a possible solution.  This could be the right solution for inter-AS PW setup, but is it the right thing to do for intra-AS MH-PWs? I don't think so.

In your email you mention "routable PA labels". The issue is not that the PW labels are routable. The issue is that the identifiers used in PW setup messages must be routable. My argument is that it is better to use the IP address of the destination PE than to use AGI/AII.

Peter

>  
> 3. In the case of TLDP PW signaling, the TLDP session between PE1
> and SN1 is separate from that between SN1 and SN2. However, for the
> purpose of MH-PW signaling, they need to be coordinated. This means
> that SN1, and other transit SNs, can continue to process the
> signaling messages for the two directions independently but will
> only perform the sticthing in the datapath when both directions have
> been setup.
> 
> 5. The above procedures are repeated at each node until the PW
> signaling message reaches PE2. PE2 may trigger the reverse direction
> either independently or in response to the received label mapping
> message.
> 
> So far, it appears that we can have MH-PW without making the PW
> labels routable and that both RSVP-TE or TLDP could be used for PW
> signaling.
> 
> Though, we have the following open issues:
> a. How do stitching nodes get identified? The mere fact that a
> FA-LSP exists between SN1 and another node cannot be used as an
> indication that the latter can be used as a stitching node.
> > You write: "I need to use a policy to decide how a 
> stitching node should move a PW from one tunnel LSP to 
> another one. I do not need a routable PW label to perform a 
> local forwarding operation in a few stiching nodes."
> > 
> > I thought that the email exchange between Richard Spencer 
> and Du Ke illustrated this problem very well and after a few 
> > > I added a few comments below.
> > >
> > > Regards,
> > > Mustapha.
> > > ---------

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 3 Aug 2004 01:18:16 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 02, 2004 1:27 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> I agree that using FA-LSPs as described in 
> draft-ietf-mpls-lsp-hierarchy-08.txt (which I must admit I 
> hadn't read) is one solution to the MH-PW provisioning issue. 
> It solves the next-hop/routing problem by having PW switching 
> nodes advertise FA-LSPs as next-hops to PE loopback IP 
> addresses via the IGP. Routing policies/metrics could be used 
> to ensure that the PW next hop was always via the best 
> directly connected FA-LSP.
> 
> However, the above solution requires that FA-LSPs are 
> provisioned between PW switching capable nodes, what about 
> providers that use LDP signalling for tunnel LSPs? I believe 
> an alternative solution is required in this case.

Hi Richard,

You are right. In the case of LDP signaling for tunnel LSPs, a PW switching node would need additional policies to determine when to tunnel traffic and where to tunnel it to.

In the worst case, we could revert to the solution that other drafts propose: the Service Provider explicitly identifies which nodes are PW switching nodes. However, I could imagine that there are more general policies that require less manual engineering and provisioning. E.g rules like: (a) if the destination PE is in the same OSPF area use a tunnel that terminates directly on that PE. If the PE is in a different OSPF area, use a tunnel that terminates on an Area Border Router.

In my first email to you, I wrote: "The question is therefore not: what routing protocols do we need to find multi-hop capable routers?; but: what are the policies that drive an LSR to bundle multiple PW-LSPs into a single transport LSP?" 

I don't think the second problem is trivial, but I think it is better to try to solve the second problem than the first. (Unless we decide that PW switching is only relevant when crossing AS boundaries, in which case BGP probably offers a good solution for the first problem.)

Peter

---

From: [email-masked]
Date: Tue, 3 Aug 2004 16:32:50 +0100

Mustapha,

> Richard and Dimitri,
> this issue is in my view one of the critical issues. I believe a
> workable solution should have the following characteristics:
> 
> 1. State how stitching nodes are discovered. I do not agree with
> Peter that a stiching node is just another LSP switching node. There
> are PW specific operations to be performed in the data, control, and
> management (OAM) planes on a PW segment.

I agree that a PW stitching node is not just another (tunnel) LSP
switching node. The data plane behaviour (i.e. MPLS label switching) may
be the same but the tunnel LSP control protocols needs to be modified
(or separate control protocols/instances used) in order to support
single sided provisioning of switched PWs. I think discovery can be
split up into two aspects, i) discovery of ingress/egress PEs, and ii)
discovery of PW switching nodes.

Regarding i) this is required to support single sided provisioning.
Regarding ii), this is only required if routers use the same address
space (i.e. same loopback addresses) at the PW layer that they use at
the MPLS tunnel layer. If a different address space was used then
support for PW switching would be explicit. The consequence of using the
same addresses is that PW switching capable nodes must be distinguish
from non PW switching capable nodes explicitly using a discovery
mechanism or implicitly, e.g. using routing metrics as is the case with
the FA-LSP solution.

> 2. State how routing of PW control messages are performed once the
> stitching nodes have been discovered. It seems to me that a solution
> that mandates the use of FA-LSPs is too restrictive.

I agree that mandating FA-LSPs is too restrictive and that a common PW
routing solution should be specified. 

> 3. Avoid if possible making the PW label routable. Not that I have
> anything against that but if a solution turns PWs into routable
> entities on their own, then we should discuss it in that wider
> context. In that case, the use of tunnel LSPs becomes a convenience
> as opposed to a requirement of the architecture.

I'm not sure I understand your last point; it appears to me to be a
contradiction. In 2 you state that routing of PW control messages must
be addressed but then in 3 state that making PWs routable should be
avoided. I think there are two issues here, a) routing at the PW layer
where LSPs tunnels are used (resulting in a two layer LSP hierarchy), b)
routing where tunnel LSPs are not used (resulting in a single LSP
layer).

Regarding a), in the control plane, routing is required at the PW layer
to calculate/select the PW path from ingress PE to egress PE across
intermediate PW switching points and therefore the PE IP addresses must
be routable. In the (PW) data plane the PW label needs to be used at
each hop to make a forwarding decision. However, even though PWs need to
be routable at the PW level, they are not routable at the tunnel LSP
level, i.e. forwarding at the LSP tunnel level is based on tunnel LSP
labels not PW labels, just like VP switching in ATM is based on VPIs not
VCIs.

Regarding b), if tunnel LSPs are not used then PWs must still be
routable at the PW layer, but as this is the only layer each hop must
belong to the PW layer, i.e. each hop must support PW switching. For
scaling reasons its highly unlikely that a single LSP layer would be
used in the core, but I think using a single LSP layer would make sense
for spoke connections in the hierarchical LDP model.

Regards,
Richard

---

From: [email-masked]
Date: Tue, 3 Aug 2004 16:52:35 +0100

Peter,

> Hi Richard,
> 
> You are right. In the case of LDP signaling for tunnel LSPs, a PW
> switching node would need additional policies to determine when to
tunnel
> traffic and where to tunnel it to.
> 
> In the worst case, we could revert to the solution that other drafts
> propose: the Service Provider explicitly identifies which nodes are PW
> switching nodes. However, I could imagine that there are more general
> policies that require less manual engineering and provisioning. E.g
rules
> like: (a) if the destination PE is in the same OSPF area use a tunnel
that
> terminates directly on that PE. If the PE is in a different OSPF area,
use
> a tunnel that terminates on an Area Border Router.

PW switching only needs to be performed when a provider doesn't have a
full mesh of tunnel LSPs, which is why I do not agree with your
suggestion in an earlier post that any LSR may need to support PW
switching. IMO only specific LSRs will need to support PW switching and
therefore a provider will always know which nodes need to be PW
switching capable. In the hierarchical LDP case the nodes that need to
be PW switching capable are the hub (PErs) nodes, in the intra-provider
case the nodes that need to be PW switching capable are the border
routers (on which the tunnel LSPs terminate). As a provider will know
before deploying a node whether or not it will need to support PW
switching, I do not think manually provisioning (or using OSS) to
configure nodes to support PW switching when they are deployed will be
an issue.

> In my first email to you, I wrote: "The question is therefore not:
what
> routing protocols do we need to find multi-hop capable routers?; but:
what
> are the policies that drive an LSR to bundle multiple PW-LSPs into a
> single transport LSP?"
> 
> I don't think the second problem is trivial, but I think it is better
to
> try to solve the second problem than the first. (Unless we decide that
PW
> switching is only relevant when crossing AS boundaries, in which case
BGP
> probably offers a good solution for the first problem.)

I'm not asking which routing protocols need to be used at this stage,
I'm just saying that from a functional perspective routing needs to be
performed. I still don't think the issue has anything to do with
policies, IMO the problem is routing at the PW layer. The FA-LSP
solution works because FA-LSPs are advertised as next hops to reach PE
IP loopback addresses, which creates a server layer topology that can be
used by the PW layer. As far as the PW layer is concerned, the FA-LSPs
are point-to-point links, the P routers between FA-LSP source/sink pairs
are transparent to the PW layer. However, this only works if routing
metrics are used correctly to ensure that FA-LSP next hops are always
chosen over IGP adjacency based next hops. As David Allan points out,
manipulating routing metrics to ensure FA-LSP next hops are always
chosen over IGP adjacency next hops may lead to problems.

If however LDP tunnel LSPs are to be used for carrying MH-PWs then they
can not be advertised by the IGP as links and therefore PW layer
routing/next hop information must somehow be distributed in order to
determine the MH-PW topology. Also, if the PW layer and tunnel LSP layer
share the same addressing, then a mechanism must be used to distinguish
between PW switching capable nodes and non PW switching capable nodes.
In the FA-LSP solution, this is achieved via manipulating routing
metrics to ensure that PW-LSP next hops are chosen over IGP adjacency
next hops, i.e. discovery is implicit rather than explicit, the best
next hop *should* support PW switching.

Regards,
Richard

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 3 Aug 2004 13:10:31 -0400

> Sent: Tuesday, August 03, 2004 11:53 AM
> switching.

Richard,

I never said that every LSR needs to function as PW switching node. I said every LSR *can* support PW switching.

The issue is the following. If you read draft-martini-pwe3-pw-switching-00.txt, you get the impression that a PW Switching node is a special network element. It needs to support PW control protocols, be aware of PW-specific identifiers, support various data plnae interworking functions, etc.

The point I was trying to make is that in many cases, a PW Switching node is nothing more than an LSR that switches PW labels.

As you correctly pointed out: that is not the end of the story. If a Service Provider does not want to pre-provision FA-LSPs, an LSR that has been selected as a PW Switching node needs additional functionality. I called that additional functionality "policies regarding when to tunnel LSPs". You call it "PW routing". I think these are two aspects of the same problem, but I am happy to use your terminology. The important issue, though, is that this could be treated as a general problem related to label stacking and not just as a PW specific problem.

So in my view there are two options:

1) Consider PW switching nodes as special network elements that are tailor-made for PW switching

2) Add a function to the MPLS control plane (like fast reroute or graceful restart) to deal with label stacking and its impact on routing and LSP setup.

In yesterday's WG meeting we decided that we need to establish the requirements for PW switching first, before we discuss solutions. Based on the requirements it is well possible that we end up doing 1). However, in the long rung, 2) might be more useful as it could apply to other problems than PWE as well.

Peter

 IMO only specific LSRs will need to support PW 
> switching and

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 04 Aug 2004 08:27:30 +0200

> alternate path to either going directly to the PE or transiting a different

you speak about an issue which is independent to the use of FA LSPs it 
just depend on the TE metric setup for the links subsequently used 
during the MH-PW establishment (note that LSP-HIER proposes a default 
setup for the FA link metric but this may be overridden) - would you 
also be more accurate when you mention "routing may change over time" in 
the present context

> have distinct topologies for the PW and the PSN layers.

i don't clearly see where the problem lies here if you have a tunnel LSP
between to nodes (say N_2 and N_3) and the tunnel LSP bandwidth is large
enough to carry another PWs between N_1 and N_3 why a MH-HOP PW [N_1 - 
N_2 - N_3] couldn't be established if all QoS conditions would be met 
over this path ?

note that i didn't mention the word FA-LSP in the above, and even if the 
tunnel between PE_2 and PE_3 would have been advertized as such (i.e. FA 
link) its semantic would not have been different from the current 
definition as an adjacency within the data plane is created between PE_2 
and PE_3 through this LSP (see section 3.5 for the details) so the usage 
of provisioned FA LSPs is meant to address cases when a known set of PWs 
is to be setup within a given period of time

>>>there are several point to clarify from the above, in 
>>
>>particular re -
>>
>>>as tunnel LSPs." the question boils down to "how a set of 
>>
>>FA-LSPs and a set of 
>>
>>>on the PE capability to advertize the corr. link that can 
>>
>>further be 
>>
>>>boils down to what you do today, more precisely, the fact 
>>
>>that FA-LSPs are provisioned 
>>
>>>or triggered doesn't impact the non-FA LSPs are used for 
>>
>>tunneling PWs
>>
> .

---

From: [email-masked]
Date: Wed, 4 Aug 2004 10:47:59 +0100

Dimitri,

If I understand correctly, David is talking here about the specific use of FA-LSPs in setting up MH-PWs rather than the generic use of TE tunnels (FA or otherwise) for carrying PWs.

A PW switching solution based on FA-LSPs is dependant on the FA-LSP next hop with the best path to the destination PE being chosen, in which case problems will arise if for whatever reason an alternative next hop is selected. 

For example, if a FA-LSP was to fail and there were no other FA-LSPs to reach the destination PE, the default behaviour would be for the next best next hop to be selected. In the case of core FA-LSP failure, the best next hop is likely to be an IGP adjacency next hop (a P router) which does not support PW switching. IMO it is not clear what happens under these kind of circumstances and further study is required to determine what the implications are of using routing metrics to implicitly select next hop PW switching nodes.

Regards,
Richard

> From: dimitri papadimitriou [mailto:[email-masked]]
> Sent: 04 August 2004 07:28
> To: David Allan
> Cc: Spencer,R,Richard,XGH5 R; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> >>>on the other side the question turns out to be having 
> established a 
> >>>FA-LSP

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 4 Aug 2004 14:54:31 -0400

Peter,

[clipped...]

> 
> In yesterday's WG meeting we decided that we need to
> establish the requirements for PW switching first, before we 
> discuss solutions. Based on the requirements it is well 
> possible that we end up doing 1). However, in the long rung, 
> 2) might be more useful as it could apply to other problems 
> than PWE as well.
> 

In addition to requirements I think in light of this
discussion and proposed solution drafts we need to clarify
maybe as new sections to existing framework draft the
following:

a) The terminology: PW switching/stitching/multihop PW,
   PW switching points and PW demultiplexor 
   allocation points (suggest stick with one or two terms).

b) Deployment scenarios of multihop/switching in terms of
   - an inter-as/domain 
   - single/inter-providers
   - a PW-enabled access network to an PW-MPLS core network
   - A PW "private" segment stitched to another "provider-based" 
     PW (not sure this is needed?).

c) switching point determination (dynamic -routing, pre-configured)
d) mp-pw path determination (implicit/explicit -ERO).
e) switching node being PW aware or not
f) end-to-end MP-PW signaling versus no end-to-end signaling 
   (just switching per config).
etc...

Hamid.

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 4 Aug 2004 22:20:06 +0200

Hamid, Peter and all,
I tend to agree with Hamid wrt the scope of work to be done.
I would also include the OAM tools e.g., localization of
fault on a specific hop of a MH-PW - probably useful in the
inter-provider scenarios.
----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Hamid Ould-Brahim [mailto:[email-masked]]
> Sent: Wednesday, August 04, 2004 10:55 AM
> To: Busschbach, Peter B (Peter); [email-masked]'; 
> Cc: [email-masked]; [email-masked]

---

From: [email-masked]
Date: Wed, 4 Aug 2004 21:09:07 +0100

No disrespect to the manufacturer community, but don't folks think it
might be good idea to ask operators what they might want here?

But please bear in mind....the requirements for:
-	the Internet
-	altnets/ISps
-	trad operators
-	enterprises
are not the same.  So can I ask again *who* is the PWE3 WG intending
doing this work for?

Regards, Neil

> Behalf Of Sasha Vainshtein
> Sent: 04 August 2004 21:20
> To: 'Hamid Ould-Brahim'; Busschbach, Peter B (Peter)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Spencer,R,Richard,XGH5 R
> I tend to agree with Hamid wrt the scope of work to be done. I would 
> also include the OAM tools e.g., localization of fault on a specific 
> hop of a MH-PW - probably useful in the inter-provider scenarios.
> establish the
> > > requirements for PW switching first, before we discuss solutions.
> > > Based on the requirements it is well possible that we end 
> up doing
> > > 1). However, in the long rung,
> > > 2) might be more useful as it could apply to other problems than 
> > > PWE as well.
> > > 
> > 
> > In addition to requirements I think in light of this discussion and
> > proposed solution drafts we need to clarify maybe as new 
> sections to
> > existing framework draft the
> > following:
> >

---

From: "David Allan" <[email-masked]>
Date: Wed, 4 Aug 2004 23:32:06 -0400

Hi Dimitri:

<snipped>
> also be more accurate when you mention "routing may change 

Not quite sure why it would be independent, fiddling metrics to impose
policy such that traffic transits a particular node or set of nodes IMO is
not a tractable solution unless you are only carrying tandemed PW
traffic....further it does not imply the requisite semantics for transiting
a PW switch

My interpretation of use of FA-LSPs (in that they are advertised into the
PSN routing system) is that they would not adequately reflect the PW layer
topology and would distort the PSN.....

More specifically, the PE needs a PSN FEC for the PW switch and not a
distant PE if the PW layer is to transit and be switched by a PSN switch,
which is completely orthogonal to the use of FA-LSPs. Use of FA-LSPs would
simply affect the routing of the PSN FEC, not what the PSN FEC was. 

<snipped to end>

rgds
Dave

---

From: [email-masked]
Date: Thu, 5 Aug 2004 10:52:41 +0100

Dave....
> Not quite sure why it would be independent, fiddling metrics 
> to impose policy such that traffic transits a particular node 
> or set of nodes IMO is not a tractable solution unless you 
> are only carrying tandemed PW traffic....further it does not 
> imply the requisite semantics for transiting a PW switch
> 
> My interpretation of use of FA-LSPs (in that they are 
> advertised into the PSN routing system) is that they would 
> not adequately reflect the PW layer topology and would 
> distort the PSN.....
> 
> More specifically, the PE needs a PSN FEC for the PW switch 
> and not a distant PE if the PW layer is to transit and be 
> switched by a PSN switch, which is completely orthogonal to 
> the use of FA-LSPs. Use of FA-LSPs would simply affect the 
> routing of the PSN FEC, not what the PSN FEC was. 
> 
NH=> The concept and value of FAs is very limited IMO.  When one has a
set of nested layer networks the general requirement is that the trail
holding time and topology stability *must* increase as one approaches
the duct.  I can't get my head round how this '1 routing instance over
all layer networks' behaves under routing protocol anomalies and all
failure scenarios.  But of even more fundamantal importance is this:
When we have a client/server relationships between layer networks which
are owned by different parties then the whole concept of FAs is a
non-starter anyway.....and even this is not sufficient, one must have
full functional independence between the layer networks involved.  These
are *very* common requirements....they are certainly not the exceptions.

A key issue for a large operator is security/stability of the
control/management plane.  It should be a no-brainer that wherever
possible the internal sensitive control/management plane protocols are
run OOB wrt to the traffic.  This is required in the co-cs mode (and
GMPLS now does indeed address this) and it is also required in the co-ps
mode.  This has very important implications for the arch/solutions, and
the PWE3 stuff has simply failed to take this into account so far.

Regards, Neil

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Sat, 7 Aug 2004 22:15:14 -0400

Mustapha,

I am surprised by your insistence that PWs should not be routable. 

I understand that the proposals I made in this email exchange have pros and cons. Within the scope of the requirements (which we will document, as we discussed in San Diego), it is very well possible that the cons outweight the pros. Or vice versa. We will see. However, you seem to have decided already that routable PWs are forbidden under any circumstances. 

You write: "My point is that the PW dataplane forwarding decision should be local to a stitching node and not network wide."

I have no idea what you mean by that. The dataplane forwarding decision is always local. The stitching node receives a packet with PW Label A, swaps it with PW Label B and forwards it over the appropriate tunnel.

The issue is how the stitching node supports signaling. It receives a PW setup request (in the current model, an LDP label mapping message) and somehow has to determine what the next node on the Multi-hop Path is. In all likelyhood, that next hop will be derived from one or more identifiers that identify the end point of the MH-PW.

There are two options:

a) identify the end point by the IP address of the destination PE
b) identify the end point by a specific AGI/AII combination.

Since every node in the network already IP routing and already has (a prefix of) the PE's IP address in its routing table, it seems to me that a) is more straightforward than b). Not only that. Solution b) requires a topology discovery protocol based on AGIs and AIIs.

However, in your email, you also write that:
"... we do not want to have a separate addressing and routing for PWs in the current PWE3 architecture". 

I am not sure how to interpret this statement. It sounds as if you agree with me that a) is the better solution. However, you are arguing vehemently against my position. Therefore, the only thing I can imagine is that you believe that any form of automated MH-PW setup is undesirable and that Service Providers will be perfectly happy to manually provision MH-PWs.

You may be right, but let's wait for the requirements ...

Peter

> Sent: Wednesday, August 04, 2004 9:41 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> see below.
> [email-masked] wrote:
> > 
> > Mustapha,
> > 
> > > Richard and Dimitri,
> > single sided provisioning of switched PWs. 
> 
> MA> Add to that OAM on the PW segment.
> 
> > I think discovery can be
> MA> I think single sided signaling is a separate issue. You can
> still configure the AC and PW information at both PEs but have one
> side trigger the PW setup (master PE) and the other reply only when
> it receives it (slave PW). This is the dominant mode of operation of
> SPVCs in ATM networks today.
> 
> MA> You are right. However, the reason for using the same address
> space is a direct consequence of the fact that PWs can only ride
> inside a tunnel of some sort. 
>  
> MA> I mean that we do not want to have a separate addressing and
> routing for PWs in the current PWE3 architecture.  
> I make the following argument: as long as PWs are confined inside
> tunnels, it does not make sense to make them routable (network wide)
> and have their own address  space.
> 
> MA> You describe it very well. My point is that the PW dataplane
> forwarding decision should be local to a stitching node and not
> network wide. In other words, we do not want to advertize PW
> reachability.
>  
> MA> Correct. And this is where I think Peter and I disagree. I do
> not belive that we want to solve the general problem where any node
> can be used as a stitching node because this degenerates into the
> case where you will be forced to have a separate routing and
> addressing for the PWs. The case of the spoke connections is
> different. I assume that a static PW may be just fine if the access
> network is simple. In complex access and aggregation networks, one
> can have build a separate PSN for this network and perform switching
> at some well idnetified edge nodes.
>  
> > Regards,
> > Richard
>

---

From: Luca Martini <[email-masked]>
Date: Mon, 09 Aug 2004 15:50:18 -0600

>   allocation points (suggest stick with one or two terms).
This is defined in the draft-martini-pwe3-pw-switching-00.txt Do you 
need me to add anything ?

>     PW (not sure this is needed?).
This would be more suited for a requirement draft.

>c) switching point determination (dynamic -routing, pre-configured)
Automatic provisioning is part of L2VPN , we probably need to expand on 
the current autodiscovery/provisioning drafts to include the 
pw-switching cases.

>d) mp-pw path determination (implicit/explicit -ERO).
Not sure what you mean. Is this regarding the pw switching TLV we  
defined ?  or regarding autodiscovery ?

>e) switching node being PW aware or not
If it's switching PW it must be PW aware otherwise it is only a P router 
in a PSN.

>   (just switching per config).
Again this is another provisioning scheme requirement.

Luca

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 9 Aug 2004 18:39:25 -0400

> From: Luca Martini [mailto:[email-masked]]
> Sent: Monday, August 09, 2004 5:40 PM
> Cc: 'Mustapha Aissaoui'; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 
> [email-masked]
> I would like to make a distinction between autodiscovery , 
> and PW switching.
> What you are proposing is an autodiscovery system that automatically 
> provisions the PW switching point to switch an incoming PW into a 
> specific outgoing one. I believe that there is a requirement for this 
> functionality, but this is an L2VPN and PW autodiscovery discussion.
> I purposely kept away from this in the pw-switching draft, as 
> provisioning of L2VPNs is not in scope here.

I agree that autodiscovery belongs in L2VPN and not in PWE3. However, the consequence of accepting draft-martini-pwe3-pw-switching-00.txt is that autodiscovery must be based on the LDP identifiers defined in the control draft (i.e. PWids, AGIs and AIIs). Is that the right approach?

In fact, in the case of Multi-hop PWs, the autodiscovery mechanism used between PEs does not necessarily extend to PW Switching Nodes. PEs need to exchange information about Attachment Circuits, but PW Switching Nodes only need to have enough knowledge to establish end-to-end PWs. Draft-martini-pwe3-pw-switching-00.txt does not allow one to make that distinction. It assumes that every node (both PEs and PW Switching Nodes) maintain AC-related information.

In summary, I don't think we can define MH-PW setup without looking at the impact it has on autodiscovery.

> ( this does not mean it is 
> not required by somebody ).
> Also keep in mind that today I only know about L2 peering points that 
> are statically provisioned. Unlike L3 peering, I have not seen PNNI 
> peering or Frame-Relay SPVC peering.

I agree. On the other hand, there is telephony peering. 

> >I understand that the proposals I made in this email 
> exchange have pros and cons. Within the scope of the 
> requirements (which we will document, as we discussed in San 
> Diego), it is very well possible that the cons outweight the 
> pros. Or vice versa. We will see. However, you seem to have 
> decided already that routable PWs are forbidden under any 
> circumstances. 
> >
> >You write: "My point is that the PW dataplane forwarding 
> decision should be local to a stitching node and not network wide."
> >
> >I have no idea what you mean by that. The dataplane 
> forwarding decision is always local. The stitching node 
> receives a packet with PW Label A, swaps it with PW Label B 
> and forwards it over the appropriate tunnel.
> >
> >The issue is how the stitching node supports signaling. It 
> receives a PW setup request (in the current model, an LDP 
> label mapping message) and somehow has to determine what the 
> next node on the Multi-hop Path is. In all likelyhood, that 
> next hop will be derived from one or more identifiers that 
> identify the end point of the MH-PW.
> >
> >There are two options:
> >
> >Since every node in the network already IP routing and 
> already has (a prefix of) the PE's IP address in its routing 
> table, it seems to me that a) is more straightforward than 
> b). Not only that. Solution b) requires a topology discovery 
> protocol based on AGIs and AIIs.
> >
> >"... we do not want to have a separate addressing and 
> routing for PWs in the current PWE3 architecture". 
> >
> >I am not sure how to interpret this statement. It sounds as 
> if you agree with me that a) is the better solution. However, 
> you are arguing vehemently against my position. Therefore, 
> the only thing I can imagine is that you believe that any 
> form of automated MH-PW setup is undesirable and that Service 
> Providers will be perfectly happy to manually provision MH-PWs.
> >
> >>>>Peter that a stiching node is just another LSP switching 
> >>>>        
> >>>>
> >>node. There
> >>    
> >>
> >>>>are PW specific operations to be performed in the data, 
> >>>>        
> >>>>
> >>control, and
> >>    
> >>
> >>>switching node. The data plane behaviour (i.e. MPLS label 
> >>>      
> >>>
> >>switching) may
> >>    
> >>
> >>>be the same but the tunnel LSP control protocols needs to 
> >>>      
> >>>
> >>be modified
> >>    
> >>
> >>>split up into two aspects, i) discovery of ingress/egress 
> >>>      
> >>>
> >>PEs, and ii)
> >>    
> >>
> >>>space (i.e. same loopback addresses) at the PW layer that 
> >>>      
> >>>
> >>they use at
> >>    
> >>
> >>>support for PW switching would be explicit. The consequence 
> >>>      
> >>>
> >>of using the
> >>    
> >>
> >>>same addresses is that PW switching capable nodes must be 
> >>>      
> >>>
> >>distinguish
> >>    
> >>
> >>>mechanism or implicitly, e.g. using routing metrics as is 
> >>>      
> >>>
> >>the case with
> >>    
> >>
> >>>the FA-LSP solution.
> >>>      
> >>>
> >>>>stitching nodes have been discovered. It seems to me that 
> >>>>        
> >>>>
> >>a solution
> >>    
> >>
> >>>I agree that mandating FA-LSPs is too restrictive and that 
> >>>      
> >>>
> >>a common PW
> >>    
> >>
> >>>>context. In that case, the use of tunnel LSPs becomes a 
> >>>>        
> >>>>
> >>convenience
> >>    
> >>
> >>>contradiction. In 2 you state that routing of PW control 
> >>>      
> >>>
> >>messages must
> >>    
> >>
> >>>avoided. I think there are two issues here, a) routing at 
> >>>      
> >>>
> >>the PW layer
> >>    
> >>
> >>>where LSPs tunnels are used (resulting in a two layer LSP 
> >>>      
> >>>
> >>hierarchy), b)
> >>    
> >>
> >>>Regarding a), in the control plane, routing is required at 
> >>>      
> >>>
> >>the PW layer
> >>    
> >>
> >>>intermediate PW switching points and therefore the PE IP 
> >>>      
> >>>
> >>addresses must
> >>    
> >>
> >>>each hop to make a forwarding decision. However, even 
> >>>      
> >>>
> >>though PWs need to
> >>    
> >>
> >>>level, i.e. forwarding at the LSP tunnel level is based on 
> >>>      
> >>>
> >>tunnel LSP
> >>    
> >>
> >>>labels not PW labels, just like VP switching in ATM is 
> >>>      
> >>>
> >>based on VPIs not
> >>    
> >>
> >>>VCIs.
> >>>      
> >>>
> >>>routable at the PW layer, but as this is the only layer 
> >>>      
> >>>
> >>each hop must
> >>    
> >>
> >>>used in the core, but I think using a single LSP layer 
> >>>      
> >>>
> >>would make sense
> >>    
> >>

---

From: [email-masked]
Date: Tue, 10 Aug 2004 00:14:21 +0100

Peter,

I agree with all the comments you make below.

Regarding the distribution of PW layer reachability information for MH-PWs, I would argue that this information must always be distributed (or collected) whether manual or dynamic provisioning methods are used. To set up a path across multiple hops where alternative paths exist, routing must be performed, there is no getting away from this. If a human operator manually configures a MH-PW then the routing function is performed by the human operator and the human operator collects the reachability information by analysing the network topology information. If OSS systems are used then the OSS system must perform the routing function and discover the topology of the network by requesting or collecting reachability/switching node capability information. If dynamic routing protocols are used to perform the routing function then reachability/switching node capability information must be distributed/collected by PEs and PW switching nodes via the routing protocol. As provisioning by a human operator obviously doesn't scale, provisioning for MH-PWs must be carried out either by OSS or dynamic protocols, which means that the PEs and PW switching nodes must advertise (or respond to requests for) reachability/switching node capability information.

Regarding PW end point identifiers for routing purposes, as things stand today I think out of the two options below, routing based on PE IP addresses (option a) is preferable to using AGI/AII combinations (option b). The main reasons being:

(1) From the PWE3 control draft: "The Attachment Identifier must be unique in the context of the PE router in which the Forwarder resides.  The combination <PE router, AI> must be globally unique." So, even if the AGI/AII are used, the PE IP addresses must be used as well anyway. 

(2) Reachability information based on [AGI/AII/PE IP address] destination identifiers would need to be advertised and stored in a routing table (if a dynamic routing protocol is used) on each PE and PW switching node. This does not seem desirable looking at things from a vendors perspective because the PW routing table implementation would need to support variable/unknown length identifiers as destinations.

Saying that, in theory, using AGI/AIIs would make sense because AGI/AIIs belong to the PW layer and therefore routing would be based on address/naming information pertinent only to the PW layer. The problem is that the naming method used to identify a PW access point (forwarder) is based on the PE IP address (which exists at the MPLS tunnel layer) plus a locally unique AI (which exists at the PW layer). Having thought about it, I think option (a) could be made to work if a globally unique identifier (e.g. an IPv6 address) was used to identify a PW access point. The AGI could still be used to identify a PW VPN, but the AII would uniquely identify a PW access point (on a global PW layer network basis). This would solve problem (1) because the AII would be globally unique and therefore the PE IP addresses (belonging to the MPLS tunnel layer) would not be required, and problem (2) would be solved because the destination would be a fixed length IPv6 address. The idea of using IPv6 addresses for identifying forwarders could be taken a step further by making a forwarder a manageable logical entity, i.e. a logical PW interface that could be managed just like any other interface. This would also be an advantage from an OAM perspective as the PW endpoint identifiers would uniquely identify the PW layer source and sink access points.

Of course there is nothing stopping a provider using IPv6 addresses for AIs (PW access points) today. The problem is that because using IPv6 addresses for AIs is not mandatory, to fully support option (a) vendors would still need to address problem (2) by implementing a PW routing table that supports unknown/variable length destination identifiers, and address problem (1) by at least having an option for using AGI/AII + PE IP address identifiers, rather than just AIIs.

Regards,
Richard

> Sent: 08 August 2004 03:15
> To: 'Mustapha Aissaoui'; Spencer,R,Richard,XGH5 R
> [email-masked]; [email-masked]
> I understand that the proposals I made in this email exchange 
> have pros and cons. Within the scope of the requirements 
> (which we will document, as we discussed in San Diego), it is 
> very well possible that the cons outweight the pros. Or vice 
> versa. We will see. However, you seem to have decided already 
> that routable PWs are forbidden under any circumstances. 
> 
> "... we do not want to have a separate addressing and routing 
> for PWs in the current PWE3 architecture". 
>

---

From: Luca Martini <[email-masked]>
Date: Mon, 09 Aug 2004 17:22:32 -0600

>I agree that autodiscovery belongs in L2VPN and not in PWE3. However, the consequence of accepting draft-martini-pwe3-pw-switching-00.txt is that autodiscovery must be based on the LDP identifiers d…
Since we have accepted the control protocol draft we do not have much 
choice on what parameters identify a PW.
This is already defined.

>In fact, in the case of Multi-hop PWs, the autodiscovery mechanism used between PEs does not necessarily extend to PW Switching Nodes. PEs need to exchange information about Attachment 
>
I see this from a different point of view. Current autodiscovery does 
not take into consideration pw-switching nodes , but I cannot see why we 
have to merge the auto provisioning of PW , and the signaling protocol ?

>Circuits, but PW Switching Nodes only need to have enough knowledge to establish end-to-end PWs. Draft-martini-pwe3-pw-switching-00.txt does not allow one to make that distinction. It assumes that every node (both PEs and PW Switching Nodes) maintain AC-related information.
>
>  
>
The pw-switching draft does not address autodiscovery,  and it does not 
assume that PW switching point have to maintain AC-related information 
either ( excluding the static PW case ). The interface parameters are 
received , and relayed along in most cases unchanged. It is certain that 
in many interAS application the PW-switching point will have to enforce 
the local AS policy, but that should be a general dataplane policy 
similar to MTU, or source routing in the IP peering case.

I envision the PW-switching point to be able to receive specific PW 
provisioning information via some autodiscovery protocol.
Why is this not possible ?

>In summary, I don't think we can define MH-PW setup without looking at the impact it has on autodiscovery.
I agree that we have to look at autodiscovery as well, but I do not see 
why we have to merge the autodiscovery with the maintenance and 
signaling protocol. Currently we have done well by having a PW 
maintenance and signaling protocol separate from autodiscovery.

Also please keep in mind L2TPV3 as well ... This is not just an MPLS to 
MPLS case.
Thanks.
Luca

>>>>>Regarding ii), this is only required if routers use the 
>>>>>          
>>>>>
>>same address
>>    
>>
>>>>>be routable. In the (PW) data plane the PW label needs to 
>>>>>          
>>>>>
>>be used at
>>    
>>
>>>>>be routable at the PW level, they are not routable at the 
>>>>>          
>>>>>
>>tunnel LSP
>>    
>>
>>>>>belong to the PW layer, i.e. each hop must support PW 
>>>>>          
>>>>>
>>switching. For
>>    
>>
>>>>>scaling reasons its highly unlikely that a single LSP 
>>>>>          
>>>>>
>>layer would be
>>    
>>

---

From: [email-masked]
Date: Tue, 10 Aug 2004 08:32:52 +0100

Peter,

Of all the voices out there (and ignoring my colleagues in BT) yours is
the closest I have heard to making any sense and realising what is going
on here.  

PW switching is creating a new layer network (though I am not convinced
some folks understand that remark, even though Richard (Spencer) tried
hard to explain it a while back).  And if this WG continues to go here
then *all* the functional components need specifying for this
up-front....else we are very likely to see continued kludges.  However,
the base problem is that PWs are starting from a flawed assumption that
MPLS == IP. The real problem is therefore being masked.  I can only
speak for BT as an operator....we want to see MPLS sorted and we do not
need/want a new PW layer network defined as its wrong and unnecessary.
XoverMPLS is a client/server relationship for which additional
requirements must be met.  XoverIP (or XoverSDH say) is *not* the same
problem even though some seem to think it is.

And none of this is actually difficult/complex if its done right.

Put bluntly.....a problem has been created (and is now growing) that
simply should not exist, and because some folks are so far down a
certain road it is my opinion that they cannot see what the real issues
are any longer.

Luca.....given you stated some 'requirements' in a recent mail, let me
ask you the question I posed earlier....who do *you* think you are
writing this stuff for now:
-	the public Internet?.....I really think not.....the Internet
does not have legacy networks and does not need a convergence story
-	Alnets?....not from a convergence perspective as they probably
don't have (any or significant) legacy networks either.....so maybe from
a 'we want a slice of the L2 action' perspective, but I'd have to
question the longer-term sanity of this even for them
-	enterprises?.....probably the closest fit in some cases
-	trad operators?....I really don't don't think so as-is, even
though its these folks that most need the convergence story sorted (and
its also what the opening lines of the proposed revised PWE3 charter
seem to imply is the target audience).

Regards, Neil

> I agree that autodiscovery belongs in L2VPN and not in PWE3. 
> However, the consequence of accepting 
> draft-martini-pwe3-pw-switching-00.txt is that autodiscovery 
> must be based on the LDP identifiers defined in the control 
> draft (i.e. PWids, AGIs and AIIs). Is that the right approach?
> 
> In fact, in the case of Multi-hop PWs, the autodiscovery 
> mechanism used between PEs does not necessarily extend to PW 
> Switching Nodes. PEs need to exchange information about 
> Attachment Circuits, but PW Switching Nodes only need to have 
> enough knowledge to establish end-to-end PWs. 
> Draft-martini-pwe3-pw-switching-00.txt does not allow one to 
> make that distinction. It assumes that every node (both PEs 
> and PW Switching Nodes) maintain AC-related information.
> 
> In summary, I don't think we can define MH-PW setup without 
> looking at the impact it has on autodiscovery.
> 
>

---

From: [email-masked]
Date: Tue, 10 Aug 2004 08:44:21 +0100

Luca,

> peering or Frame-Relay SPVC peering.

I'm not sure what you mean by this. If you are suggesting that stitching together PWs to make MH-PWs is akin to ATM/FR SPVC peering then I disagree. At the PW layer, each MH-PW has a source, destination and one or more switching points. Connectivity between these is provided by multiple server layer partitions that appear to the PW client layer as 1 hop p2p links. Therefore, a MH-PW can be described as being akin to a single ATM or FR SPVC, not the peering of ATM/FR SPVCs.

If you are specifically referring to the inter-provider/AS case, then I still don't see the relevance. Are you suggesting that because providers use static provisioning at peering points today for their existing connection-orientated packet switching technologies (i.e. ATM/FR), that they should continue to do the same for MPLS? I think the question comes down to scaling, MPLS has been selected as the convergence technology by many providers for all services (i.e. voice, broadband, mobile, leased line, etc.) and therefore must be highly scalable. Due to the number of different services that MPLS will need to support and the (global) coverage that will be expected, the inter-provider/AS peering requirements are likely to be very different for MPLS than for ATM/FR today. Static provisioning may be used for MPLS inter-provider/AS peering in the short term, but one would expect that a secure, scalable, dynamic solution would need to be developed in the long term if MPLS is to succeed as the global convergence technology of the future.

Regards,
Richard

---

From: [email-masked]
Date: Tue, 10 Aug 2004 08:51:43 +0100

Thanks Richard, and of course I generally agree with you....but some
small remarks below.
> Regarding the distribution of PW layer reachability 
> information for MH-PWs, I would argue that this information 
> must always be distributed (or collected) whether manual or 
> dynamic provisioning methods are used. To set up a path 
> across multiple hops where alternative paths exist, routing 
> must be performed, there is no getting away from this. If a 
> human operator manually configures a MH-PW then the routing 
> function is performed by the human operator and the human 
> operator collects the reachability information by analysing 
> the network topology information. If OSS systems are used 
> then the OSS system must perform the routing function and 
> discover the topology of the network by requesting or 
> collecting reachability/switching node capability 
> information. If dynamic routing protocols are used to perform 
> the routing function then reachability/switching node 
> capability information must be distributed/collected by PEs 
> and PW switching nodes via the routing protocol. As 
> provisioning by a human operator obviously doesn't scale, 
> provisioning for MH-PWs must be carried out either by OSS or 
> dynamic protocols, which means that the PEs and PW switching 
> nodes must advertise (or respond to requests for) 
> reachability/switching node capability information.
> 
> Regarding PW end point identifiers for routing purposes, as 
> things stand today I think out of the two options below, 
> routing based on PE IP addresses (option a) is preferable to 
> using AGI/AII combinations (option b). The main reasons being:
> 
> (1) From the PWE3 control draft: "The Attachment Identifier 
> must be unique in the context of the PE router in which the 
> Forwarder resides.  The combination <PE router, AI> must be 
> globally unique." So, even if the AGI/AII are used, the PE IP 
> addresses must be used as well anyway. 
> 
> (2) Reachability information based on [AGI/AII/PE IP address] 
> destination identifiers would need to be advertised and 
> stored in a routing table (if a dynamic routing protocol is 
> used) on each PE and PW switching node. This does not seem 
> desirable looking at things from a vendors perspective 
> because the PW routing table implementation would need to 
> support variable/unknown length identifiers as destinations.
NH=> OK, but the really important point to get from any of this is that
we need PW addressing.  This is not IP layer network addressing.  This
is not MPLS layer network addressing (this also needs sorting BTW).  I
wonder if folks really grasp this point?  I sometimes think now.  But a
plea.....the addressing of a layer network is one of its most important
functional attributes.  You should think very carefully before defining
an addressing structure.  If you screw this up at t=0 its almost
impossible to change (easily anyway) later.   For example, IPv6 is not
IPv4 'with some enhancements' its a completely different layer network.
A VC4 layer network in SDH does *not* have the same addressing space as
the SDH VC12 layer network.  It does not matter that addressing
structures might look similar, they reside is a completely different
space.  And when/if folks finally realise we need an OOB
control/management plane for MPLS then they will also have to come to
terms with the fact that the addressing of the traffic and
control/management plane networks also reside in disjoint spaces.
Security is very important....why on earth would one make the
internal/sensitive control/management protocols a target for hacking
when there is no need to?  Go learn from the GMPLS folks what they had
to do here for SDH and OTNs.
> 
> Saying that, in theory, using AGI/AIIs would make sense 
> because AGI/AIIs belong to the PW layer and therefore routing 
> would be based on address/naming information pertinent only 
> to the PW layer.
NH=> Bang on.....but is this a *good* addressing structure?

> The problem is that the naming method used 
> to identify a PW access point (forwarder) is based on the PE 
> IP address (which exists at the MPLS tunnel layer) plus a 
> locally unique AI (which exists at the PW layer). Having 
> thought about it, I think option (a) could be made to work if 
> a globally unique identifier (e.g. an IPv6 address) was used 
> to identify a PW access point.
NH=> What a novel idea, ie use a good structure up-front.....not saying
PWs is the right place to do this of course, but I can think of a
network layer that could make good use of this right now ;-)

Regards, Neil

> The AGI could still be used to 
> identify a PW VPN, but the AII would uniquely identify a PW 
> access point (on a global PW layer network basis). This would 
> solve problem (1) because the AII would be globally unique 
> and therefore the PE IP addresses (belonging to the MPLS 
> tunnel layer) would not be required, and problem (2) would be 
> solved because the destination would be a fixed length IPv6 
> address. The idea of using IPv6 addresses for identifying 
> forwarders could be taken a step further by making a 
> forwarder a manageable logical entity, i.e. a logical PW 
> interface that could be managed just like any other 
> interface. This would also be an advantage from an OAM 
> perspective as the PW endpoint identifiers would uniquely 
> identify the PW layer source and sink access points.
> 
> Of course there is nothing stopping a provider using IPv6 
> addresses for AIs (PW access points) today. The problem is 
> that because using IPv6 addresses for AIs is not mandatory, 
> to fully support option (a) vendors would still need to 
> address problem (2) by implementing a PW routing table that 
> supports unknown/variable length destination identifiers, and 
> address problem (1) by at least having an option for using 
> AGI/AII + PE IP address identifiers, rather than just AIIs.
> 
> Regards,
> Richard
>

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 10 Aug 2004 01:23:57 -0700 (PDT)

Hi Hamid,

>    allocation points (suggest stick with one or two terms).

draft-raggarwa-rsvpte-pw-00.txt propopses definitions for some of the
above. Once the WG settles on the terminology, we should certainly include
it in a single document.

> >   (just switching per config).

The above should probably be captured in a PW-Requirements2 document. I
would  add the following to the list:
    - PW QoS
    - PW Redundancy

rahul

---

From: [email-masked]
Date: Tue, 10 Aug 2004 09:59:11 +0100

Luca,

> choice on what parameters identify a PW.

I disagree, this implies that the WG does not have the power to change or make amendments to decisions that have already been made. If WG consensus was reached that the parameters currently defined for identifying PWs were not suitable for MH-PWs, then there is no reason why alternative parameters couldn't be added (at least as optional) in separate/revised drafts. Especially considering the draft(s) in question are not even RFCs yet.

> have to merge the auto provisioning of PW , and the signaling 

I don't think Peter is suggesting that auto-provisioning and signalling should be merged or described in the same document. I think he is just pointing out that if auto-discovery was to be based on PW endpoint identifiers, because of the way PW end/mid points (or access points) are currently identified, autodiscovery would be dependant on the signalling mechanism used. For example, PW end points established using FEC 128 are identified by the PWid+PE IP address, whereas PW end points established using FEC 129 are identified by the AGI/AII+PE IP address, i.e. endpoint identification is dependent on the signalling mechanism used. If PWs were identified using the same identifier regardless of the signalling protocol used, then in turn auto-discovery would not be dependent on the signalling protocol used. A further improvement would be to use a unique identifier that is only pertinent to the PW layer, e.g. an IPv6 address, which would be a significant advantage from a management and OAM perspective.

Regards,
Richard

---

From: [email-masked]
Date: Tue, 10 Aug 2004 10:27:25 +0100

Richard....spot on....1 additional remark where I want to reinforce
something important.

> I disagree, this implies that the WG does not have the power 
> to change or make amendments to decisions that have already 
> been made. If WG consensus was reached that the parameters 
> currently defined for identifying PWs were not suitable for 
> MH-PWs, then there is no reason why alternative parameters 
> couldn't be added (at least as optional) in separate/revised 
> drafts. Especially considering the draft(s) in question are 
> not even RFCs yet.
> 
> I don't think Peter is suggesting that auto-provisioning and 
> signalling should be merged or described in the same 
> document. I think he is just pointing out that if 
> auto-discovery was to be based on PW endpoint identifiers, 
> because of the way PW end/mid points (or access points) are 
> currently identified, autodiscovery would be dependant on the 
> signalling mechanism used. For example, PW end points 
> established using FEC 128 are identified by the PWid+PE IP 
> address, whereas PW end points established using FEC 129 are 
> identified by the AGI/AII+PE IP address, i.e. endpoint 
> identification is dependent on the signalling mechanism used. 
NH=> And this is one thing that is clearly wrong....and its happened
before with MPLS.  An address is an attribute of an access point in the
data-plane.  It has nothing to do with signalling (nor routing for that
matter).  And specifically signalling should not determine addressing.
What happens if we decide to change the signalling?  What happens if we
use the NMS/OSS to set-up the trail?

Regards, Neil

> If PWs were identified using the same identifier regardless 
> of the signalling protocol used, then in turn auto-discovery 
> would not be dependent on the signalling protocol used. A 
> further improvement would be to use a unique identifier that 
> is only pertinent to the PW layer, e.g. an IPv6 address, 
> which would be a significant advantage from a management and 
> OAM perspective.
> 
> Regards,
> Richard
>

---

From: [email-masked]
Date: Tue, 10 Aug 2004 14:43:42 +0100

Folks, I have had a few private mails asking me to explain something I
noted below.....so just in case other folks are having problems with my
terse and/or poor explanation let me spell it out:

I said (extracted from below):
"An address is an attribute of an access point in the data-plane.  It
has nothing to do with signalling (nor routing for that matter)."

So to better explain what I meant here:

An address defines an access point of a network or subnetwork (this is a
G.805 func arch term, it's not an IP subnet).  It is an attribute of the
data-plane of some layer network (this can be any mode, ie cl-ps, co-ps
or co-cs).  Signalling and routing are 2 additional functional
components (there are more than this, but this is all that is relevant
here). 

Depending on the mode the signalling and routing (and other management)
components can operate in-band or out-of-band wrt to the data-plane that
will be carrying the traffic.  In fact, when we take these components
OOB (for important security/stability/resilience reasons) the mode of
the control/management data-plane network can be cl-ps whilst that of
the traffic data-plane network co-ps or co-cs (cf GMPLS which is exactly
like this for SDH or OTN say).  Note also that the addressing of these 2
layer networks (ie 1 for traffic and 1 for control/management) operate
in quite different spaces.

So, whilst routing and signalling protocols carry addressing (of the
traffic data-plane) they should be agnostic to the nature of that
addressing.  However, there is further key point regarding the
relationship between addressing and topology (and thus the impact on
routing advertisements)........

Addressing and topology are coupled.  The tighter the coupling the more
efficient can be the address aggregation (ie summarisation in routing
advertisements), and vice versa (ethernet is an extreme example of the
latter case.....and here the address has completely degenerated into a
'name' since it carries no topological information of 'where').
However, the coupling must not be too tight or else changes in topology
impact addressing schemes...and that is not a good idea either.

Hope that clarifies.  

Regards, Neil

> From: Harrison,N,Neil,IKR2 R 
> Sent: 10 August 2004 10:27
> To: Spencer,R,Richard,XGH5 R; [email-masked]'; 
> [email-masked]'
> Cc: [email-masked]'; [email-masked]'; 
> [email-masked]'; [email-masked]'
> Richard....spot on....1 additional remark where I want to 
> reinforce something important.
> 
> > Luca,
> > 
> NH=> And this is one thing that is clearly wrong....and its 
> happened before with MPLS.  An address is an attribute of an 
> access point in the data-plane.  It has nothing to do with 
> signalling (nor routing for that matter).  And specifically 
> signalling should not determine addressing.  What happens if 
> we decide to change the signalling?  What happens if we use 
> the NMS/OSS to set-up the trail?
> 
> Regards, Neil
>

---

From: John Drake <[email-masked]>
Date: Tue, 10 Aug 2004 07:23:43 -0700

I think Peter raises some very valid points

> Sent: Monday, August 09, 2004 3:39 PM
> To: 'Luca Martini'
> Cc: [email-masked]; [email-masked]; [email-masked];
> 'Mustapha Aissaoui'; [email-masked]; [email-masked]
> I agree that autodiscovery belongs in L2VPN and not in PWE3. However, the
> consequence of accepting draft-martini-pwe3-pw-switching-00.txt is that
> autodiscovery must be based on the LDP identifiers defined in the control
> In fact, in the case of Multi-hop PWs, the autodiscovery mechanism used
> between PEs does not necessarily extend to PW Switching Nodes. PEs need to
> exchange information about Attachment Circuits, but PW Switching Nodes
> only need to have enough knowledge to establish end-to-end PWs. Draft-
> martini-pwe3-pw-switching-00.txt does not allow one to make that
> distinction. It assumes that every node (both PEs and PW Switching Nodes)
> maintain AC-related information.
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 10 Aug 2004 12:58:31 -0400

Luca,

I think the framework sections/draft will help clarifying
the terminology and convey a common understanding of the
problem that is being solved (I don't see requirements
to be that much useful if people have different understanding
and interpretation of the objectives and problem being solved). 
Anyway, as long as all this is clarified in the 
requirement draft I am perfectly fine with that.

See some comments inline...

> need me to add anything ?

Sounds a good start. I have one comment though.

It seems that multihop PW has been defined in terms of
switching a set of PWs. What it doesn't specify is whether 
the ingress and egress PE (ultimate PEs) are aware this is 
in fact a MH-PW and not an independent single hop 
pseudowire that is being switched to other pseudowires.

PW switching can happen even if the originating PE is
not aware (for example at the control plane)
that its PW is being switched to other pseudowires. 

Take for example the VPLS case when used in
the context of distributed/hierarchical scenario. 
The U-PE (low end Ethernet bridge) is not required to know 
that its pseudowire that lead to the N-PE is being 
switched/spliced to a set of N-PEs
and then to other remote PE or U-PE, nor it needs to
know about the "switching point TLVs".

Though the end to end is a spliced pseudowire (here is another 
term for "PW switching" being already used in l2vpn 
signaling ;-)), the originating PE didn't specify
in terms of control any information that indicates the
intent is to establish a MH-PW instead of an
"independent" PW. 

In other words "PW switching" does not necessarily implies
a MH-PW (while MH-PW implies somewhere PW switching
is performed). In the context of MH-PW, the originating PE 
knows apriori that it wants to establish a MH-PW or the
PW segment being established is member of a MH-PW. 

Note that in this definition of MH-PW, a given MH-PW 
can as well be "PW switched" to other MH-PWs 
(not just SH-PWs). 

It looks to me we need to disambiguate between these cases
in the requirements/framework doc:

a) PW switching/splicing
b) MH-PW where a PE that explicitly indicates its intent 
   to establish a Multihop Pseudowire instead of independent 
   PW.
c) Independent PW (lets call it the I-PW who is a single hop 
   BUT not part of any MH-PW) versus PW segment member of
   MH-PW (the one you cal SH-PW). 
d) an independent PW that is being PW switched
   (an ingress PE is not aware of the PW switching function
    taking place).
d) a PW segment that is member of MH-PW.
e) a MH-PW that is composed of only PW segments.
f) a MH-PW that is composed of PWs and possibly
   other native l2 circuits.

For MH-PW I would have assumed that the originating PE somehow 
needs to indicate (for example at the control plane) or it needs 
at least to know that the intent is to establish a MH-PW instead of 
"independent" PW to a given remote forwarder (or remote PE) 
with no possibility of establishing an end-to-end signaling 
adjacency to the ultimate PE. That remote forwarder can
be located at a given switching point or at the ultimate PE.

> This would be more suited for a requirement draft.

Sure.

[clipped...]

> defined ?  or regarding autodiscovery ?

For MH-PW, the ingress PE may indicate a set of information
such as identification of the forwarder on the ultimate PE and
can as well indicate (if it has that information) the "PW path"
to be used. 

The switching TLVs you mentioned are just used
to indicate to the originating PE the actual path of MH-PW and
as indicated in the draft the TLVs are used for troubleshooting
purposes. In this scenario the MH-PW path is implicit done 
through configuration. That path can be explicitly signaled by 
the ingress PE (that's what I referred to implicit/explicit
without indicating what mechanism can be used to determine
that path -i.e., discovery, routing, provisioning, etc).

Hamid.

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Aug 2004 08:37:07 -0600

>I disagree, this implies that the WG does not have the power to change or make amendments to decisions that have already been made. If WG consensus was reached that the parameters currently defined…
This is true , and I do not have any issue with adding some kind of new 
autodiscovery parameter.
I am not sure what we are discussing here .... I have no problem in 
doing any of the things you are describing.
All I was pointing out is to keep in mind that we have to make a 
differentiation between autodiscovery , and signaling/maintenance 
protocols. Both still have to be considered together, and should  be 
designed to meet the requirements.
This might give rise to more then one draft , and certainly not all 
drafts will be part of PWE3.

>I don't think Peter is suggesting that auto-provisioning and signalling should be merged or described in the same document. I think he is just pointing out that if auto-discovery was to be based on…
I fully Agree.

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Aug 2004 08:43:29 -0600

[email-masked] wrote:

> <>NH=> And this is one thing that is clearly wrong....and its happened
Neil,
So what you are saying is that the addressing is independent of the 
signaling ?
I agree with this point.

Luca

---

From: Luca Martini <[email-masked]>
Date: Wed, 11 Aug 2004 09:09:42 -0600

Hamid,

See comments in line...

>pseudowire that is being switched to other pseudowires.
The ultimate PEs do not have to be aware that the PW is being switched.

>intent is to establish a MH-PW instead of an
This is exactly the pw-switching draft model.
We added a pw switching TLV, ( added by the pw switching point ) for 
management and debugging purposes. It is not used to control singnalling.

>   other native l2 circuits.
basically , you want a lot nore terms defined ;-)
b) could be called a inter-domain PW.
c) is a SH-PW
d) is a PW
e) is == b)  I'm not sure why the difference would be useful
f) is not a PW. If it includes native ACs then it is more a VC, or an 
ethernet vlan ......

>be located at a given switching point or at the ultimate PE.
why would the originating PE "need" to know the intent to establish an 
MH-PW ?
( the operator might need to know , but why the PE ? )

>>>    PW (not sure this is needed?).
So goen the fact that AS# seem to be a BGP concept , we should stick 
with the inter-domain term. ( one AS can have many PW domains as the two 
are not related )

>that path -i.e., discovery, routing, provisioning, etc).
The idea here was not to preclude this functionality. PW source routing 
, and PW routing can still be acheived with an autodiscovery/PW routing  
protocol. This pw-switching design did not intend to preclude it at all.
So, if a ultimate PE needs to setup a PW to another U-PE in a different 
domain it becomes a provisioning exercise that can be done by NMS, BGP, 
Radius , or any other protocol you can think of.

Luca

---

From: Cheng-Yin Lee <[email-masked]>
Date: Wed, 11 Aug 2004 17:14:18 -0400

Richard,

[email-masked] wrote:

> Regarding the distribution of PW layer reachability information for MH-PWs, I would argue that this information must always be distributed (or collected) whether manual or dynamic provisioning methods are used. To set up a path across multiple hops where alternative paths exist, routing must be performed, there is no getting away from this. If a human operator manually configures a MH-PW then the routing function is performed by the human operator and the human operator collects the reachability information by analysing the network topology information. If OSS systems are used then the OSS system must perform the routing function and discover the topology of the network by requesting or collecting reachability/switching node capability information. If dynamic routing protocols are used to perform the routing function then reachability/switching node capability information must be distributed/collected by PEs and PW switching nodes via the routing protocol.

Very much in agreement with the above

> As provisioning by a human
> operator obviously doesn't scale, provisioning for MH-PWs must be carried out either by OSS or dynamic protocols, which means that the PEs and PW switching nodes must advertise (or respond to requests for) reachability/switching node capability information.

as well as the above

> (2) Reachability information based on [AGI/AII/PE IP address] destination identifiers would need to be advertised and stored in a routing table (if a dynamic routing protocol is used) on each PE an…

Could we not decouple VPN membership discovery from routing ?

Thanks
Cheng-Yin

>
>
> Saying that, in theory, using AGI/AIIs would make sense because AGI/AIIs belong to the PW layer and therefore routing would be based on address/naming information pertinent only to the PW layer. The problem is that the naming method used to identify a PW access point (forwarder) is based on the PE IP address (which exists at the MPLS tunnel layer) plus a locally unique AI (which exists at the PW layer). Having thought about it, I think option (a) could be made to work if a globally unique identifier (e.g. an IPv6 address) was used to identify a PW access point. The AGI could still be used to identify a PW VPN, but the AII would uniquely identify a PW access point (on a global PW layer network basis). This would solve problem (1) because the AII would be globally unique and therefore the PE IP addresses (belonging to the MPLS tunnel layer) would not be required, and problem (2) would be solved because the destination would be a fixed length IPv6 address. The idea of using IPv6
> addresses for identifying forwarders could be taken a step further by making a forwarder a manageable logical entity, i.e. a logical PW interface that could be managed just like any other interface. This would also be an advantage from an OAM perspective as the PW endpoint identifiers would uniquely identify the PW layer source and sink access points.
>

---

From: [email-masked]
Date: Thu, 12 Aug 2004 07:08:34 +0100

Cheng-Yin,

> Could we not decouple VPN membership discovery from routing ?

VPN membership discovery is already decoupled from routing. In the MH-PW case there are two aspects to discovery, i) discovery of PW endpoints and ii) discovery of PW switching capable nodes. Discovery of VPN endpoints is always required as these are not known prior to PW provisioning, i.e. the endpoints are not known until a provider receives the customer request for the VPN. 

However, discovery of PW switching points is only required because the same (IP loopback) address space is used at the client PW layer that is used at the MPLS tunnel server layer. A MH-PW next hop must always be a PW switching capable node (or the destination endpoint PE), and therefore non PW switching nodes must be distinguished from those that do support PW switching.

As discussed on the list, one way to solve the problem and keep the same addressing would be to use a discovery mechanism along with a separate PW routing table that only contains routing information for MH-PW source/destination PEs and PW-switching capable nodes, i.e. routing information pertinent only to the PW layer. Another way to solve the problem and keep the same addressing would be to use FA-LSPs and routing metrics to ensure that FA-LSPs are always the best next hop. Discovery of PW switching capable nodes in this solution is implicit, i.e. the best next hop to a PW endpoint by implication should be PW switching capable.

Regards,
Richard

---

From: [email-masked]
Date: Thu, 12 Aug 2004 08:28:02 +0100

Cheng-Yin...

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Cheng-Yin Lee
> Sent: 11 August 2004 22:14
> To: Spencer,R,Richard,XGH5 R
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> > Regarding the distribution of PW layer reachability information for 
> > MH-PWs, I would argue that this information must always be 
> distributed 
> > (or collected) whether manual or dynamic provisioning methods are 
> > used. To set up a path across multiple hops where alternative paths 
> > exist, routing must be performed, there is no getting away 
> from this. 
> > If a human operator manually configures a MH-PW then the routing 
> > function is performed by the human operator and the human operator 
> > collects the reachability information by analysing the network 
> > topology information. If OSS systems are used then the OSS 
> system must 
> > perform the routing function and discover the topology of 
> the network 
> > by requesting or collecting reachability/switching node capability 
> > information. If dynamic routing protocols are used to perform the 
> > routing function then reachability/switching node capability 
> > information must be distributed/collected by PEs and PW switching 
> > nodes via the routing protocol.
> 
> > operator obviously doesn't scale, provisioning for MH-PWs must be 
> > carried out either by OSS or dynamic protocols, which means 
> that the 
> > PEs and PW switching nodes must advertise (or respond to 
> requests for) 
> > Regarding PW end point identifiers for routing purposes, as things 
> > stand today I think out of the two options below, routing 
> based on PE 
> > IP addresses (option a) is preferable to using AGI/AII combinations 
> > (option b). The main reasons being:
> >
> > (1) From the PWE3 control draft: "The Attachment Identifier must be 
> > unique in the context of the PE router in which the 
> Forwarder resides.  
> > The combination <PE router, AI> must be globally unique." 
> So, even if 
> > the AGI/AII are used, the PE IP addresses must be used as 
> well anyway.
> >
> > destination identifiers would need to be advertised and stored in a 
> > routing table (if a dynamic routing protocol is used) on 
> each PE and 
> > PW switching node. This does not seem desirable looking at 
> things from 
> > a vendors perspective because the PW routing table implementation 
> > would need to support variable/unknown length identifiers as 
> > destinations.
> 
NH=> Yes of course, but one needs to look at the overall VPN service
problem to put these functions in their correct context....let me try
and explain.    Knowing the membership of a 'club' does not tell you
where the members live or how to get/connect between them......but
clearly all of these are required functions and part of the VPN service
problem (route-calculation is but 1 facet here).

IMO there are 2 quite disjoint layer network tasks when considering VPNs
(any)....the 1st is common to all VPNs (and has 3 subtasks that require
different behaviour) whilst the 2nd is a possible value-add function,
viz:
A	there is the task of server layer topology creation
B	there is the optional value-add task of client layer
reachability distribution

These tasks are orthogonal and should not be lumped together.

Task A is the biggest and most important one and contains 3 subtasks:
1	Discover *who* belongs to the VPN.....so this is all about
learning the sites (read as 'server layer addresses') in *whatever* the
mode/technology is being used for the server layer network.
2	Calculate *routes* between the server layer addresses, ie how to
establish paths across the server layer network.....so this is the
route-calculation bit.
3	Create *paths* within the server layer network (the nature of
the 'paths' and the management of them is mode/technology
dependent.....and it is specifically *not* the same across the cl-ps,
co-ps and co-cs modes).

Now one could lump sub-tasks 1 and 2 above together in some server layer
routing process, but certainly not sub-task 3.....this is either a NMS
provisioning job or (better) it is done via a signalling agent under the
control of the NMS.

Note carefully that task A is all about server layer topology creation,
and if we stop here we have merely automated the creation of what I
would call 'a simple managed BW service'.....something folks sometimes
call (wrongly) a 'L1 or L2 VPN'.  It can apply to *any* mode/technology,
but for commercial VPNs where one requires both client layer
reachabililty isolation and strong traffic/performance isolation it
really only makes sense to use either co-cs or co-ps mode technologies
IMO.  I know folks can use cl-ps here (well this is the IETF!) but I am
trying to be precise about understanding the real differences across
each of the modes.....they are not alike and we can do things smarter as
long as we properly understand this and what is going on functionally
here.

Now let's look at the functional behaviour required in each of these
tasks/sub-tasks:

Task A

-	Sub-task 1 - this lends itself to a centralized query/response
behaviour.  So a solution like radius is ideal.  Other solutions such as
BGP-based say are not ideal as they are broadcast in nature.

-	Sub-task 2 is a computation issue about route
calculation......this can be done in either a distributed or centralised
manner in the *server* layer mode/technology (this has nothing to do
with the client layer please note)

-	Sub-task 3 is a path creation task.  It is best carried out IMO
by a proper signalling protocol/agent in the server, working closely
under the (ultimate) control of the NMS.  So this could be RSVP-TE say
for server layer when this is based on either the co-ps or co-cs mode.
The subsequent operational fault/performance management of the server
layer varies depending on its mode.....1 size does not fit all here.

As noted, if we stop here this creates a simple managed BW VPN in the
server layer.

If we want to add-value as a SP we can add client layer
reachability.....so this is:

Task B

Here a 'broadcast' behaviour (ideally limited to between same-member
sites of a given VPN only) is required to distribute client layer
reachability across VPN member sites.....so its here that MP-BGP finds a
good role.  Note that this function has nothing to do with the server
layer stuff under task A.

Now that's breaking the VPN service problem back into its logical
components IMO.  Clearly the functional solution should not be the same
for all tasks as the required behaviours are different.  Speaking as a
SP I like looking at the VPN service creation problem like this, as:
-	it clearly shows me that there is a common theme across all
modes/technologies, which is important for NMS/OSS and functional
re-use;
-	it points us at the right functional solutions for the given
task/sub-task....and clearly these are not the same, so a '1 protocol
fits all' solution is not a good idea IMO.

Richard has been working on precisely the above issues in some R&D work
I have been running in BT because I got rather disillusioned with seeing
folks argue that 'my protocol is better than yours'.  There is a generic
way to do VPNs IMO across all modes, and its looking at the problem as
above that is key.  So I not surprised that you find much of what
Richard says as making sense.

Regards, Neil
	
> 
> Thanks
> Cheng-Yin
> 
> >
> >
> > Saying that, in theory, using AGI/AIIs would make sense because 
> > AGI/AIIs belong to the PW layer and therefore routing would 
> be based 
> > on address/naming information pertinent only to the PW layer. The 
> > problem is that the naming method used to identify a PW 
> access point 
> > (forwarder) is based on the PE IP address (which exists at the MPLS 
> > tunnel layer) plus a locally unique AI (which exists at the 
> PW layer). 
> > Having thought about it, I think option (a) could be made 
> to work if a 
> > globally unique identifier (e.g. an IPv6 address) was used 
> to identify 
> > a PW access point. The AGI could still be used to identify 
> a PW VPN, 
> > but the AII would uniquely identify a PW access point (on a 
> global PW 
> > layer network basis). This would solve problem (1) because the AII 
> > would be globally unique and therefore the PE IP addresses 
> (belonging 
> > to the MPLS tunnel layer) would not be required, and 
> problem (2) would 
> > be solved because the destination would be a fixed length IPv6 
> forwarders 
> > could be taken a step further by making a forwarder a manageable 
> > logical entity, i.e. a logical PW interface that could be 
> managed just 
> > like any other interface. This would also be an advantage 
> from an OAM 
> > Of course there is nothing stopping a provider using IPv6 addresses 
> > for AIs (PW access points) today. The problem is that because using 
> > IPv6 addresses for AIs is not mandatory, to fully support 
> option (a) 
> > vendors would still need to address problem (2) by 
> implementing a PW 
> > routing table that supports unknown/variable length destination 
> > identifiers, and address problem (1) by at least having an 
> option for 
> > using AGI/AII + PE IP address identifiers, rather than just AIIs.
> >
> > Regards,
> > Richard
> >
> exchange have 
> > > pros and cons. Within the scope of the requirements 
> (which we will 
> > > document, as we discussed in San Diego), it is very well possible 
> > > that the cons outweight the pros. Or vice versa. We will see. 
> > > However, you seem to have decided already that routable PWs are 
> > > forbidden under any circumstances.
> > >
> > > You write: "My point is that the PW dataplane forwarding decision 
> > > should be local to a stitching node and not network wide."
> > >
> > > I have no idea what you mean by that. The dataplane forwarding 
> > > decision is always local. The stitching node receives a 
> packet with 
> > > PW Label A, swaps it with PW Label B and forwards it over the 
> > > appropriate tunnel.
> > >
> > > The issue is how the stitching node supports signaling. 
> It receives 
> > > a PW setup request (in the current model, an LDP label mapping 
> > > message) and somehow has to determine what the next node on the 
> > > Multi-hop Path is. In all likelyhood, that next hop will 
> be derived 
> > > from one or more identifiers that identify the end point of the 
> > > MH-PW.
> > >
> > > There are two options:
> > >
> already has 
> > > (a prefix of) the PE's IP address in its routing table, 
> it seems to 
> > > me that a) is more straightforward than b). Not only 
> that. Solution 
> > > b) requires a topology discovery protocol based on AGIs and AIIs.
> > >
> > > I am not sure how to interpret this statement. It sounds 
> as if you 
> > > agree with me that a) is the better solution. However, you are 
> > > arguing vehemently against my position. Therefore, the 
> only thing I 
> > > can imagine is that you believe that any form of automated MH-PW 
> > > setup is undesirable and that Service Providers will be perfectly 
> > > happy to manually provision MH-PWs.
> > >
> > > > > > this issue is in my view one of the critical 
> issues. I believe 
> > > > > > a workable solution should have the following 
> characteristics:
> > > > > >
> > > > > > 1. State how stitching nodes are discovered. I do not agree 
> > > > > > with Peter that a stiching node is just another LSP 
> switching
> > > > node. There
> > > > > I agree that a PW stitching node is not just another (tunnel) 
> > > > > LSP switching node. The data plane behaviour (i.e. MPLS label
> > > > switching) may
> > > > > (or separate control protocols/instances used) in order to 
> > > > > support single sided provisioning of switched PWs.
> > > >
> > > > side trigger the PW setup (master PE) and the other reply only 
> > > > when it receives it (slave PW). This is the dominant mode of 
> > > > operation of SPVCs in ATM networks today.
> > > >
> > > > > the MPLS tunnel layer. If a different address space was used 
> > > > > then support for PW switching would be explicit. The 
> consequence
> > > > of using the
> > > > > > anything against that but if a solution turns PWs into 
> > > > > > routable entities on their own, then we should 
> discuss it in 
> > > > > > that wider context. In that case, the use of tunnel LSPs 
> > > > > > becomes a
> > > > convenience
> > > > > routing where tunnel LSPs are not used (resulting in a single 
> > > > > LSP layer).
> > > >
> > > > tunnels, it does not make sense to make them routable (network 
> > > > wide) and have their own address  space.
> > > >
> > > > not belive that we want to solve the general problem where any 
> > > > node can be used as a stitching node because this 
> degenerates into 
> > > > the case where you will be forced to have a separate 
> routing and 
> > > > different. I assume that a static PW may be just fine if the 
> > > > access network is simple. In complex access and aggregation 
> > > > networks, one can have build a separate PSN for this 
> network and 
> > > > perform switching at some well idnetified edge nodes.
> > > >
> > > > > Regards,
> > > > > Richard
> > > >
> > >
> 
> 
>

---

From: Cheng-Yin Lee <[email-masked]>
Date: Thu, 12 Aug 2004 16:14:39 -0400

Richard,

> Regarding PW end point identifiers for routing purposes, as things stand today I think out of the two
> options below, routing based on PE IP addresses (option a) is preferable to using AGI/AII combinations
> (1) From the PWE3 control draft: "The Attachment Identifier must be unique in the context of the PE
> router in which the Forwarder resides.  The combination  must be globally unique." So,
> even if the AGI/AII are used, the PE IP addresses must be used as well anyway.
>
> (2) Reachability information based on [AGI/AII/PE IP address] destination identifiers would need to be
> advertised and stored in a routing table (if a dynamic routing protocol is used) on each PE and PW
> switching node. This does not seem desirable looking at things from a vendors perspective because the
> PW routing table implementation would need to support variable/unknown length identifiers as
> destinations.
>
>
I agree routing based on PE IP addresses is preferable.
But I have doubts with the need to store [AGI/AII/PE IP address] or the PW endpoint identifiers in routing tables at PW switching nodes.
For e.g. assume there is a routing protocol which advertises PW switching nodes (and capability) and PE links/routes..
Then routing at PE-X knows the next-hop to PE-Y for a PW (to PE-Y, AIY)  is PW-SW1 (PW Switching node). Similarly routing at PW-SW1 knows the next-hop to PE-Y is PW-SW2. There is no need to store PEY+AIY information in the routing table. [The PEY+AIY information can be stored by signaling].

AIX---PE-X----PW-SW1---PW-SW2----PE-Y---AIY

As you suggest using IPv6 for  PW  endpoint identifier may be convenient from OAM perspective, for e.g. to be able to identify at each PW switching hop where the PW is routed, but the PW could also be identified by the PE+AI address ( stored by signaling in either case).

It is possible to route PW based on PE+AI, but is it necessary? What am I missing?

Thanks
Cheng-Yin

---

From: [email-masked]
Date: Mon, 16 Aug 2004 11:05:21 +0100

Thanks Adrian......a few additional remarks in-line.....

> On Behalf Of Adrian Farrel
> Sent: 13 August 2004 21:25
> To: [email-masked]; [email-masked]
> Hi,
> PMFJI (and slightly off topic).
> 
> Thanks, Neil, for your mail which does help to clarify several things.
> 
> I particularly support your note that GMPLS supports an 
> out-of-band control plane. This is fundamental to the design 
> and operation of GMPLS.
NH=> To be accurate here it is actually a consequence of the co-cs mode.
However, an OOB approach can also be applied to the co-ps mode....and
there are good reasons (like security, stability and resilence design)
why this ought to be seriously considered.
> 
> Can I just throw a couple of other points into the melting pot?
> 
> Since GMPLS was developed within the IETF there is an 
> assumption of IP addressing (or naming). This means that not 
> only is IP addressing used in the control plane, but IP 
> naming is used in the data plane. There is, of course, also 
> the facility for unnumbering.
NH=> Couple of points:
-	Both data-plane networks require addressing, but they exist in
disjoint spaces....the fact that the traffic data-plane is co-cs (here)
and the control (management?) data-plane is cl-ps ought to make this
rather obvious IMO.  
-	these addresses are completely disjoint from IP addresses used
in the public Internet (obviously so for the traffic data-plane as the
mode is completely different)....in fact, the control/management
data-plane addresses *must not* be reachable from the Internet as
security is a key reason/benefit from using an OOB approach.

> 
> It should be noted that the TEDB used to compute paths 
> through a GMPLS network is emphatically not the routing 
> database used to route packets (especially control plane
> packets) within the network.
NH=> Sorry if I sound pedantic, but there is not a *single* network
here, and there are at least 2 data-plane networks....and what you state
above is really just saying this a different way.

> This is true despite the fact 
> that the same routing protocol may be used to distribute the 
> information used to build the two databases.
NH=> Agreed.
> 
> Now, since there is a commonality of address formats between 
> control and data planes in GMPLS, some optimisations and 
> sharing of address spaces MAY be used, but these are not 
> compulsory.
NH=> Very much so.  I can recall BT stating 4 years ago or so when GMPLS
started-off that it would probably be very sensible not to use v4
structures for the traffic data-plane but start with v6 structures.  I
mean, why not learn from history given the traffic data-plane here is
co-cs and has nothing to do with the IP-based public Internet?  

Regards, Neil

> In the packet capable switching world (Note well 
> that GMPLS fully supports the PCS world) where control and 
> data packets traverse the same links, this optimization may 
> be used heavily (cf. MPLS).
> 
> However, (note again that GMPLS supports PCS and out-of-band 
> signalling), there is no reason to require the control and 
> data planes to share address spaces or even to share physical 
> resources.
> 
> Cheers,
> Adrian
> 
> ==
> 
> Folks, I have had a few private mails asking me to explain 
> something I noted below.....so just in case other folks are 
> having problems with my terse and/or poor explanation let me 
> spell it out:
> 
> "An address is an attribute of an access point in the 
> data-plane.  It has nothing to do with signalling (nor 
> routing for that matter)."
> 
> An address defines an access point of a network or subnetwork 
> (this is a G.805 func arch term, it's not an IP subnet).  It 
> is an attribute of the data-plane of some layer network (this 
> can be any mode, ie cl-ps, co-ps or co-cs).  Signalling and 
> routing are 2 additional functional components (there are 
> more than this, but this is all that is relevant here).
> 
> Depending on the mode the signalling and routing (and other 
> management) components can operate in-band or out-of-band wrt 
> to the data-plane that will be carrying the traffic.  In 
> fact, when we take these components OOB (for important 
> security/stability/resilience reasons) the mode of the 
> control/management data-plane network can be cl-ps whilst 
> that of the traffic data-plane network co-ps or co-cs (cf 
> GMPLS which is exactly like this for SDH or OTN say).  Note 
> also that the addressing of these 2 layer networks (ie 1 for 
> traffic and 1 for control/management) operate in quite 
> different spaces.
> 
> So, whilst routing and signalling protocols carry addressing 
> (of the traffic data-plane) they should be agnostic to the 
> nature of that addressing.  However, there is further key 
> point regarding the relationship between addressing and 
> topology (and thus the impact on routing advertisements)........
> 
> Addressing and topology are coupled.  The tighter the 
> coupling the more efficient can be the address aggregation 
> (ie summarisation in routing advertisements), and vice versa 
> (ethernet is an extreme example of the latter case.....and 
> here the address has completely degenerated into a 'name' 
> since it carries no topological information of 'where'). 
> However, the coupling must not be too tight or else changes 
> in topology impact addressing schemes...and that is not a 
> good idea either.
> 
> Hope that clarifies.
> 
> Regards, Neil
> 
> > > I disagree, this implies that the WG does not have the power to 
> > > change or make amendments to decisions that have already 
> been made. 
> > > If WG consensus was reached that the parameters currently defined 
> > > for identifying PWs were not suitable for MH-PWs, then 
> there is no 
> > > reason why alternative parameters couldn't be added (at least as 
> > > optional) in separate/revised drafts. Especially considering the 
> > > draft(s) in question are not even RFCs yet.
> > >
> > > > not take into consideration pw-switching nodes , but I 
> cannot see 
> > > > why we have to merge the auto provisioning of PW , and the 
> > > > signaling protocol ?
> > >
> > > signalling should be merged or described in the same document. I 
> > > think he is just pointing out that if auto-discovery was 
> to be based 
> > > on PW endpoint identifiers, because of the way PW end/mid 
> points (or 
> > > access points) are currently identified, autodiscovery would be 
> > > dependant on the signalling mechanism used. For example, PW end 
> > > points established using FEC 128 are identified by the PWid+PE IP
> happened 
> > before with MPLS.  An address is an attribute of an access point in 
> > the data-plane.  It has nothing to do with signalling (nor 
> routing for 
> > that matter).  And specifically signalling should not determine 
> > addressing.  What happens if we decide to change the 
> signalling?  What 
> > happens if we use the NMS/OSS to set-up the trail?
> >
> > Regards, Neil
> >
> > > If PWs were identified using the same identifier 
> regardless of the 
> > > signalling protocol used, then in turn auto-discovery 
> would not be 
> > > dependent on the signalling protocol used. A further improvement 
> > > would be to use a unique identifier that is only 
> pertinent to the PW 
> > > layer, e.g. an IPv6 address, which would be a significant 
> advantage 
> > > from a management and OAM perspective.
> > >
> > > Regards,
> > > Richard
> > >