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

From: Bhupesh Kothari <[email-masked]>
Date: Mon, 04 Aug 2008 11:51:21 -0700

HENDERICKX Wim <[email-masked]> wrote:

> During the session I expressed concerns regarding 2 dual homes CE(s)
> on 2 PE(s) with multi-homing. Here is the scenario I had in mind.
> 
>                             (VE1, VE2)
>                 ____ PE1………………..
>               /  ____/  :                               :
>         __/   /         :                                PE3
> CE1 __   /          :                                 :
>             \ /             :                              :
>              / \_____ PE2 ………………
>        __/               /  (VE1, VE2)
> CE2 _________/
> 

> PE3 picks a designated forwarder lets say PE1 for both CE1 and
> CE2. After discussion what I understood is that when CE1 fails PE3
> reelects the designated forwarder for both CE1 and CE2 and PE3 also
> flushes the Mac table.

When CE1--PE1 link fails, all PEs will reelect who is the designated
PE for VE1 (assuming VE1 is for CE1).  Since the designated PE in this
case will move from PE1 to PE2, PE3 needs to flush the MACs learned
from PE1.

> 
> This should be addressed as an impact on CE1 should not impact other
> CE(s) according to me.
> 

In VPLS, there is only one PW between a pair of PEs as the ACs are not
tied to particular remote neighbors as in the case of P2P L2VPNs.
Since PWs are not tied to ACs, when a AC goes down there is no way to
flush just the MACs associated with a particular AC other than
explicitly sending a list of MACs to be flushed.  In your example, PE1
can send a list of MACs (learned from CE1) to be flushed to PE3.  The
capability to send a list of MACs to be flushed is not yet there, but
can be added.

> Cheers,
> Wim

Thanks
Bhupesh

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Mon, 4 Aug 2008 21:17:41 +0200

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

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

Cheers,
Wim 

-----Original Message-----
From: Bhupesh Kothari [mailto:[email-masked]] 
Sent: maandag 4 augustus 2008 20:51
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: draft-kompella-l2vpn-vpls-multihoming-01

HENDERICKX Wim <[email-masked]> wrote:

>                 ____ PE1....................
>               /  ____/  :                               :
>         __/   /         :                                PE3
> CE1 __   /          :                                 :
>             \ /             :                              :
>              / \_____ PE2 ..................
>        __/               /  (VE1, VE2)
> CE2 _________/
> 

> PE3 picks a designated forwarder lets say PE1 for both CE1 and CE2. 
> After discussion what I understood is that when CE1 fails PE3 reelects

> the designated forwarder for both CE1 and CE2 and PE3 also flushes the

> Mac table.

When CE1--PE1 link fails, all PEs will reelect who is the designated PE
for VE1 (assuming VE1 is for CE1).  Since the designated PE in this case
will move from PE1 to PE2, PE3 needs to flush the MACs learned from PE1.

Thanks
Bhupesh

---

From: Bhupesh Kothari <[email-masked]>
Date: Mon, 04 Aug 2008 12:20:49 -0700

BALUS Florin <[email-masked]> wrote:

> I have some other comments, questions I want to raise on this draft:
> 
> -          Let’s assume PE1 is chosen by PE3 over PE2 in the diagram below
> 
> -          The distribution model for BGP VPLS information (through BGP) is one to many with no individual p2p
> communication between PE2-PE3.
> 
> -          How does PE2 know that he was not chosen by PE3? PE3 needs to know that to bring down its own data plane
> towards PE2 or otherwise I see some problems (e.g. PE3 sending BUM traffic to PE2 wasting bandwidth in the core, even
> confusion at PE3 for the PHP case when receiving traffic from both PE2 and PE1 from the same VE ID).

It's explained in Section 3 of the draft.  In brief, path selection on
all VPLS PEs (and RRs if any) will deterministically elect a single
designated PE for a multi-homed customer site.  In your case, path
selection on PE1, PE2 and PE2 will result in PE1 as the winner
(assuming PE1 is better than PE2 -- what is considered better is
specified in the draft).

> 
> Adding to the comments raised below by Wim
> 
> -          I think the case of a single homed CE mixed with the dual-homed ones seems even more problematic: i.e. the
> single-homed CE could be left hanging, isolated from the other VPLS sites.
> 

