Subject: RE: ??: RE: Scaling hierarchical LDP/PWstitching

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 26 Jul 2004 14:35:03 -0400

Hi Du Ke,

I have included a few comments below.

Peter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 26, 2004 2:43 AM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]'
> Subject: ??: RE: [PWE3] Scaling hierarchical LDP/PWstitching
> 
> 
> 
> I agree with Richard with the term "PW layer network".
> I think, which Richard claimed is that, PW layer network is a overlay
> network over IP network, and it has its own routing information and
> topology.

Creating an overlay network with its own routing and addressing is one solution. It would turn the PW layer into an IP VPN. However, I don't think that such an approach is necessary.

draft-ietf-mpls-lsp-hierarchy-08.txt describes how a hierarchy of LSPs can be created. It assumes that lower-layer LSPs (in PW terms: the Transport LSP) use the same instance of a control plane as the higher-layer LSPs (the PWs). E.g. assume that in the scenario below all nodes use the same routing protocol. Further, assume that there is a Transport LSP between SPE1 and SPE2. Based on its link state data base, SPE1 would be aware that it could reach SPE2 via P1 and P2, or directly via the Transport LSP. The decision which path to use would be based on traffic engineering metrics.

> 
> To illustrate why this is an issue, please consider the example below:
> UPE1----SPE1----P1----P2----SPE2----UPE2
> This is a IP layer topology of network. In this network, UPE1 
> & UPE2 are
> ultimate PEs where the customer-facing ACs are bound to a PW 
> forwarder.
> SPE1 & SPE2 are PW Switching Points where two PW segments are bound
> together. and P1 & P2 are common LSR, which have no sense of the
> establishing/existing of PWs, and participate only in the PSN tunnel
> between SPE1 and SPE2. So P1 & P2 routers do not belong to 
> the PW layer and
> therefore they should be transparent to the PW layer network.
> The topology of overlay network(PW layer network) is:
> UPE1-----------------SPE1-----------------SPE2-----------------UPE2
>      (PSN tunnel -1)      (PSN tunnel -2)      (PSN tunnel -3)
> 
> Richard suggests that, the routing information base of the 
> overlay network,
> i,e. a separate PW layer routing table (PWRIB) with routing 
> information
> that is only pertinent to the PW layer network, should be maintained.

As I said above, I don't think it is necessary to maintain routing information that is only pertinent to the PW Layer network. There is nothing special about PW Switching Points. They just do (PW) label switching. SPE1 and SPE2 are not different from P1 and P2. Or, in other words, P1 and P2 could serve as PW Switching Points as well. Therefore, from an architectural perspective, a five-segment MH-PW (UPE1-SPE1-P1-P2-SPE2-UPE2) is equally valid as a three-segment MH-PW (UPE1-SPE1-SPE2-UPE2). The use of a Transport LSP to tunnel traffic between SPE1 and SPE2 is optional and at the operator's discretion.

