Summary of debate RE: Merge MAC Withdraw Drafts?

["Balus, Florin Stelian (Florin)" <[e-mail]>]

Since we had a long email exchange and Ali consolidated his arguments in one place I will do the same to make it easy for the WG to follow both sides. 

Why VPLS operators want to extend LDP-based MAC Flush for PBB-VPLS? 
- To provide one common tool for both VPLS/PBB-VPLS for the majority of MPLS-based use cases.	
- Simplifies PBB-VPLS implementation: no certification required, no OSS modification (it looks like even Ali is agreeing on these ones)

Perceived problems with LDP-based MAC Flush brought up on the list by Ali

1. inconsistency between draft-pbb-vpls-pe-model and draft-balus - initial high level statement from Ali. 

My answers:
We asked for clarifications two times and I am asking everybody to read Ali's latest clarification! 
We have been redirected to yet another draft - draft-ietf-l2vpn-vpls-bridge-interop - which supposedly mandates that CMAC Flush should be done with native Ethernet mechanisms. Putting aside the lack of any MUST/clear statement on CMAC Flush in the quoted text I will pinpoint that RFC 4762 already does CMAC flush using LDP MAC Withdraw. So I conclude this problem is not a valid one.

Shane, Giles, 

Do you see any problem here? Are we going to review RFC 4762? Also the expectation is that every party involved in email debates on this list should understand at least the meaning of keywords, not to speak about staying professional. 

I don't want to have to go through yet another redirection, to a 3rd draft! :)

2. requires interoperability at the gateway between MPLS and native PBB domains 

My answers:
- we never said the native PBB domain is in scope of the draft. We focused on MPLS use cases. So this issue does not apply. 

To help Ali trim MIRP Pros list wrt his generic statement below about MIRP not having any "interop issue" here are some facts:
- interoperability between MIRP and LDP MAC Flush will need to be implemented anyhow for the following use cases: networks where native PBB domains are connected via PBB-VPLS to regular LDP VPLS domains. 
- I mentioned also the case of the existing QinQ and new QinQ/G.8032 domains where MIRP does not cut it as one common tool across any use cases involving this kind of domains.

3. slow convergence - this is about the basic LDP hop-by-hop propagation

My answers:
- It looks from Ali's summary he agrees LDP hop-by-hop procedure works just fine in the field for HVPLS and MS-PW.
- our proposed procedure is improving substantially the use of the LDP hop-by-hop procedure - no data plane changes in the intermediate PEs compared with regular HVPLS - easy to see why we believe there will be no issue with its use for PBB-VPLS.

On the improvement claim between MIRP and LDP-based MAC Flush:
- To decide whether to add a second tool, any MPLS operator will ask what is the difference compared with existing LDP MAC Flush. Any implementer of MAC Flush procedure knows that in a good LDP implementation the time it takes LDP to propagate a message in the switch (control plane) is actually negligible compared with the time it takes even to deliver the LDP payload from one PE to the other. 

I asked Ali to quantify what "slower" means and I did not see any reply. I wish him luck in his endeavor to improve our operators "education"! :)

I apologize for the long email. I did my best to summarize all the arguments and responses but it has been a long exchange.

Regards 
Florin

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[e-mail]]
> Sent: Friday, May 07, 2010 6:00 PM
> To: Balus, Florin Stelian (Florin); Shane Amante; [e-mail];
> [e-mail]
> Subject: RE: Merge MAC Withdraw Drafts?
> 
> 
> Shane, Giles:
> 
> I think, we have spent enough time and energy to discuss this subject
> and I hope this discussion has been informative to our SP colleagues
> and
> the pros/cons of these two approaches are now clear since they are the
> real owner of these solutions. If after these healthy discussions,
> there
> are still some SPs/operators who want to go with LDP-based MAC withdraw
> for C-MACs in PBB-VPLS, then I would like to hear from them since they
> should have the final say.
> 
> Again, here is the summary for pros/cons of each approach based on my
> previous email:
> 
>  LDP-based:
> -------------
> Pros:
> -	Simple to implement, no certification required, no OSS
> modification
> -	Works for E2E MPLS only
> Cons:
> -	Slower to converge (relative to Ethernet mechanism)
> -	Creates interop issues and wll require additional interop
> solutions
> -	Requires implementing, testing, and operating such interop
> solutions
> 
> Native Ethernet-based:
> Pros:
> -	Simple to implement, no certification required, no OSS
> modification
> -	Works for E2E MPLS
> -	Faster to converge
> -	No interop issue
> -	No additional interop solution development, testing, and
> operating
> Cons:
> -	None ( based on this long email thread, no one has pointed a
> single con regarding this)
> 
> 
> Florin, a few comments inline to your response
> 
> - Ali
> 
> > -----Original Message-----
> > From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-
> > lucent.com]
> > Sent: Friday, May 07, 2010 10:30 AM
> > To: Ali Sajassi (sajassi); Shane Amante; [e-mail]; Giles Heron
> > ([e-mail])
> > Subject: RE: Merge MAC Withdraw Drafts?
> >
> > Shane, Giles,
> >
> > We have been rambling on this draft that requires only a new LDP TLV
> > for way too long and I think we did our best to answers Ali's points.
> > With the reply below I think we are at a point where we need to
> > conclude it is ok to agree to disagree - this is supposed to be my
> > night job! I wonder what will happen if we have to debate a 20 page
> > draft! :)
> >
> > Ali,
> >
> > I will summarize the point that is left on scalability to make some
> > steps towards the closure:
> > - you are admitting below there was "a perfect reason" to use LDP
> hop-
> > by-hop for MS-PW status and LDP MAC Flush.
> 
> For B-MACs !! and there is perfect reason for not doing it for C-MACs
> :-)
> 
> > - you do not have any real example to demonstrate the LDP hop-by-hop
> > procedure is broken - I prompted you to bring up any bad experience
> > with implementing and deploying HVPLS, MS-PWs and I did not see any
> > reply.
> 
> I never said it is broken or I have a bad experience with it. I have
> been saying that is a bad solution for C-MACs because of the above
> reasons (refer to the summary).
> 
> > - I asked you to highlight also any initiative targeted at fixing
> these
> > mechanisms in L2VPN or PWE3 and you did not reply with anything
> either.
> 
> Again, my issue is not with B-MAC flushing. As I said numerous times,
> you can extend the B-MAC flush for C-MAC addresses but you will create
> tons of interop issues down the road and if every SDO does the same
> thing we will have a nightmare. You have conveniently sidestepping
> these
> interop issues and saying that they should be taken care later.
> 
> > - So we should conclude that this procedure is working just fine in
> > real life deployments.
> > - We are proposing an enhanced use of this LDP hop-by-hop procedure
> > where compared with the above mechanism the PE-rs do not perform any
> > data plane function. Worthwhile to note for completion that VPLS Mesh
> > does not use LDP hop-by-hop anyhow.
> >
> > So in conclusion I think we need to close this thread too: there is
> no
> > scaling problem and the proposed mechanism will work even better than
> > in the MS-PW and HVPLS cases to address customer requirements for one
> > toolset in an MPLS E2E scenario.
> >
> > The rest is just academic discussion. I will try to address in-line
> > anything that resembles some scalability discussion just because I
> like
> > Ali. :)
> 
> And I like you - no hard feeling :-)
> 
> -Ali
> 
> > The rest we can continue as a discussion in IEEE.
> >
> > Florin