Subject: 答复: RE: [PWE3] Scaling hierarchical LDP/PWstitching

From: [email-masked]
Date: Mon, 26 Jul 2004 14:43:12 +0800

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.

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.

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

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3