Subject: RE: Truly Generalized VPLS (?)

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 22 Jul 2003 14:21:32 -0400

Eric,

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

Another aspect of scalability of the decoupled procedures is
to keep the MAC-address learning, and l2 forwarding decisions relevant 
only to the "low-end/low-cost" U-PE (allowing N-PE to focus only
on common pw/vpn control functions and not to keep MAC addresses, 
etc).

Hamid.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Sun, 27 Jul 2003 22:04:32 -0400

Wei Luo,

Thanks for your comments. I had scenario 2 in mind. Further comments in-line.

Peter

> -----Original Message-----
> From: Wei Luo [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 9:16 PM
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: Truly Generalized VPLS (?)
> 
> 
> 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.

I agree, but by establishing transport LSPs between them, they become peers and the intermediate switches will only see the outer label and not the inner PW-LSP, i.e. scenario 2.

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

Yes, that would be a bit much. Therefore, you use label stacking, i.e. scenario 2.

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

What exactly is the problem with Frame and ATM scaleability? In ATM you have a two-level hierarchy (VPs and VCs) and as far as I know, that works perfectly fine. Service providers have been able to build very large networks serving tens of thousands of customers. 

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

If you want to use targeted LDP, you need three sessions: between SRC-U-PE and SRC-N-PE; between SRC-N-PE and DST-N-PE; and between DST-N-PE and DST-U-PE. As a consequence you set up three independent PWs. You can consider these as one logical PW, but that would mean that you have to specify all kinds of additional procedures. E.g.

1) TTL
Does each element in the path set the TTL to 2, or does the SRC-N-PE set it to 4 and the subsequent nodes decrease the value?

2) OAM
If the SRC-U-PE sends a VCCV Ping message, is it terminated by SRC-N-PE? And is the PW between SRC-N-PE and DST-N-PE tested independently? Or is the VCCV Ping sent by SRC-U-PE, forwarded by SRC-N-PE to DST-N-PE, which in turn sends it to DST-U-PE? And if one of the reply messages on any of these segments does not arrive, how is that reported to SRC-U-PE? By not sending a response, or by sending an error message?

3) Protection switching
Suppose SRC-U-PE is dual-homed but has set up ony a single spliced PW to DST-U-PE. Now suppose that the PW segment between SRC-N-PE and DST-N-PE goes down and can not be restored. How does SRC-U-PE find out that it needs to set up another PW tthrogh the other N-PE it is connected to? Does N-PE send an error message that reports a fault on a segment of the spliced PW?

All these issues can be solved, but they need to be specified unambiguously. On the other hand, if you use RSVP-TE and consider the end-to-end PW between SRC-U-PE and DST-U-PE as a single LSP, the solution to these issues follows immediately from existing standards. Hence my question: why are we defining a non-standard way to do something for which standards already exist?

> 
> Which scenario do you have in mind?

2

> 
> ---Wei
> 
> 
> "Busschbach, Peter B (Peter)" wrote:
> > 
> > > 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
>