Subject: PW/Multi-layer LSP switching

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

Peter,

Thanks for the clarification regarding your thoughts on LSP switching/routing/policies, and I agree with your assertion that this is not a PW specific problem. The problem applies to any MPLS LSP (regardless of its label stack depth) for which label switching (or swapping) is performed. Whenever label switching is performed there must be at least one LSR between the source and destination LER, and therefore a route at the given label stack depth must be calculated from source LER to destination LER. 

Another way of describing the problem would be to say that routing is required for a client layer LSP if an end-to-end server layer LSP does not exist between the source and destination LERs at the client layer. If multiple server layer LSPs (or server layer partitions) are required to establish connectivity between source and destination LERs at the client layer, then forwarding (or selection as to which outbound server layer LSP to use) at nodes where server layer LSPs are terminated/sourced must be based on the client layer label. The difference being that if an end-to-end server layer LSP exists between the source and destination LERs at the client layer then this is effectively a one hop point-to-point link and therefore no routing is required. On the other hand, if multiple server layer LSPs are required to provide connectivity between the source and destination LERs at the client layer then these are effectively separate point-to-point links between multiple hops, and therefore a route between the source and destination LERs across alternative multiple hops must be calculated/selected.

Obviously this problem is not MPLS specific, it is a problem common to all cases where an end-to-end server layer partition (which is seen as a point-to-point link by the client layer) does not exist between the source and destination at the client layer. For instance, if a leased line exists between a source router and a destination router then there is no need for routing at the client (IP) layer as the server layer (leased line in this case but could equally be a LSP) provides a point-to-point link between ingress and egress. If on the other hand to provide connectivity between the source and destination routers at the client layer requires multiple leased lines between intermediate routers, then routing is required at the client (IP) layer to discover/calculate/select a route across the alternative intermediate routers between source and destination.

Regards,
Richard

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: 03 August 2004 18:11
> To: Spencer,R,Richard,XGH5 R; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, August 03, 2004 11:53 AM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked]
> > Subject: RE: [PWE3] Scaling hierarchical LDP/PW stitching
> > 
> > 
> > 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.
> 
> 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
> > 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: [email-masked]
Date: Wed, 4 Aug 2004 14:12:13 +0100

Thanks Richard....that is a pretty good summary of client/server
functional arch relationships as per G.805 wrt to what this means for
routing.  Couple of further points:
-	the essence of client layer topology creation is that:  A client
layer link connection is formed by a server layer trail.  This is a
recursive bahviour to the duct.  This is aka TE in IETF.  So this is how
an MPLS *server layer network* provides this function for an IP *client
layer network*.
-	if there is not a 1:1 relationship between a client and server
then we need muxing.  All such cases (ie 1 hop or N hops) need this *per
hop*.  Muxing is a property of the link connection and is considered to
belong to the server layer as it will vary with server layer
technology/mode.  Muxing is part of the client/server adaptation
function.  Further, if the server layer is co-cs we will also require
rate-adaptation and delineation processes within the adaptation
function.
-	below this there is the server layer access point....this must
have an address that belongs to the server layer (it has nothing to do
with the access point addressing in the client layer network even if it
they both have the same format).  
-	below the server layer access point there is the server layer
trail termination point....this is a very important point since this is
where the integrity of the server layer network is ensured.  So it is
here that we have OAM insertion/extraction, defects detected/handled and
performance/availability SLAs measured.

And as Richard points out, if the client entity is always just 1 hop
thenthere can be no path construction in the client layer network
itself....so a routing capability here is a non-issue.  However, if the
client layer entity can be multi-hop then this all changes and we now
need some form of routing capability in the client.  Also note that in
the *general* client/server case, the client and server layer networks
can be owned by different parties.  So full functional independence,
which includes client layer transparency (ie no compression), must
always be the base default behaviour here.

Regards, Neil
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 04 August 2004 10:42
> Cc: [email-masked]; [email-masked]
> Subject: [PWE3] PW/Multi-layer LSP switching
> 
> 
> Peter,
> 
> Thanks for the clarification regarding your thoughts on LSP 
> switching/routing/policies, and I agree with your assertion 
> that this is not a PW specific problem. The problem applies 
> to any MPLS LSP (regardless of its label stack depth) for 
> which label switching (or swapping) is performed. Whenever 
> label switching is performed there must be at least one LSR 
> between the source and destination LER, and therefore a route 
> at the given label stack depth must be calculated from source 
> LER to destination LER. 
> 
> Another way of describing the problem would be to say that 
> routing is required for a client layer LSP if an end-to-end 
> server layer LSP does not exist between the source and 
> destination LERs at the client layer. If multiple server 
> layer LSPs (or server layer partitions) are required to 
> establish connectivity between source and destination LERs at 
> the client layer, then forwarding (or selection as to which 
> outbound server layer LSP to use) at nodes where server layer 
> LSPs are terminated/sourced must be based on the client layer 
> label. The difference being that if an end-to-end server 
> layer LSP exists between the source and destination LERs at 
> the client layer then this is effectively a one hop 
> point-to-point link and therefore no routing is required. On 
> the other hand, if multiple server layer LSPs are required to 
> provide connectivity between the source and destination LERs 
> at the client layer then these are effectively separate 
> point-to-point links between multiple hops, and therefore a 
> route between the source and destination LERs across 
> alternative multiple hops must be calculated/selected.
> 
> Obviously this problem is not MPLS specific, it is a problem 
> common to all cases where an end-to-end server layer 
> partition (which is seen as a point-to-point link by the 
> client layer) does not exist between the source and 
> destination at the client layer. For instance, if a leased 
> line exists between a source router and a destination router 
> then there is no need for routing at the client (IP) layer as 
> the server layer (leased line in this case but could equally 
> be a LSP) provides a point-to-point link between ingress and 
> egress. If on the other hand to provide connectivity between 
> the source and destination routers at the client layer 
> requires multiple leased lines between intermediate routers, 
> then routing is required at the client (IP) layer to 
> discover/calculate/select a route across the alternative 
> intermediate routers between source and destination.
> 
> Regards,
> Richard
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>