> 
> This routing information base (PWRIB) are important to every 
> single sided
> signaling protocol for MH-PW setup.
> 
> As RSVP-TE for MH-PW setup is considered(as Peter suggested), 
> UPE1 should
> know the path from UPE1 to UPE2, which can be get from PWRIB. 
> (Of cause,
> whether we should use RSVP-TE as protocol to setup and 
> maintain PE is an
> other question, I'll discuss it in an other mail.)
> 
> In fact, PWRIB can be maintained in several style.
> Such as, it can be maintained in a centralized 
> autodiscovery/radius server
> or OSS, When UPE1 launches to establish the PW to UPE2, it send a
> "register" message for the FEC to the discovery server and receive a
> explicit route information, then it can send path message to 
> UPE2 or PW
> Label mapping to SPE1.
> Or, PWRIB can be maitained by UPEs & SPEs with a distributed 
> style, using
> an IGP extension(s) (or a separate mechanism) or a separate 
> IGP instance.
> Then UPE1 knows to send mapping, whose target PE is UPE2, to 
> SPE1. and SPE1
> knows to forward the mapping to SPE2, and so on.
> Or, PWRIB can be maintained in the brain of operator

I don't think that is a scaleable solution :-)

>, whilst, the UPEs &
> SPEs are manually configurated.
> 
> 
> 
> 
> Regard,
> Du Ke
> >...............................................
> >Add:   No.68 Zijinghua Rd,Yuhuatai District,
> >        Nanjing. P.R.China.
> >Zip:   210012
> >Tel:   0086-25-52871809
> >Fax:   0086-25-52871000
> >Mail:  [email-masked]
> >.............................................
> 
> 
> 
>                                                               
>                                                               
>            
>                       "Busschbach,                            
>                                                               
>            
>                       Peter B (Peter)"         收件人：  
> "[email-masked]'" <[email-masked]>, 
> [email-masked],           
>                       <busschbach@lucen         
> [email-masked]                                                
>                          
>                       t.com>                   抄送：            
>                                                                       
>                       发件人：                 主题：    RE: [PWE3] 
> Scaling hierarchical LDP/PW stitching                              
>                       pwe3-bounces@ietf                       
>                                                               
>            
>                       .org                                    
>                                                               
>            
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
>                       2004-07-26 03:53                        
>                                                               
>            
>                                                               
>                                                               
>            
>                                                               
>                                                               
>            
> 
> 
> 
> 
> Richard,
> 
> I am glad you took the initiative to discuss the 
> architectural aspects of
> PW stitching. With several recent drafts that address this 
> issue, it is the
> right time to look at the fundamentals.
> 
> I think we need to look at this problem from a slightly different
> perspective. One of the fundamental misconceptions is that there is
> anything special about nodes the form the intermediate hops 
> in a multi-hop
> PW. Stitching PWs is nothing more than PW label switching and 
> every LSR is
> capable of doing that. 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?
> 
> It is important to realize than any LSP could be considered a 
> MH-PW. In one
> of your emails you show the following scenario:
> 
> UPE1----SPE1----P1----P2----SPE2----UPE2
> 
> Suppose an MH-PW is established that consists of five 
> segments: UPE1-SPE1,
> SPE1 - P1, P1 - P2, etc. Since on each link the PW segment is 
> established
> between adjacent nodes, there is no need to add an additional 
> label on top
> of the PW label (see e.g. section 2 of the control draft). 
> Hence, the MH-PW
> is just a regular LSP between UPE1 and UPE2. From a scaleability
> perspective it may make sense to tunnel all PWs that pass 
> through SPE1 and
> SPE2 through a Transport LSP that connects those two nodes, 
> but  whether to
> do that or not should be based on operator policies.
> 
> The problem with this argument is that it may be true from a 
> data plane
> perspective, but that it doesn't work from a control plane 
> perspective.
> After all, in the data plane, a MH-capable router does 
> nothing more than PW
> label switching, but in the control plane it has to tie together two
> targeted LSP sessions, or does it?
> 
> IMO, the appropriate conclusion is that Targeted LDP is really not the
> right tool to set up MH PWs. Draft-raggarwa-rsvpte-pw-00.txt 
> describes how
> RSVP-TE can be used to set up MH-PWs. It is totally 
> straightforward. The
> only thing different from regular RSVP is a TLV that is used by the PW
> end-points to identify the PW. (The current draft only shows 
> PW-id, but a
> subsequent draft will include GID as well.)
> 
> I realize that the introduction of RSVP-TE for PW set up is a 
> departure
> from earlier decisions to use LDP. However, if you compare it with the
> alternatives, I think it is clear that this the way to go.
> 
> draft-yudong-pwe3-control-protocol-ext-00.txt recognizes that 
> intermediate
> hops need the LSP ids of the two PW end points. It also 
> recognizes that in
> some cases there may be a need to carry the address of an 
> intermediate hop.
> This contribution essentially recreates CR-LDP, but with a new and
> incomplete form of Explicit Route Object. CR-LDP would obviously be
> equivalent to using RSVP-TE for MH-PW setup, but since the 
> decision has
> been made to abondon CR-LDP, RSVP-TE is the better choice at 
> this point in
> time.
> 
> draft-martini-pwe3-pw-switching-00.txt remains closer to the 
> control draft.
> It sticks with targeted LDP. The problem is, as you wrote in 
> an earlier
> email, that this mechanism seems to rely on manual provisioning by the
> operator. Another problem, IMO, is that it leads to proliferation of
> PW-specific identifiers (AGI and AII) throughput the network. 
> Therefore, it
> turns the PW switching Points in specialized nodes that need 
> to deal with
> non-routable identifiers. Architecturally, that is not the way to go.
> 
> Just to be clear: draft-martini-pwe3-pw-switching-00.txt contains
> information that is useful and that should become part of PW switching
> standards. E.g. if a provider would want to mix and match 
> L2TP-based PWs
> with MPLS-based PWs, there is a need for the procedures defined in the
> draft. However, I believe that there is a need for only a few of such
> L2TP-MPLS interworking nodes. We should not accept a 
> definition MH-PWs that
> assumes that this is functionality that is required in each 
> and every PW
> Switching point. And we should not accept a signaling 
> protocol for MH-PW
> setup that uses non-routable identifiers.
> 
> Peter
> 
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, July 21, 2004 3:19 AM
> > To: [email-masked]; [email-masked]
> > Subject: [PWE3] Scaling hierarchical LDP/PW stitching
> >
> >
> > To address LDP scaling (and VPLS packet replication) a
> > hierarchical LDP model is proposed (in
> > draft-ietf-l2vpn-signaling-01.txt) where hubs (PErs routers)
> > are connected via a full mesh of LDP sessions, but spokes
> > (PEr/MTUs routers) only establish LDP sessions with the
> > hub(s) that they connect to. This reduces the number of LDP
> > sessions required and also reduces the number of packet
> > replications that hub (PErs) routers must perform.
> >
> > However, as yet I don't believe there are any drafts that
> > discuss exactly how the hub and spoke PWs are signalled and
> > stitched/bound together. Likewise for VPWS PW paths that are
> > established by stitching multiple PWs together between
> > endpoints. I believe this is an important area as one can
> > imagine large service providers having hundreds of PErs
> > routers connected via a full mesh of LDP sessions with tens
> > of thousands of MTUs/PEr devices hanging off them. To support
> > hundreds of thousands of PWs between tens of thousands of
> > MTUs/PEr routers obviously requires a highly scalable
> > provisioning solution.
> >
> > The example below shows an example of a hierarchical
> > VPLS/VPWS network with 4 PErs devices each connected to a
> > single MTUs device:
> >
> > MTUs4----PErs4--PErs3-----MTUs3
> >            |  \ /  |
> >            |   X   |
> >            |  / \  |
> > MTUs1----PErs1--PErs2-----MTUs2
> >
> > I assume that to provision a stitched VPWS PW path from MTUs1
> > to MTUs2, the individual PWs that form the path need to be
> > established individually and then stitched together. Although
> > the individual PWs can be established using single sided
> > provisioning, the signalling for each PW must be initiated at
> > one side for each PW either through manual configuration or
> > via OSS. OSS (or some manual method) must also be used to
> > keep track of and bind the different PWs together. To do this
> > OSS needs to learn or be configured with information about
> > which MTUs devices sit behind which PErs devices.
> >
> > For VPLS, the point-to-multipoint PWs between the hubs (PErs
> > devices) can be provisioned using singled sided provisioning,
> > but the spoke PWs need to be signalled and associated with
> > the relevant VPLS separately. Again, the signalling needs to
> > be initiated at one side and the spokes need to be associated
> > with the correct VPLS via manual configuration or via OSS.
> >
> > The drawback with the above approach is that intermediate
> > routers along the stitched PW path (i.e. PErs routers) must
> > each be configured via OSS or via a manual method, and OSS
> > must be also be used to bind and keep track of the individual
> > PWs. The ideal solution would be to use a dynamic protocol(s)
> > to establish the end-to-end PW path using single sided
> > provisioning initiated from one end of the path.
> >
> > However, to establish and end-to-end path across multiple
> > hops requires a path to be calculated and selected (if
> > multiple paths exist) before the path can be signalled.
> > Stitching PWs together to from a path between two endpoints
> > is effectively creating a new layer network. Although
> > targeted LDP has been proposed as the signalling mechanism to
> > signal individual PWs, there is no routing at the PW layer to
> > calculate/select an end-to-end path.
> >
> > Route/path calculation/selection is fairly simple for the
> > hierarchical LDP model using a centralised OSS approach, each
> > MTUs is connected to one PErs (except where dual homing is
> > used), and each PErs has a targeted LDP session with each
> > other. Therefore, if the OSS knows that MTUsX sits behind
> > PErsX, and MTUsY sits behind PErsY, then to establish a PW
> > path between MTUsX and MTUsY requires stitching/signalling of
> > 3 PWs, i.e. MTUsX<->PErsX, PErsX<->PErsY, and PErsY<->MTUsY.
> > Obtaining information about which MTUs devices sit behind
> > which PErs devices is straightforward in the OSS approach
> > because the information is gathered, maintained, and
> > processed using a centralised mechanism. Using a distributed
> > approach however using dynamic protocols requires
> > reachability information to be distributed, at least between
> > the PErs devices, i.e. PErs devices need to advertise to each
> > other which MTUs devices they are connected to. As yet a
> > mechanism has not been defined to distribute this
> > information, or to select primary/secondary paths where MTUs
> > devices are multihomed.
> >
> > Du Ke has submitted a draft recently
> > (<http://www.ietf.org/internet-drafts/draft-yudong-pwe3-contro
> l-protocol-ext-00.txt>) to address LDP scaling that proposes 
> a solution
> with two different modes:
> 
> i) A mode called 'simple trunk' that reflects LDP messages to clients
> similar to the way in which BGP route reflectors distribute routes to
> clients. This potentially could be used to reduce the number of LDP
> sessions in an existing full mesh.
> 
> ii) A mode called 'next hop self' that describes a solution for PW
> stitching but does not scale as it relies on broadcasting 
> labels to every
> PErs in the full mesh for every VPWS/VPLS (the route of the 
> problem being
> that there is no routing functionality at the 'PW layer' 
> which the draft
> does not address).
> 
> I would like to establish consensus as to whether a) a 
> dynamic protocol
> based end-to-end single sided provisioning solution is required to aid
> scaling for stitched PWs, or if b) PW stitching is best 
> handled via OSS.
> 
> Any comments/thoughts are welcomed.
> 
> Thanks,
> Richard
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> 
>

