RE: Extensions to LDP Signaling for PBB-VPLS -

["David Allan" <dallan at nortel.com>]

HI Florin:

> 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


> -----Original Message-----
> From: David Allan [mailto:dallan at nortel.com]
> Sent: Thursday, July 30, 2009 8:23 AM
> To: BALUS Florin; l2vpn at ietf.org
> Subject: RE: Extensions to LDP Signaling for PBB-VPLS -
> 
> 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:Florin.Balus at alcatel-lucent.com]
> Sent: Thursday, July 30, 2009 11:04 AM
> To: Allan, David (CAR:NS00); l2vpn at ietf.org
> Subject: RE: Extensions to LDP Signaling for PBB-VPLS -
> 
> 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:dallan at nortel.com]
> > Sent: Thursday, July 30, 2009 12:49 AM
> > To: BALUS Florin; l2vpn at ietf.org
> > Subject: Extensions to LDP Signaling for PBB-VPLS -
> >
> > 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