RE: Extensions to LDP Signaling for PBB-VPLS -

["BALUS Florin" <Florin.Balus at alcatel-lucent.com>]

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

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