Subject: RE: Truly Generalized VPLS (?)

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 23 Jul 2003 18:09:59 -0400

> Peter> Since  for a given  VPLS, a  U-PE needs  PWs to  a 
> limited  number of
> Peter> remote  U-PEs, I  thought it  would make  more sense  
> to  use RSVP-TE
> Peter> instead of LDP.  
> 
> I don't understand why you think so. 
> 
> Peter> However, the  problem I  have with the  splicing 
> approach is  that it
> Peter> looks very much like manual provisioning 
> 
> I guess I don't really understand  your alternative, and just 
> how it differs
> from the splicing approach.  Can you describe it in a bit 
> more detail? 
> 

Eric,

I must have done a very poor job explaining my thoughts. I am sorry about that. Let me try again.

GVPLS describes a solution where the end-to-end data path between two U-PEs for a given VPLS consists of up to three PWs that are spliced together. The N-PEs that tie the PWs together essentially do label switching: they take traffic received over one PW and forward it over another. The encapsulated data (including Control Word, etc) remains unchanged; only the value of the PW label changes.

The core of my proposal is to recognize that the end-to-end data path between two U-PEs is *one*  LSP that is routed through intermediate hops instead of three separate LSPs that are spliced together.

The N-PEs are the intermediate hops, and, as said before, they are functioning as MPLS switches that switch based on PW labels. The second part of my proposal is to generalize this concept: an N-PE in a Decoupled VPLS solution is nothing more than an MPLS switch that is designated to switch PW labels: a "PW-LSR".

How is a PW-LSR different than other MPLS switches in the Service Provider's network? It is not. It is just that the other switches in the MPLS network will not see the PW labels, because the PW-LSRs will use label stacking to tunnel the PWs through these other switches.

The only complication is that the PW infrastructure (i.e. the U-PEs and the intermediate hops, the N-PEs or PW-LSRs) is an overlay network on top the MPLS network at large. To discover the topology of that PW infrastructure, you  need to run a routing protocol within that overlay network. I hesitate to use the term "virtual routing", but that is probably the best way to look at it.

[This may sound complicated, but isn't this a general issue? MPLS offers the possibility to create multiple network layers, one on top of the other, through label stacking. To fully utilize that functionality, it should be possible to run independent routing protocols in every layer]

A U-PE discovers through auto-discovery the other U-PEs that belong to the same VPLS. It sets up PWs to these other U-PEs. In most cases, such a PW will be an LSP that goes through multiple intermediate hops.

I seems to me that RSVP-TE is the most appropriate protocol to set up these multi-hop LSPs. The alternatives:

1) A targeted LDP between the two U-PEs doesn't work because it won't tell the intermediate hops how to switch PW labels. 

2) Flooding LDP through the entire PW infrastructure might work, but is seems overkill because it will reach all other U-PEs instead of just the subset that belongs to the same VPLS. Besides, since each LSP needs to uniquely identify Source and Destination U-PEs , path merging is not allowed.

RSVP-TE is straightforward: through autodiscovery, source and destination of the LSP are known and through the routing protocol in the PW infrastructure, the intermediate hops know which path to follow.

-----------------------------------------------

Compared to the gvpls draft, I think I am proposing two things that are different:

- Introduction of a routing protocol to discover the topology of the PW infrastructure. However, I think that something similar is required in the gvpls approach. E.g. in the current draft it is not clear to me how a SRC-N-PE knows which DST-N-PE to connect to to reach a DST-U-PE. If you don't want to rely on manual provisioning by the service provider, you need some form of topology discovery.

- Use of RSVP-TE instead of Targeted LDP for PW set up. I think that the decision to consider a PW as an LSP between two peers without intermediate hops is a severe limitation. The splicing approach in the gvpls draft is an attempt to salvage the situation, but it is a non-standard fix to a problem for which well-known solutions already exist.

Peter

---

From: Wei Luo <[email-masked]>
Date: Fri, 25 Jul 2003 18:16:24 -0700

Peter,

Maybe you allow me to fill in some details so I can understand your proposal
better.  Before doing that, I have to point out there could be any number of
intermediate hops (MPLS LSRs) between the U-PE and N-PE, and between the N-PE
and N-PE in the distributed model.  In other words, these U-PE and N-PE are not
necessarily directly connected to each other.

Scenario 1:

If you want to use RSVP-TE for the end-to-end PW signaling and treat the N-PE
just
like any other LSRs, all LSRs between the U-PEs (inclusive) must be involved in
PW signaling.  In other words, the PWs are not transparent to the core network,
and the core LSRs must have stateful information on every PW traversing them. 
Each U-PE might only have to manage a moderate number of PWs, but the core LSRs
have to manage a very large number of PW LSPs in addition to all the IPv4 LSPs,
which require large number of memory and process cycles.  This reminds me about
the legacy L2VPN based on Frame Relay and ATM network, and the scalability would
be a real concern for the core LSRs.

Scenario 2:

Use RSVP-TE between U-PE and N-PE, and between N-PE and N-PE only.  I am not
sure if there is such a thing called directed RSVP (like directed LDP) that runs
between the PEs and is transparent to intermediate LSRs.  Even if there is, I am
not so sure how it would be better or different from using directed LDP.

Which scenario do you have in mind?

---Wei

---

From: Eric Rosen <[email-masked]>
Date: Mon, 28 Jul 2003 13:22:18 -0400

Peter> How is  a PW-LSR  different than other  MPLS switches in  the Service
Peter> Provider's network? It is not. It  is just that the other switches in
Peter> the MPLS network will not see the PW labels, because the PW-LSRs will
Peter> use label stacking to tunnel the PWs through these other switches. 

The two PW endpoints have to agree  on such things as the use of the control
word, the  use of  signaling, etc.  They  may also  need to send  each other
status info.   These things are  done using the  control plane.  If  the two
endpoints  are  not  peers  in   a  control  plane  relationship,  then  the
intermediate  nodes must,  be forwarding  control plane  signals from  one pw
endpoint  to  another, which  means  that  the  intermediate nodes  maintain
per-PW control state.

When a PW packet is received by a  PW endpoint, the PW label must be a label
which was assigned by that endpoint.   If the two endpoints are not peers in
a  control plane  relationship, the  PW  labels need  to be  swapped by  the
intermediate nodes, which means  that the intermediate nodes maintain per-PW
labels.  

Given that these intermediate nodes  must maintain per-PW state, I don't see
how  your  proposal is  any  different  than  the splicing  proposals.   The
operations performed by the intermediate nodes seem to be the same. 

I also don't see why RSVP-TE is any better than LDP here. 

Peter> The only complication  is that the PW infrastructure  (i.e. the U-PEs
Peter> and  the intermediate  hops,  the  N-PEs or  PW-LSRs)  is an  overlay
Peter> network on top the MPLS network at large. To discover the topology of
Peter> that PW  infrastructure, you  need to run  a routing  protocol within
Peter> that overlay network.  

In  theory  you could  pass  around pw  endpoint  identifiers  in a  routing
algorithm, with  the splice points  being the possible next  hops.  However,
you'd need  to invent  a summarizable addressing  scheme for  the endpoints,
make sure the routing is loop-free, etc.  Frankly, I haven't seen the demand
for this.