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

Request for comments ===>Fw: Two issues regarding BGP VPLS

Subject: Request for comments ===>Fw: Two issues regarding BGP VPLS
From: Huke Hu Chun Zhe
Date: Fri, 14 Jan 2005 08:53:39 +0800
----- Original Message ----- 
From: "Huke Hu Chun Zhe" <huchunzhe@xxxxxxxxxx>
To: <kireeti@xxxxxxxxxxx>
Sent: Friday, January 07, 2005 6:54 PM
Subject: Re: Two issues regarding BGP VPLS


> This is me and Dhruv's formal reply , please check 
> 
> Dear Kireeti,
> 
>  
> 
> Issue 1: Multi homing
> 
> From the draft - “When a BGP speaker receives two equivalent NLRIs (see below 
> for the definition), 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.”
> 
>  
> 
> 1)     We cant use the BGP standard path selection algorithm as per your reply
> 
> 2)     Cant use AS Path Length as mentioned in your reply, but stated in draft
> 
> 3)     Local Preference is local to an AS and is exchanged between IBGP peers 
> only, when multi-homed PEs belong to different AS, we cannot use it.
> 
> 4)     We have a full mesh requirement for PEs within an AS but when a site 
> is multi-homed to PEs belonging to different AS a full mesh requirement 
> between these PEs is a too much to ask for.
> 
>  
> 
> Issue 2: Tunnel Handling
> 
> Removing the site from VPLS, when tunnel to one peer is down will be a very 
> costly operation. In case of route damping or tunnel fluctuation we would end 
> up sending REACH / UNREACH to all the peers and the whole VPLS would be 
> affected because of just one peer. The data plane would loose its robustness 
> and all the PEs throughout the VPLS would be adding and deleting forwarding 
> entries. 
> 
>  
> 
> In case of VPLS via LDP draft-ietf-l2vpn-vpls-ldp-03 we can send withdrawn to 
> just one peer and there would be no impact on other PEs in the VPLS. In case 
> of PWE3 we have mechanism to send notification to peers in case of such 
> tunnel events. This makes the data plane very stable.
> 
>  
> 
> Tunnel down to just one peer (a particular site) should be notified to that 
> peer. In case we add CSV bits we would send Reach NLRI again but forwarding 
> entries would be updated only on the target PEs and at all other PEs NLRIs 
> would just be updated. 
> 
>  
> 
> The idea of removing a site completely for VPLS in an event of just one 
> tunnel down seems inappropriate.
> 
>  
> 
> Thank you for these prompt replies.
> 
>  
> 
> Regards,
> 
> Huchunzhe / Dhruv
> 
> 
> 
> ----- Original Message ----- 
> From: <kireeti@xxxxxxxxxxx>
> To: <huchunzhe@xxxxxxxxxx>; <kireeti@xxxxxxxxxxx>
> Sent: Friday, January 07, 2005 2:04 PM
> Subject: Re: Two issues regarding BGP VPLS
> 
> 
> > > I think if only one tunnel btw PE1 and PE9 go down 
> > > PE1 will withdraw from VPLS , this process is very costly 
> > > compared with martini mode , where there is notification in LDP
> > > to recover from this tunnel down and again up event .
> > 
> > I think you are missing the point.  VPLS *requires* a full mesh.
> > This is independent of the protocol used for signaling.  So whether
> > the signaling is BGP or LDP, PE1 has to withdraw from the VPLS.
> > With BGP, this is a single NLRI withdrawal.  With LDP, PE1 has to
> > send N independent withdraws (or notifications).
> > 
> > (If you go over the L2VPN archives, you will see a discussion on this.)
> > 
> > Kireeti.
<Prev in Thread] Current Thread [Next in Thread>
  • Request for comments ===>Fw: Two issues regarding BGP VPLS, Huke Hu Chun Zhe <=