l2vpn@ietf.org
[Top] [All Lists]

Two issues regarding BGP VPLS

Subject: Two issues regarding BGP VPLS
From: Huke Hu Chun Zhe
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. 

<Prev in Thread] Current Thread [Next in Thread>