Subject: Re: L2vpn Digest, Vol 9, Issue 1

From: Huke Hu Chun Zhe <[email-masked]>
Date: Tue, 04 Jan 2005 14:14:06 +0800

Dear Hector,

Thanks for your reply but I still think we face the same problem.

Case I: Where there exist BGP session between PE1 and PE2. 
PE1 may receive a NLRI from PE2 with the same VE-ID, this would only tell PE1 that PE2 is multi-homed that is it has a same RD and VE-ID. The best route selection would run at PE3 and he would select one of the PEs PE1 or PE2. What is the best route at PE3 cannot be informed at PE1 and PE2. 
Also please note that according to L2VPN Kompella we should reject the NLRI if the remote CE-ID matches with the local CE-ID. 

Case II:  Where there exist no (VPLS enabled) BGP session between PE1 and PE2
Multi-homing should work in this scenario as well.

As far as forwarding is concerned, since PE1 and PE2 are un-aware of the best route and both have received a NLRI from PE3, both would form a Pseudo-wire and make the VSI status up and download the forwarding entries. At PE3, since BGP notifies only the best route PW exists only for one of the PEs. Forwarding at PE1 which is not the best route would continue; he would send traffic to PE3 continuously. The same would be dropt at PE3 though because no entries exist for the same. PE1 would not be aware of this situation at any time. 

Thank You,

Huchunzhe / Dhruv

----- Original Message ----- 
From: "Hector Avalos" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 04, 2005 1:43 AM
Subject: RE: L2vpn Digest, Vol 9, Issue 1

Hi,

Regarding the issue number 1 that you mention, you need to consider that
PE1 will also get PE2 NLRI advertisement.
It will do std BGP path selection and will know that he is not the
'active' PE for CE1.

PE1 can set up a PW with PE3, but it will not forward any traffic to it
(and any other PE for the same VPLS domain).

PE3 will have both PE1 and PE2 NLRI but only one being active.
When PE2 NLRI is withdrawn, PE3 does path selection and uses PE1 LNRI.

cheers,

Hector 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 03 January 2005 18:15
To: [email-masked]
Subject: L2vpn Digest, Vol 9, Issue 1

Send L2vpn mailing list submissions to
[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
https://www1.ietf.org/mailman/listinfo/l2vpn
or, via email, send a message with subject or body 'help' to
[email-masked]

You can reach the person managing the list at
[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of L2vpn digest..."

Today's Topics:

   1. Two issues regarding BGP VPLS (Huke Hu Chun Zhe)

----------------------------------------------------------------------

Message: 1
Date: Mon, 03 Jan 2005 17:27:24 +0800
From: Huke Hu Chun Zhe <[email-masked]>
Subject: Two issues regarding BGP VPLS
To: Mustapha Aissaoui <[email-masked]>, [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=iso-8859-1

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. 

------------------------------

_______________________________________________
L2vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 9, Issue 1
***********************************