A single homed customer site is expected to be assigned a different VE
ID than a multi-homed site on the same PE.

> -          I was under the impression this could be done by assigning separate VE IDs & label blocks for each
> dual-homed CEs/single-homed CE group (a complex solution, wasting a lot of label block resources).  I understood from
> hallway discussions that the authors said the separate VE IDs are not anyhow the solution. Can we get a confirmation
> about how this is addressed?
> 

It must be a misunderstanding.  As I explained above, assigning
different VE IDs is the right approach.

> Thanks,
> Florin

Thanks
Bhupesh

---

From: Bhupesh Kothari <[email-masked]>
Date: Mon, 04 Aug 2008 13:37:20 -0700

Hi Wim,

> I would assume it does. PE3 would have to maintain a PW to each PE (PE1

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.

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

Thanks
Bhupesh

---

From: "BALUS Florin" <[email-masked]>
Date: Mon, 4 Aug 2008 17:42:05 -0500

Bhupesh,
Thanks for your answers. See in-line...

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Bhupesh Kothari
> Sent: Monday, August 04, 2008 12:21 PM
> To: BALUS Florin
> Cc: [email-masked]
> > -          The distribution model for BGP VPLS information (through
> BGP) is one to many with no individual p2p
> > -          How does PE2 know that he was not chosen by PE3? PE3 needs
> to know that to bring down its own data plane
> > towards PE2 or otherwise I see some problems (e.g. PE3 sending BUM
> traffic to PE2 wasting bandwidth in the core, even
> > -          I think the case of a single homed CE mixed with the dual-
> homed ones seems even more problematic: i.e. the

[[FB]] Then it means that for each "active/preferred" PE and for each VPLS instance there will be at least two set of PWs: one for the VE ID assigned for the Single-Homed sites, another one for the dual-homed CE1, even if they are part of the same customer VPLS service. 
Otherwise the failure of CE1-PE1 link will bring down all the PWs to that VPLS switching instance on PE1, isolating all the single-homed CEs. 

Also assuming more than one dual-homed sites are present on PE1 in a VPLS instance (& assuming for simplicity PE1 is the preferred PE for all of them), then you will also need a different VE ID for each of these CEs and a different set of PWs for each of them: i.e. one for dual-homed CE2,... one for dual-homed CEn, even if they are part of the same customer VPLS? 
Otherwise failure of CE1-PE1 link will produce interruption of service for the other dual-homed CEs (CE2-CEn).

Did I understand correctly?

Florin

> > dual-homed CEs/single-homed CE group (a complex solution, wasting a
> lot of label block resources).  I understood from
> > hallway discussions that the authors said the separate VE IDs are not
> anyhow the solution. Can we get a confirmation

---

From: Bhupesh Kothari <[email-masked]>
Date: Mon, 04 Aug 2008 17:29:30 -0700

Hi Florin,

> [[FB]] Then it means that for each "active/preferred" PE and for
> each VPLS instance there will be at least two set of PWs: one for
> the VE ID assigned for the Single-Homed sites, another one for the
> dual-homed CE1, even if they are part of the same customer VPLS
> service.  Otherwise the failure of CE1-PE1 link will bring down all
> the PWs to that VPLS switching instance on PE1, isolating all the
> single-homed CEs.

No, there is only one PW between a pair of PEs and so only one PW is
created even though two customer sites are connected to PE1.  When the
CE1-PE1 link goes down and if the PW goes down (depends on the VE ID),
then another PW will be reestablished, for the single homed site as it
has a unique VE ID in the VPLS instance, and hence, the site will
never be isolated from the VPLS domain.  The remote peers already know
the label to use to reach that single homed site.

> Also assuming more than one dual-homed sites are present on PE1 in a
> VPLS instance (& assuming for simplicity PE1 is the preferred PE for
> all of them), then you will also need a different VE ID for each of
> these CEs and a different set of PWs for each of them: i.e. one for
> dual-homed CE2,... one for dual-homed CEn, even if they are part of
> the same customer VPLS?  Otherwise failure of CE1-PE1 link will
> produce interruption of service for the other dual-homed CEs
> (CE2-CEn).
> 

A different VE ID will be required, but PW is not created for each.

I'll add more text in the draft to explain operations in such
scenarios. 

Bhupesh

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Tue, 5 Aug 2008 09:55:01 +0200

Bhupesh, thx more in-line

-----Original Message-----
From: Bhupesh Kothari [mailto:[email-masked]] 
Sent: maandag 4 augustus 2008 22:37
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: draft-kompella-l2vpn-vpls-multihoming-01

Hi Wim,

HENDERICKX Wim <[email-masked]> wrote:

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

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

WH> Indeed this is what I meant. Thx for clarifying

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.

WH> How would this work? E.g. in the example we use PE3 has no awareness
of the Mac @ belonging to which CE on a given PE.

Thanks
Bhupesh

---

From: "BALUS Florin" <[email-masked]>
Date: Tue, 5 Aug 2008 17:08:00 -0500

Hi Bhupesh,
Thanks for the answers. 

>From what you explain below the failure of the CE1-PE1 access link
affects the PW infrastructure and implicitly the communication between
all the other CEs connected to the same VPLS on PE1. I do not think this
is a good approach as it extends the scope of the failure.

More in-line for technicalities...

> Sent: Monday, August 04, 2008 5:30 PM
> To: BALUS Florin
> Cc: [email-masked]
> > > > single-homed CE could be left hanging, isolated from the other
> VPLS
> > > sites.
> > > >
> > >
> > > A single homed customer site is expected to be assigned a
different
> VE
> never be isolated from the VPLS domain.  

[[FB]] From what you are saying here it looks like the dual-homed CE1
and the single-homed CEs on PE1 share initially the same PW. Then if
CE1-PE1 link fails the initial PW will be torn down and a new PW will be
re-established towards PE2 in order to reach CE1. Also another PW to the
site corresponding to the single-homed CEs on PE1 will be
reestablished/activated. 

This results in a service interruption for single-homed sites due to
failure of CE1-PE1 access link. I think this is not acceptable as it
increases the scope of the failure unnecessarily. 

>The remote peers already know
[[FB]] From what you are saying the service labels/PWs assigned for the
dual-homed site/VE ID are used for all the other sites/VE IDs in the
VPLS on PE1? In other words the remote PE peers do not instantiate in
the data path the service labels for the single-homed site/VE ID from
PE1? 

What if there are multiple dual-homed sites on the same PEs, in the same
VPLS? Which VE ID's PW is chosen and based on what? (I am talking about
the case of different sites/VE IDs in the same VPLS)

Thanks,
Florin

---

From: Bhupesh Kothari <[email-masked]>
Date: Wed, 06 Aug 2008 12:09:02 -0700

> of the Mac @ belonging to which CE on a given PE.

I should have been more clear.  A MAC flush message from PE1 containing a list
of MACs will be sufficient for this purpose.

Bhupesh

---

From: Bhupesh Kothari <[email-masked]>
Date: Wed, 06 Aug 2008 14:54:12 -0700

Hi Florin,

> is a good approach as it extends the scope of the failure.

The scope of the failure is not extended to other CEs.  See below for
more details.

> re-established towards PE2 in order to reach CE1.

Correct.

> Also another PW to the site corresponding to the single-homed CEs on
> PE1 will be reestablished/activated.
> 

Your understanding is correct about the PW activation, but this does
not necessarily mean traffic disruption for single-homed site.  See
below for details.

> VPLS on PE1?

Yes.

> In other words the remote PE peers do not instantiate in the data
> path the service labels for the single-homed site/VE ID from PE1?
>

Yes.

> the case of different sites/VE IDs in the same VPLS)