---

From: John Drake <[email-masked]>
Date: Mon, 26 Jul 2004 13:13:05 -0700

Peter,

I have always wondered why the PWE3 group didn't consider LSP hierarchy.  I
definitely agree that you don't want to invent a PWE3 specific control
plane.

Thanks,

John

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: Monday, July 26, 2004 11:35 AM
> To: [email-masked]'
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]'
> Subject: RE: ??: RE: [PWE3] Scaling hierarchical LDP/PWstitching
> 
> Hi Du Ke,
> 
> Creating an overlay network with its own routing and addressing is one
> solution. It would turn the PW layer into an IP VPN. However, I don't
> think that such an approach is necessary.
> 
> draft-ietf-mpls-lsp-hierarchy-08.txt describes how a hierarchy of LSPs can
> be created. It assumes that lower-layer LSPs (in PW terms: the Transport
> LSP) use the same instance of a control plane as the higher-layer LSPs
> (the PWs). E.g. assume that in the scenario below all nodes use the same
> routing protocol. Further, assume that there is a Transport LSP between
> SPE1 and SPE2. Based on its link state data base, SPE1 would be aware that
> it could reach SPE2 via P1 and P2, or directly via the Transport LSP. The
> decision which path to use would be based on traffic engineering metrics.
> 
> 
> >
> As I said above, I don't think it is necessary to maintain routing
> information that is only pertinent to the PW Layer network. There is
> nothing special about PW Switching Points. They just do (PW) label
> switching. SPE1 and SPE2 are not different from P1 and P2. Or, in other
> words, P1 and P2 could serve as PW Switching Points as well. Therefore,
> from an architectural perspective, a five-segment MH-PW (UPE1-SPE1-P1-P2-
> SPE2-UPE2) is equally valid as a three-segment MH-PW (UPE1-SPE1-SPE2-
> UPE2). The use of a Transport LSP to tunnel traffic between SPE1 and SPE2
> is optional and at the operator's discretion.
> 
> 
> >