Subject: Two issues regarding BGP VPLS

From: Huke Hu Chun Zhe <[email-masked]>
Date: Mon, 03 Jan 2005 17:27:24 +0800

Dear All,
regarding draft " draft-ietf-l2vpn-vpls-bgp-02 "
there are two issues :

Issue 1: 

Problem description in Multi Homing

What is multi homing?

Multi-home a VPLS site is to connect it to multiple PEs, perhaps even in different ASes.  In the case where the PEs connected to the same site are assigned the same VE ID, a loop-free topology is constructed by routing mechanisms, in particular, by BGP path selection.  When a BGP speaker receives two equivalent NLRIs, it applies standard path selection criteria such as Local Preference and AS Path Length to determine which NLRI to choose; it MUST pick only one.  If the chosen NLRI is subsequently withdrawn, the BGP speaker applies path selection to the remaining equivalent VPLS NLRIs to pick another; if none remain, the forwarding information associated with that NLRI is removed.

Two VPLS NLRIs are considered equivalent from a path selection point of view if the Route Distinguisher, the VE ID and the VE Block Offset are the same.  If two PE are assigned the same VE ID in a given VPLS, they MUST use the same Route Distinguisher, and they MUST   announce the same VE Block Size for a given VE Offset.

Problem

VSI configured at PE1 and PE2 with same RD, site ID and offset, like: 

ce1-------------------------pe1--------------------------pe3------ce2

  |------------------------pe2---------------------------|

In this scenario CE1 is connected to 2 different PE and thus is multi-homed. PE1 and PE2 both advertise the NLRIs, in PE3 BGP received 2 set of label blocks from PE1 and PE2 and PE3 in turn must have broadcast his NLRI to both PE1 and PE2. BGP here runs the best route selection algorithm and say select the label block from PE2 as best and thus notify this label block to VPLS VSI. A PW is thus formed between PE2 and PE3.

In this whole time PE1 does not know that his label block has not been selected in the best route selection and thus unaware of the fact that VSI PE3 does not even know that PE1 exist. PE1 form a PW because he has received a reach NLRI from PE3; downloads and make VSI state up. 

PE1 and PE2 both think they have a PW to PE3. PE3 has PW only to PE2 and does not even know about the existence of PE1.  

Use of Un-Reach NLRI cannot solve the problem as BGP is broadcast and we cannot send UN Reach to only one BGP peer. Adding CSV bits as well may not solve it. This is an open issue with the multi homing based on draft - draft-ietf-l2vpn-vpls-bgp-02. 

One Alternative means may use same mechanism in BGP VPLS address family to send VSI status thru new BGP message like LDP notification MSG to notify VC status.

Please give your valuable comments regarding this.

Issue 2:  CSV problem

VPLS Phase - II Tunnel Handling proposal for BGP

Current Design

The sending of Reach and Un Reach NLRI is based only on the availability of the AC. The availability of tunnel is not taken into consideration. The PW status is based on the tunnel. So a case when the tunnel goes down at a PE, we would make the PW down and download accordingly but cannot send UN Reach or any other notification to the peers and thus the state of PW in remote side would be UP. The reason for enable to send UN Reach NLRI is that BGP label block is advertised to all the BGP peers we do not have separate notification to a corresponding peer. Thus UN Reach cannot be send when tunnel to a particular BGP peer goes down. So we end up having a condition such that at one peer PW state down and other UP when tunnel up / down happens. 

Proposal

In case of L2VPN we had CSV bits. These bits denoted weather a particular connection local state is up or down which was based on the interface and tunnel state. 

Based on the draft-ietf-l2vpn-vpls-bgp-02 the NLRI for VPLS do not have any CSV bits. We can use CSV in VPLS to denote the state of tunnel. Since CSV is not a part of draft we may add a CLI to distinguish weather we should use it or not. We can allow PW establishment even when CSV bits are not part of Reach NLRI. 