Irrespective of whether multiple sites are all multi-homed or only
some are multi-homed and others single-homed, ONLY one site is
"selected" for PW establishment that will carry traffic.  The site
with the lowest site ID is selected for this purpose.  So, if the
multi-homed site ID is 1 and single-homed site ID is 2, just for the
PW establishment, ID 1 is picked by all remote PEs.

Its an implementation detail, but here is a general explanation of why
there shouldn't be any traffic loss.  For clarity, consider:

              CE4 -------    ...............
                         \  .               .    ___ CE2
                      ___ PE1                .  /
                     /    :                  PE3
                  __/    :       Service      :
              CE1 __     :       Provider    PE4
                    \     :                   : \___ CE3
                     \___ PE2                .
                            .               .
                             ...............

PE1 has two sites, one multi-homed and other single-homed.  Site IDs
are 1 (for CE1) and 4 (for CE4). 

On PE2, there is just one site, with ID 1 for CE1 (multi-homed).

On PE3, there is just one site, with ID 2 for CE2

For simplicity, lets just consider one remote PE, PE3, for
explanation.  Also assume that PE1 has higher preference than PE2.

PE3 will establish just one PW to PE1.  For this PW, PE1 programs its
FIB with labels it advertises for site ID 1.  For this PW, PE3 selects
site ID 1 from the list of sites on PE1, and so the labels advertised
by PE1 for site ID 1 are used.  In other words, there is one PW
between PE1 and PE3, and just for the PW establishment, site 1 and 2
are picked on PE1 and PE3 ends.  PE3 will send traffic for both CE1
and CE4 over this PW.

