Subject: Re: Extensions to LDP Signaling for PBB-VPLS -

From: "BALUS Florin" <[email-masked]>
Date: Fri, 31 Jul 2009 03:24:28 -0500

Dave,
You are talking about some undocumented proposal that seem to be in IEEE scope. Before declaring it an all encompassing solution that covers all use cases  you need to document it and submitt it to IEEE for 802.1 scrutiny. As I explained to you, from the looks of it your proposal seems unnacceptable to at least part of the large VPLS deployments (1K+ PEs) where people value simple operations  and want to limit the number of bmacs in the network.

The solution we propose is generic and does not require any change in operation of existing VPLS networks. That is whyI said is consistent with what is in use. Moreover it is based on the same ldp withdraw message where pbb tlv is added automatically based on the place where the event takes place. 

I will be in vacation for the next while without access to email so Iwill have a hard time continuying this debate. Anyhow based on the above arguments I think this is the wrong context for discussing the value of your proposal without a well documented solution doc.  
Florin 

----- Original Message -----
From: [email-masked] <[email-masked]>
To: BALUS Florin; [email-masked] <[email-masked]>
Sent: Fri Jul 31 02:37:33 2009
Subject: RE: Extensions to LDP Signaling for PBB-VPLS - 

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:[email-masked]]
> Sent: Thursday, July 30, 2009 8:23 AM
> To: BALUS Florin; [email-masked]
> 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:[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,
> 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:
> >
> > 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