Re: draft-kompella-l2vpn-vpls-multihoming-01

[Bhupesh Kothari <bhupesh at juniper.net>]

Hi Wim,

HENDERICKX Wim <wim.henderickx at alcatel-lucent.be> wrote:

> Bhupesh,
> 
> Thanks, In this case does the solution allows 2 different designated
> forwarder for 2 different VE(s) on the same PE as per the example below.
> I would assume it does. PE3 would have to maintain a PW to each PE (PE1
> and PE2 in the example).

Not necessary. The existence of PWs is independent of how we will
flush MACs.  Consider that VE1 is VE ID 1, VE2 is VE ID 2 and VE3 for
PE3 is VE ID
3.  

Assumes that PE1 is "better" than PE2 for both VE1 and VE2 (based on
preference).  In this case:

-  PE1 will have one PW to PE3 (between IDs 1 and 3). 
-  PE2 will have no PW.
-  PE3 will have one PW to PE1 (between IDs 3 and 1). 

In this case, for both customer sites, CE1 and CE2, PE1 is the
designated forwarder. 


If PE2 is better for VE2 and PE1 is better for VE1, then:

- PE1 (ID 1) will have a PW to PE2 (ID 2) and PE3 (ID 3)
- PE2 (ID 2) will have a PW to PE1 (ID 1) and PE3 (ID 3)
- PE3 (ID 3) will have a PW to PE1 (ID 1) and PE2 (ID 2)

In this case, CE1 traffic is through PE1 and CE2 traffic is through
PE2.

In either case, the goal is to have an implicit or an explicit flush
that will flush only the MACs that need to be.  Note that BGP VPLS has
implicit flush semantics as it is aware of multi-homed sites.


> As you mentioned below we should extend the solution with a MAC flush
> capability like LDP does today.

Yes, we'll add the explicit flush.  The explicit flush capability
provides optimization at the expense of more state in the control
plane as now the PEs need to track the MACs learned in forwarding so
that those can be withdrawn later on.


> 
> Cheers,
> Wim 

Thanks
Bhupesh