Proposed design is such that when site ID is configured we set the all CSV bits as 0 indicating the local state is UP. In this case initially we receive all the remote label blocks and discover the peers in the VPLS. When we try to form a PW we search for a tunnel to the remote peer, if tunnel exist we continue our processing normal. If tunnel does not exist we create PW but the state of PW is down at this moment we send Reach NLRI again with CSV bit unset (1) for this particular peer. On receiving of Reach NLRI we check the CSV bits now the CSV bits indicate the remote state of the PW; if the remote state is 1; we make the PW state down. When tunnel available we again send a reach NLRI with bit as 0 and on receiving the NLRI we can make the PW state up as local and remote state depending on the tunnel is available. 

   +------------------------------------+

   |  Length (2 octets)                 |

   +------------------------------------+

   |  Route Distinguisher  (8 octets)   |

   +------------------------------------+

   |  VE ID (2 octets)                  |

   +------------------------------------+

   |  VE Block Offset (2 octets)        |

   +------------------------------------+

   |  VE Block Size (2 octets)          |

   +------------------------------------+

   |  Label Base (3 octets)             |

   +------------------------------------+

   |  Variable TLVs (0 to N octets)     |

   |              ...                   |

   +------------------------------------+

Circuit Status Vector

A new sub-TLV is introduced to carry the status of a VPLS PW between a pair of PEs.  

A PE should monitor the status of the tunnel towards the remote PE; it can inform the remote PE about tunnel events.  Similarly, the remote PE can inform the status of its tunnel to the first PE.  Combining the local and the remote information, a PE can determine the status of a PW.

The basic unit of advertisement in VPLS for a given PE is a label-block.  Each label within a label-block corresponds to a PW on the Site.  So we can advertise the local status information (i.e. the tunnel information) for all PWs corresponding to a label-block along with the label-block's NLRI.  This can be done by introducing the circuit status vector TLV.

The value field of this TLV is a bit-vector, each bit of which indicates the status of the PW associated with the corresponding label in the label-block.  Bit value 0 indicates that the tunnel to the remote PE is up, while a value of 1 indicates that tunnel is down.

PE A, while selecting a label from a label-block (advertised by PE B, for remote Site m, and VPLS X) for its local Site n (in VPLS X) can  also determine the status of the corresponding PW (between Site n and Site m) by looking at the appropriate bit in the circuit status vector.

The length field of the TLV specifies the length of the value field in bits.  The value field is padded to the nearest octet boundary.

Thank you.
Huke.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 5 Jan 2005 09:44:02 -0800 (PST)

Hi Huke,

> regarding draft " draft-ietf-l2vpn-vpls-bgp-02 "

Thanks for your comments.

> In this scenario CE1 is connected to 2 different PE and thus is
> multi-homed. PE1 and PE2 both advertise the NLRIs, in PE3 BGP
> received 2 set of label blocks from PE1 and PE2 and PE3 in turn must
> have broadcast his NLRI to both PE1 and PE2. BGP here runs the best
> route selection algorithm and say select the label block from PE2 as
> best and thus notify this label block to VPLS VSI. A PW is thus
> formed between PE2 and PE3.
>
> In this whole time PE1 does not know that his label block has not
> been selected in the best route selection and thus unaware of the
> fact that VSI PE3 does not even know that PE1 exist. PE1 form a PW
> because he has received a reach NLRI from PE3; downloads and make
> VSI state up.

Actually, since iBGP requires (logical) full mesh connectivity in the
control plane, PE1 will see PE2's NLRI.  So, PE1 can know whether it
wins the path selection or not, and based on that, can decide whether
or not to establish PWs to other PEs.  Similarly for PE2.

Note that path selection for VPLS MUST yield the same result for all
PEs (i.e., if PE1 and PE2 are dual-homed to site 1 in VPLS foo, all
PEs in VPLS foo MUST pick the same PE to reach site 1.)  I'll clarify
this in the next version of the draft.

> The sending of Reach and Un Reach NLRI is based only on the
> availability of the AC. The availability of tunnel is not taken into
> consideration.

It is a requirement that PEs in a VPLS must be full-meshed in the data
plane.  Suppose PE1, PE2, PE5, PE7 and PE9 are in VPLS foo.  In this
case, there must be data connectivity among all these PEs, that is,
tunnels and PWs.  If even one tunnel goes down (say between PE1 and
PE9), then either PE1 or PE9 must withdraw from the VPLS.  This can be
accomplished by having the head-end of the tunnel LSP withdraw its
NLRI when it realizes that the tunnel is down.

Hope that helps,
Kireeti.
-------