RE: Summary of debate RE: Merge MAC Withdraw Drafts?

["Ali Sajassi (sajassi)" <[e-mail]>]

Florin, you are making the same old argument as before "if LDP-flusing
ain't broken in VPLS, why cannot I use it for PBB-VPLS" but now you are
adding one new one and that is:

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

We need to differentiate between interoperability scenarios where e2e
encap is .1ah versus scenarios where .1ah encap is terminated in the
middle of the network. Example of the former case:

IB-BEB --- MSTP network ----- PE ---------- PE ---- MSTP network ---
IB-BEB
IB-BEB --- MSTP network ----- PE ---------- n-PE -- MPLS w/LDP -----
PBB-uPE
IB-BEB --- MSTP network ----- PE ---------- n-PE -- MPLS w/BGP -----
PBB-uPE
IB-BEB --- MSTP network ----- PE ---------- PE ---- G.8032 net -----
IB-BEB
IB-BEB --- G.8032 network --- PE ---------- PE ---- G.8032 net -----
IB-BEB
IB-BEB --- 802.1aq ---------- PE ---------- PBB-PE

And many more permutations. In all these cases, C-MAC flushing can be
done nicely and easily by native flush mechanism (MIRP).

Now, if there is no MAC-in-MAC encap, then as I mentioned before, the
flushing needs to be done by the scheme for that network - e.g., interop
between QinQ and G.8032, or VPLS and QinQ or etc. 

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

I explained the difference between B-MAC and C-MAC domains before.
Please refer to my previous emails as I don't like to repeat myself.
Whenever you have PBB encap (which is what we are talking here), then
MIRP makes perfect sense as below:

IB-BEB ----- MSTP network ------- PE ---- MPLS network ----- PE -----
G.8032 net --- IB-BEB

-Ali


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Balus, Florin Stelian (Florin)
> Sent: Monday, May 10, 2010 1:33 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Subject: Summary of debate RE: Merge MAC Withdraw Drafts?
> 
> 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