Note that PE3 also has NLRIs for site ID 4 from PE1.  PE3 simply keeps
those in its control plane state and only programs its FIB with labels
for site ID 1.  

When a failure occurs, all PEs should do "make-before-break" as the
labels are already known.

If CE1-PE1 link goes, PE1 has to advertise the NLRI for site 1 with D
bit set.  Before it advertises this, it programs its FIB with labels
it advertises for site ID 4 (for CE4).  It also does NOT tear down
it's end of the old PW (which used site 1 labels).  When PE3 learns
about the D bit for site 1, it knows that there is additional site,
site 4, on PE1, and so it should not simply tear down the old PW.  It
should program the labels that it received from site 4, then it should
switch traffic to the new PW and only then it should tear down it's
end of the old PW.  The question of when PE1 tears down it's end of
the old PW is again an implementationd detail, but it could be dumb
timer based or better heuristic based.

Also note that the path selection that PE3 does on receiving the D bit
for site 1 from PE1 is independent of what is explained above.  The
path selection will elect PE2 as the forwarder for site 1 and so a new
PW to PE2 will be set up.

> Florin

Hope it helps.

Thanks,
Bhupesh

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Thu, 7 Aug 2008 06:48:33 +0200

Thx for clarification, which BGP message do you envisage to use for this
purpose ?

-----Original Message-----
From: Bhupesh Kothari [mailto:[email-masked]] 
Sent: woensdag 6 augustus 2008 21:09
To: HENDERICKX Wim
Cc: [email-masked]
Subject: Re: draft-kompella-l2vpn-vpls-multihoming-01

HENDERICKX Wim <[email-masked]> wrote:
> > As you mentioned below we should extend the solution with a MAC 
> > flush capability like LDP does today.
> 
> WH> How would this work? E.g. in the example we use PE3 has no 
> WH> awareness

I should have been more clear.  A MAC flush message from PE1 containing
a list of MACs will be sufficient for this purpose.

Bhupesh

---

From: "BALUS Florin" <[email-masked]>
Date: Thu, 7 Aug 2008 18:06:07 -0500

Hi Bhupesh,

I think there is no way to guarantee that make before break for PWs with
MAC learning + MAC Flushing on top is hitless - i.e. synchronization of
different processes at the 2 PEs (label installation + switching between
old and new PWs, MAC Flush, MAC learning) depends on network condition,
PE load, traffic profile. 

So I think there is a good chance that the scope of failure does extend
to non-affected CEs even with the make before break scheme. 
There might be a need to look for an alternative to tearing down the
VPLS infrastructure every time something happens with one site. 

But of course we should hear from people running networks on this one
before spending additional cycles...

Thanks for the detailed answers.
Florin

> Sent: Wednesday, August 06, 2008 2:54 PM
> To: BALUS Florin
> Cc: [email-masked]
> > > > > > -          I think the case of a single homed CE mixed with
> the
> > > dual-
> > > then another PW will be reestablished, for the single homed site
as
> it
> > CE1-PE1 link fails the initial PW will be torn down and a new PW
will
> be

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 29 Aug 2008 10:45:00 -0700

Bhupesh, Wim:

I was just going through this draft and I have the following concern
regarding the dual-home mechanism described in this draft:

