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