Subject: Re: Scaling hierarchical LDP/PW stitching

From: Mustapha Aissaoui <[email-masked]>
Date: Mon, 09 Aug 2004 10:31:45 -0400

Peter,
see a couple of clarifications below. I agree that we need to work
on the
requirements and scope of MH-PWs.

Regards,
Mustapha.
------------
"Busschbach, Peter B (Peter)" wrote:
> 
> Mustapha,
> 
> I am surprised by your insistence that PWs should not be routable.

MA> It seems to me we are debating terminology here. By PWs are
routable, I mean there is a separate (from the PSN) routing instance
which advertises PW reachability and which is used by the stitching
nodes to forward the PW packets. This would be something like what
option (b) you describe below which will be based on routable PW
label and/or TAII.
 
> 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.

MA> You are right, I agree with you on (a) because we want to stick
to the current PWE3 architecture as much as possible. The point
where I disagree is you want to make any LSR a stitching node. I
think what Richard and I have comme to the conclusion that in this
case you would need a solution like in (b).

> You may be right, but let's wait for the requirements ...
> 
> Peter
> 
> > -----Original Message-----
> > From: Mustapha Aissaoui [mailto:[email-masked]]
> > Sent: Wednesday, August 04, 2004 9:41 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [PWE3] Scaling hierarchical LDP/PW stitching
> >
> >
> > Richard,
> > see below.
> >
> > Regards,
> > Mustapha.
> > -----------
> > [email-masked] wrote:
> > >
> > > 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.
> >
> > MA> Add to that OAM on the PW segment.
> >
> > > 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.
> >
> > 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.
> >
> > > 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.
> >
> > 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.
> >
> > > > 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).
> >
> > 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.
> >
> > > 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.
> >
> > 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.
> >
> > > 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.
> >
> > 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:39:35 -0600

Peter,

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

Luca

Busschbach, Peter B (Peter) wrote:

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