Both BGP Path selection and VPLS Path selection described in section 3.4
are based on the corresponding VSIs for the same VPLS on different PE
devices (AD = <RD, VE-ID, VBO, VBS, LB; DOM, BNH, CF, VP, LP>). In other
words, the BGP advertisement allows to pick one VSI for a given VPLS
instance among multiple PE devices that are dual/multi-homed. However,
redundancy needs to be provided at the port level and not VSI level for
dual/multi-homing of CE devices !!

In other words, if a CE1-PE1 link fails, you don't want to switch the
VSI from PE1 to PE2 and impact all other CE devices that are dual-homed
to PE1/PE2 for the same VPLS instance. Besides, the current H-VPLS
allows for dual-homing of the CE/u-PE devices that are load balanced
among dual/multi-homed PE devices for the same VPLS instance !!

-Ali

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Fri, 29 Aug 2008 20:20:29 +0200

Ali,

This is the same concern I raised in the emails before and will be
difficult to solve if you let the remote PE(s) make a decision for
multi-homing.

Cheers,
Wim 

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: vrijdag 29 augustus 2008 19:45
To: HENDERICKX Wim; Bhupesh Kothari
Cc: [email-masked]
Subject: Concern regarding draft-kompella-l2vpn-vpls-multihoming-01

Bhupesh, Wim:

-Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 29 Aug 2008 11:30:58 -0700

Wim,

So, has this issue been acknowledged and if so, then what is the remedy
?

Cheers,
Ali 

> From: HENDERICKX Wim [mailto:[email-masked]] 
> Sent: Friday, August 29, 2008 11:20 AM
> To: Ali Sajassi (sajassi); Bhupesh Kothari
> Cc: [email-masked]
> Subject: RE: Concern regarding 
> draft-kompella-l2vpn-vpls-multihoming-01
> 
> Ali,
> 
> This is the same concern I raised in the emails before and 
> will be difficult to solve if you let the remote PE(s) make a 
> decision for multi-homing.
> 
> Cheers,
> Wim 
> 
> I was just going through this draft and I have the following 
> concern regarding the dual-home mechanism described in this draft:
> 
> Both BGP Path selection and VPLS Path selection described in 
> section 3.4 are based on the corresponding VSIs for the same 
> VPLS on different PE devices (AD = <RD, VE-ID, VBO, VBS, LB; 
> DOM, BNH, CF, VP, LP>). In other words, the BGP advertisement 
> allows to pick one VSI for a given VPLS instance among 
> multiple PE devices that are dual/multi-homed. However, 
> redundancy needs to be provided at the port level and not VSI 
> level for dual/multi-homing of CE devices !!
> 
> In other words, if a CE1-PE1 link fails, you don't want to 
> switch the VSI from PE1 to PE2 and impact all other CE 
> devices that are dual-homed to PE1/PE2 for the same VPLS 
> instance. Besides, the current H-VPLS allows for dual-homing 
> of the CE/u-PE devices that are load balanced among 
> dual/multi-homed PE devices for the same VPLS instance !!
> 
> -Ali
> 
>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Fri, 29 Aug 2008 20:33:24 +0200

Ali,

It has been acknowledge, but the remedy has not been provided so far
afaik.

Cheers,
Wim 

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: vrijdag 29 augustus 2008 20:31
To: HENDERICKX Wim; Bhupesh Kothari
Cc: [email-masked]
Subject: RE: Concern regarding draft-kompella-l2vpn-vpls-multihoming-01

Wim,

Cheers,
Ali 

> Both BGP Path selection and VPLS Path selection described in section 
> 3.4 are based on the corresponding VSIs for the same VPLS on different

> PE devices (AD = <RD, VE-ID, VBO, VBS, LB; DOM, BNH, CF, VP, LP>). In 
> other words, the BGP advertisement allows to pick one VSI for a given 
> VPLS instance among multiple PE devices that are dual/multi-homed. 
> However, redundancy needs to be provided at the port level and not VSI

> VSI from PE1 to PE2 and impact all other CE devices that are 
> dual-homed to PE1/PE2 for the same VPLS instance. Besides, the current

> H-VPLS allows for dual-homing of the CE/u-PE devices that are load 
> balanced among dual/multi-homed PE devices for the same VPLS instance 
> !!
> 
> -Ali
> 
>

---

From: Bhupesh Kothari <[email-masked]>
Date: Fri, 29 Aug 2008 11:55:38 -0700

Ali,

