Subject: Extensions to LDP Signaling for PBB-VPLS -

From: "David Allan" <[email-masked]>
Date: Thu, 30 Jul 2009 03:48:34 -0400

Hi Florin:

I understand the problem this proposes to solve, but I believe there is
a simpler way. If you assign a B-MAC to a multihomed customer site then
you never need to invalidate C-MAC to B-MAC bindings and a MAC
invalidate message for the B-MAC is sufficient to ensure no black holing
when an AC goes down, normal flooding and learning permitting remote PEs
to learn which PE the customer site is reachable via. This provides for
the possibility of localizing the blocked/unblocked decision for the ACs
(which IMO needs to be coordinated between the MH PEs in order to be
robustly loop free) as knowledge of the multi-homing does not need to be
propagated into the network.

WDYT?
Dave

---

From: "BALUS Florin" <[email-masked]>
Date: Thu, 30 Jul 2009 10:04:07 -0500

Hi Dave,
As discussed after the session, we are proposing a generic solution that
does not depend on any special, locally configured, BMAC assignment
scheme. 
Florin

> -----Original Message-----
> From: David Allan [mailto:[email-masked]]
> Sent: Thursday, July 30, 2009 12:49 AM
> To: BALUS Florin; [email-masked]
> Subject: Extensions to LDP Signaling for PBB-VPLS -
> 
> Hi Florin:
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 30 Jul 2009 11:22:30 -0400

Understood,

...but I don't see a difference between administering MH-IDs and
administering B-MACs, 1:1 cardinality for any incremental administration
...and such state needs to reside somewhere....you simply now have more
classes of it...

IMO if a dual homed network is given a PIP on each of the PEs it is
homed upon with the slight abuse of having a common B-MAC address, I
believe no changes to existing control plane procedures are required,
and the subtending Ethernet can then select the active port (via MC-LAG,
STP or whatever procedures) without requiring any VPLS procedures or
control plane interworking to speak of. I will see more B-MAC addresses
than I would see otherwise,  but IMO this is only really parsitic if the
dual homed customer network is a single C-MAC (router). 

As for actual failure scenario, after the PIP B-MAC is withdrawn, there
will simply be a few flooded frames at the B-MAC layer until the new
path to the customer network is learned via the alternate PIP, the
customer network will not experience a lot of flooding of C-MAC frames
as the network convergence, in effect the fact there was a failure in
the network will not manifest itself in a lot of customer layer flooding
of frames...ergo, silently recovered ;-)

I like it...

Cheers
Dave

-----Original Message-----
From: BALUS Florin [mailto:[email-masked]] 
Sent: Thursday, July 30, 2009 11:04 AM
To: Allan, David (CAR:NS00); [email-masked]
Subject: RE: Extensions to LDP Signaling for PBB-VPLS - 

Hi Dave,

> invalidate message for the B-MAC is sufficient to ensure no black 
> holing when an AC goes down, normal flooding and learning permitting 
> remote PEs to learn which PE the customer site is reachable via. This 
> provides
for
> the possibility of localizing the blocked/unblocked decision for the 
> ACs (which IMO needs to be coordinated between the MH PEs in order to 
> be robustly loop free) as knowledge of the multi-homing does not need 
> to be propagated into the network.
> 
> WDYT?
> Dave

---

From: "BALUS Florin" <[email-masked]>
Date: Thu, 30 Jul 2009 14:19:07 -0500

Dave,
I was under the impression we closed the item during our afternoon
discussion. But you seem in-love with your idea! :) 
If you still think what you have in mind is sound, I suggest you put it
in a document and submit it to IEEE 802.1 for proper review in one of
the incoming IEEE sessions. 

I believe the solution we presented today is addressing in a generic way
the operational environment which is in scope for L2VPN WG: deployed LDP
VPLS networks using the existing LDP MAC Flush toolset. In this
environment it makes sense to have consistent procedures for both VPLS
and PBB-VPLS.
Florin

> Sent: Thursday, July 30, 2009 8:23 AM

---

From: "David Allan" <[email-masked]>
Date: Fri, 31 Jul 2009 03:37:33 -0400

> I was under the impression we closed the item during our afternoon
discussion. 

I appreciated the opportunity to understand some of your motivations for
your technical choices...but we'd not closed on consensus...If I gave
you that impression, that was unfortunate...

> But you seem in-love with your idea! :) 

Love is not the right term. I like the attributes of the solution, and
if those can be achieved by other means, I may like that as well...
There are two attributes I value here:

1) Knowledge of dual homing is local to the "homed upon" PEs, no broader
impacts on the network

2) C-MAC flush is not required at peer BEBs on a change of which PE/BEB
the CE is homed upon.

> If you still think what you have in mind is sound, I suggest you put
it in a document and submit it to IEEE 802.1 for 
> proper review in one of the incoming IEEE sessions. 

I understand that while this is not a formal project at the IEEE, it is
a hot topic, and they consider C-MAC flushing undesirable. My
expectation being that if they go forward, they would produce a solution
of similar attributes to those I value, even if not the same in detail.
Progressing a solution now in L2VPN may have attriutes incompatible with
what the IEEE ultimately does...

Meanwhile, if the WG insists on a solution in advance if IEEE, the IETF
has not been shy about moving MACs for resiliency reasons, witness VRRP,
and that could be done without any control plane changes...If what the
IEEE produces requires changes, it could be addressed at that time...

> I believe the solution we presented today is addressing in a generic
way the operational environment which is in scope 
> for L2VPN WG: deployed LDP VPLS networks using the existing LDP MAC
Flush toolset. In this environment it makes sense to 
> have consistent procedures for both VPLS and PBB-VPLS.

I'm not quite parsing this, if consistent procedures, nothing new would
be needed. Can you clarify this...?

Best
Dave

> administering B-MACs, 1:1 cardinality for any incremental 
> administration ...and such state needs to reside somewhere....you 
> simply now have
more
> and the subtending Ethernet can then select the active port (via MC- 
> LAG, STP or whatever procedures) without requiring any VPLS procedures

> or control plane interworking to speak of. I will see more B-MAC
addresses
> than I would see otherwise,  but IMO this is only really parsitic if 
> the dual homed customer network is a single C-MAC (router).
> 

> the network will not manifest itself in a lot of customer layer 
> flooding of frames...ergo, silently recovered ;-)
> 
> I like it...
> 
> Cheers
> Dave
> 
> As discussed after the session, we are proposing a generic solution 
> that does not depend on any special, locally configured, BMAC 
> assignment scheme.
> Florin
>