Subject: Truly Generalized VPLS (?)

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Tue, 22 Jul 2003 13:12:10 -0400

In the WG meeting in Vienna I made a comment on draft-radoaca-ppvpn-gvpls-02, which I was asked to bring up on the mailing list.

The issue is the following:

In any "decoupled" solution there is a hierarchy of devices: a U-PE that performs a bridging function and an N-PE that forwards traffic based on identifiers other than MAC addresses. Between N-PEs, these identifiers are PW labels. In the access network, PW labels can also be used, although other options (Q-in-Q, MAC-in-MAC) could potentially play a role.

Since the forwarding function in the N-PEs is essentially a form of label switching, the question is: why don't we treat the connection between two U-PEs as a regular Label Switched Path that goes through multiple intermediate hops and is set up and managed with regular MPLS protocols and tools? In essence, PWs are LSPs, U-PEs function as "PW-LERs" and N-PEs function as "PW-LSRs". PW-LERs and PW-LSRs form a logical MPLS infrastructure that is overlayed on top of the existing Packet Switched Network. Adjacencies between PW-LxRs are created through MPLS, IP and/or GRE tunnels. RSVP-TE is used to set up PWs between PW-LERs (i.e. U-PEs). 

How does this alternative view differ from draft-radoaca-ppvpn-gvpls?

1) Draft-radoaca-ppvpn-gvpls prescribes a fixed topology: U-PEs are connected to N-PEs and there is a full mesh of tunnels between N-PEs. Hence, a PW goes at maximum through two intermediate hops.

In the more general approach, any topology is allowed. E.g. there is no need for a full mesh of tunnels between N-PEs. In case of a partial mesh, PWs could be routed through multiple PW-LSRs. Similarly, additional aggregation points (e.g. Border Routers between ASs) could be deployed.

2)In draft-radoaca-ppvpn-gvpls there is a notion that N-PEs are VPLS-specific network elements. The current draft actually specifies an approach in which N-PEs can forward traffic purely based on PW labels, but the draft still promotes an optimization where the SRC-ID is carried in the Control Word so as to decrease the number of PW labels required between N-PEs. In that case, an N-PE would perform VPLS-specific functions when forwarding packets in the data plane.

In the more general approach, intermediate nodes are LSRs. VPLS-specific functions occur only at the edge. Hence, Service Providers can rely to a larger extent on general-purpose MPLS switches and don't need to distribute VPLS functionality throughout their networks.

3) In draft-radoaca-ppvpn-gvpls, signaling is completely PW-centric: PWs are set up using PW-specific signaling and then spliced together.

In the more general approach, there is of course a need for VPLS-specific TLVs in the RSVP messages, but these are only relevant to the U-PEs. The PW-LSRs do not need to implement VPLS-specific signaling functions.

In the meeting in Vienna, Vasile and Ali argued that the splicing approach described in draft-radoaca-ppvpn-gvpls was necessary because of control-plane scaleability. I may be missing something, but I don't see why that is the case. 

a) In terms of control message load required for PW set up, I don't see a significant difference between the splicing approach and the more general approach.

b) In terms of control message load required for OAM and protection switching, I am not sure, because draft-radoaca-ppvpn-gvpls is not very specific about the impact is of splicing. This is another reason why I believe the more general approach is preferable: when a PW between U-PEs is in effect a regular LSP, mechanisms like vccv and the various forms of protection switching can be applied straightforwardly. With splicing that may also be the case, but one needs to think it through.

Draft-radoaca-ppvpn-gvpls provides a solution that works across multiple access technologies. Personally, I believe that Q-in-Q doesn't work well in a decoupled network and I don't think MAC-in-MAC will ever be standardized. Still, it is important to note that the general RSVP-based approach that I advocate in this email could also be made to work across access networks based on Q-in-Q or MAC-in-MAC. 

In summary: I believe that draft-radoaca-ppvpn-gvpls is too narrowly focused on   extending current PW and VPLS drafts. Instead, by accepting that PWs are LSPs that can be routed through multiple intermediate nodes, I believe one can define scaleable VPLS solutions that are superior to GVPLS.

Peter

---

From: Eric Rosen <[email-masked]>
Date: Tue, 22 Jul 2003 13:51:08 -0400

The point  of the decoupled  procedures is to  reduce the number  of control
connections (e.g., LDP connections) which must be maintained by any one U-PE
device.  By using  decoupled proceudres, a (spliced) PW  can run between two
U-PEs without there being an LDP  connection between the U-PEs.  This is the
scalability  consideration.   I don't  see  how  you  get that  without  the
splicing methodology.  

Peter> Since the forwarding  function in the N-PEs is  essentially a form of
Peter> label switching, the  question is: why don't we  treat the connection
Peter> between two U-PEs as a  regular Label Switched Path that goes through
Peter> multiple intermediate  hops and  is set up  and managed  with regular
Peter> MPLS protocols and tools?

Because that requires an LDP connection between the two U-PEs. 

Peter> Draft-radoaca-ppvpn-gvpls  prescribes a  fixed  topology:  U-PEs  are
Peter> connected  to N-PEs  and  there is  a  full mesh  of tunnels  between
Peter> N-PEs. Hence, a PW goes at maximum through two intermediate hops.

Not necessarily.  See,  e.g., the related material in  section 5.5 of draft-
rosen-ppvpn-l2-signaling.   There  is  no  fundamental  restriction  on  the
topology. 

One may ask of  course whether it is worthwhile to reduce  the number of LDP
connections.  After all, the signaling load is, to first order, proportional
to the  number of PWs supported, not  to the number of  LDP connections, and
the splicing  approach does not  reduce the number  of PWs.  In  most common
cases I think that a reduction in  the number of LDP connections is not that
big a  deal.  However, there are  a couple of  cases where it might  be very
useful: 

- A "low end" U-PE with limits on its TCP support. 

- When PWs  go between SPs, the control connections need  to be secured, and
  this requires management; having fewer means less management. 

With regard to the extra "control word" and to the MAC-in-MAC stuff, well, I
agree that those particular pieces are not likely to go anywhere.