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