Subject: RE: Truly Generalized VPLS (!)

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 4 Aug 2003 20:24:27 -0400

> Given your sample topology: 
> 
>       U-SRC-PE---N-SRC-PE--------N-DST-PE---U-DST-PE
> 
Eric> In LDP, when you receive a
Eric> particular  TLV on one  session, you  forward the corresponding TLV  on the
Eric> other.  That doesn't seem like much  of an issue, though the proper behavior
Eric> would need to be specified.  (Note  that in an "ordinary" MPLS LSP, there is
Eric> an  independent LDP  connection between  every adjacent  pair of  LSRs.  The
Eric> notion of  passing attributes  along the path,  by passing them  through the
Eric> sequence of LDP  connections, is well understood; see  the "path vector" and
Eric> the "MTU" attributes.)

I agree. The consequence is that N-SRC-PE should wait for a Label Mapping Message from U-SRC-PE before it can send a Label Mapping Message to N-DST-PE. In return, N-DST-PE cannot send a Label Mapping Message to N-SRC-PE until it has received a Label Mapping Message from U-DST-PE. In other words, there is a definite sequence to the actions along the path.

When this sequence of actions is clearly understood, then I agree that this method is equivalent to sending an RSVP-TE message along the path. 

However, I still believe that there is a subtle difference with "standard" LDP. In standard LDP with downstream unsolicited mode, N-SRC-PE would send Label Mapping Messages to all its peers. In the GVPLS approach, it sends Label Mapping Messages to those peers that are on the path to U-PEs that support the same VPLS. It uses information from the Label Mapping Message (i.e. the Generalized FEC) and knowledge of the topology, that it has somehow acquired, to determine which of it peers it has to send Label Mapping Messages to (and not just one message, but possibly more than one, depending on the number of U-PEs that are hidden behind that N-PE).

I would still argue that we are defining a new protocol, but I don't have a vested interest in RSVP-TE and I think we can make this form of LDP work, if we define it unambiguously.

> Peter> In a  previous email I asked  how an N-PE discovers  the "local list"
> Peter> and   "remote  list"   that   you  mention   in   section  5.5.1   of
> Peter> draft-rosen-l2-signaling.  From your answer I got the impression that
> Peter> you envisioned that those lists  would be manually provisioned by the
> Peter> Service Provider.
> 
Eric> No, the information can  be distributed by whatever 
Eric> auto-discovery procedure we are using.  

I don't think so. Speaking in the context of L2 VPNs, the autodiscovery procedures tell us which U-PEs support a given VPLS. They don't tell us where the intermediate switches are and how they are connected to each other.

There are autodiscovery protocols that enable network elements to learn the network topology they have to deal with. They are called routing protocols. I maintain that if you want to do GVPLS right you have to run a combination of BGP and/or your favorite IGP to find out where the PW Label Switching Nodes are and how they are connected to each other and to U-PEs.

I think this email thread is coming to an end. In closure I would like to summarize my original point: to find the right solution for GVPLS, you have to generalize the concept of a PW: abolish the notion of a PW being a direct connection between two peer nodes and accept the notion that a PW is an LSP that is routed through multiple intermediate LSRs that switch based on the PW label.

In a certain sense it is a matter of perspective. There is a tendency to look "outward". I.e. given a VPLS, try to define what to build around it to generalize it. Instead, one should look "inward". Given a VPLS, try to define how you can add intermediate nodes that aggregate and switch traffic between the PEs. It seems that looking outward is more in line with the natural evolution of networks, but that is just an optical illusion.