> dual/multi-homing of CE devices !!

Not correct.  If you see other email thread on this topic on the
mailing list, I described scenarios that have multiple sites (or VE
IDs).  So, a PE can be a DF for a particular VE ID and non-DF for
another VE ID for the same VSI.  So, redundancy is not at the VSI
level; it is at the VE ID level.  A VE ID can map to a port or a set
of port depending on the topology.

> to PE1/PE2 for the same VPLS instance. 

Correct and thats not the case in BGP VPLS. 

> Besides, the current H-VPLS allows for dual-homing of the CE/u-PE
> devices that are load balanced among dual/multi-homed PE devices for
> the same VPLS instance !!

For a particular VLAN, a CE multi-homed to two PEs would require STP
or some other protocol in LDP VPLS to prevent loop as LDP VPLS PEs are
unware of the multi-homing.

Thanks,
Bhupesh

---

From: "BALUS Florin" <[email-masked]>
Date: Fri, 29 Aug 2008 14:14:08 -0500

See in-line..

> Sent: Friday, August 29, 2008 11:56 AM
> To: Ali Sajassi (sajassi)
> Cc: [email-masked]
> Subject: Re: Concern regarding
> 3.4
[[FB]] For multiple Dual-Homed CE sites & associated VE IDs located on
two PEs (PE1 and PE2) any failure of a link to the lowest Dual-Homed VE
ID (say VE ID 1) will actually generate infrastructure changes on both
PE1 and PE2 - i.e. on PE1 all the PW infrastructure with the next VE ID
(say VE2) takes over, and on PE2 the new lowest ID (i.e. VE ID 1)
imposes his own new PW infrastructure.

> Correct and thats not the case in BGP VPLS.

[[FB]] Actually I do think there are changes that will affect the VSI
infrastructure on both PEs - see above.

---

From: Bhupesh Kothari <[email-masked]>
Date: Fri, 29 Aug 2008 12:01:32 -0700

Hi Wim,

> difficult to solve if you let the remote PE(s) make a decision for

I thought I addressed all you MAC flush concerns. :-) 

As I said, MAC flush capability in BGP based VPLS will be added to
address the concern you pointed out (with multiple VE IDs) and other
cases where MAC flush is needed.

Can you be specific on what is your open concern. 

Thanks
Bhupesh

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 29 Aug 2008 13:44:09 -0700

Bhupesh,

Currently BGP VPLS requires only a single VE-ID per VPLS instance per
PE. Now with this proposal, if there are 100 CE devices dual-homed to a
pair of PE devices for a given VPLS instance, you can end up with 100
VE-IDs for each PE for that VPLS instance and thus having 100 VPLS
routes being advertised in BGP versus a single route as done currently
!! 

Cheers,
Ali  

> Cc: HENDERICKX Wim; [email-masked]
> Not correct.  If you see other email thread on this topic on 
> the mailing list, I described scenarios that have multiple 
> sites (or VE IDs).  So, a PE can be a DF for a particular VE 
> ID and non-DF for another VE ID for the same VSI.  So, 
> redundancy is not at the VSI level; it is at the VE ID level. 
>  A VE ID can map to a port or a set of port depending on the topology.
> 
> > 
> switch the 
> > dual-homed to PE1/PE2 for the same VPLS instance.
> 
> For a particular VLAN, a CE multi-homed to two PEs would 
> require STP or some other protocol in LDP VPLS to prevent 
> loop as LDP VPLS PEs are unware of the multi-homing.
> 
> 
> > 
> > -Ali
> > 
> 
> Thanks,
> Bhupesh
>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Sat, 30 Aug 2008 08:44:50 +0200

Bhupesh,

My main open concern is the modeling of MAC flush in BGP. How do we
ensure with this proposal that the amount of messages remains low.

So in essence I would like to see a proposal how the MAC flush operation
in BGP would be modeled.

Cheers,
Wim

-----Original Message-----
From: Bhupesh Kothari [mailto:[email-masked]] 
Sent: vrijdag 29 augustus 2008 21:02
To: HENDERICKX Wim
Cc: Ali Sajassi (sajassi); [email-masked]
Subject: Re: Concern regarding draft-kompella-l2vpn-vpls-multihoming-01

Hi Wim,

Thanks
Bhupesh