RE: Merge MAC Withdraw Drafts?

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

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.
- 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 asked you to highlight also any initiative targeted at fixing these mechanisms in L2VPN or PWE3 and you did not reply with anything either.
- 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. :)
The rest we can continue as a discussion in IEEE.

Florin

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:[e-mail]]
> Sent: Thursday, May 06, 2010 6:29 PM
> To: Balus, Florin Stelian (Florin); Shane Amante; [e-mail]
> Subject: RE: Merge MAC Withdraw Drafts?
>
> Florin,  Let's please concentrate on the substance ...
>
>
> > > a) C-MAC flushing is only needed for the edge PEs with I-components
> > [[FB]] Flushing is limited to the edge PEs in our proposal
> >
>
> Yes, but the difference is that in your proposal, the flush message is
> an out-of-band message traveling hop by hop through nodes that don't
> need to see them; whereas, in MIPR the flush message in an in-band
> Ethernet message passing through intermediate nodes as data. In current
> H-VPLS, there is a perfect reason for the flush message to be forwarded
> hop by hop since every nodes along the path needs to process such
> message.
>
>                PBB-uPE ------- n-PE ----------- n-PE -------- PBB-uPE
> LDP flush         X------------- X -------------- X ------------ X
> MIRP flush        X----------------------------------------------X
>
>
>
> > > b) PEs with B-components need NOT to be involved in passing this
> > > message
> > > hop by hop
> >
> > [[FB]] Again LDP MAC Flush and PW status using hop-by-hop propagation
> > in PE-rs and S-PEs (HVPLS and respectively MS-PWs) were standardized
> in
> > L2VPN and PWE3 and were implemented by a number of vendors including
> > some of your own products. They are running fine in deployments
> around
> > the world. Can you clarify what is the specific problem you saw in
> your
> > implementation/deployments with this approach?
> >
>
> As I mentioned before, in current H-VPLS deployment, there is a perfect
> reason for sending LDP MAC flush hop by hop since every node along the
> path operates on the same set of MAC addresses and thus every node
> along
> the path needs to flush. This is not the case for PBB-VPLS as only the
> C-MAC needs to be flushed and so there is no need to send the flush
> message hop by hop !!

[[FB]] Summarizing the lack of reply for specific field/implementation issues with LDP hop by hop procedures + what you are saying above:
a. you are not saying that the solution proposed in draft-balus will not work in real life deployments
b. you are saying that the MIRP solution which is just being standardized will work better based on analyzing one particular dimension and without any real deployments to support your claims

If you are "to educate" your MPLS customers to move to a second tool you need to do better than this: i.e. you need to show that the LDP hop-by-hop procedure is broken and will not work. That means they made a mistake deploying it for the HVPLS and MS-PW solutions you sold them.

>
> > > c) faster convergence resulting in shorter service interruption
> > > d) consistent with the PBB-VPLS model that you co-authored with me
> !!
> >
> > [[FB]] The above are unsubstantiated, generic claims that should not
> be
> > considered when judging the merging proposal in my opinion. Again
> there
> > are lots of MS-PWs and HVPLS deployments where hop-by-hop LDP
> > propagation runs just fine today. I did not see any work item in
> L2VPN
> > or PWE3 flagging the behavior as a problem.
> >
>
> Hopefully by now the argument for faster convergence should be very
> clear !! Also, the reason for having the PBB-VPLS model as we defined
> it
> is to make sure that we have a clear demarcation between IEEE bridging
> and IETF L2VPN protocols and such allow for transparent operation of
> IEEE protocols when needed over LAN emulation module. The flush message
> is a perfect example of it where the flush message that is initiated by
> bridge module can be passed transparently over LAN emulation module.
>
[[FB]] There is no native PBB domain in our use case - this discussion is out-of-scope...

> > >
> > > - LDP scheme is simpler than native one because the native scheme
> > > requires no fancy protocols and state-machine mechanisms of MRP (as
> I
> > > mentioned in my previous email).
> >
> > [[FB]] I don't see in my reply below any of these claims about "fancy
> > protocols and state machine". I believed indeed that the extension to
> > LDP MAC Flush is simple, implementable and deployable based on our
> > experience.
> >
>
> I didn't say that LDP implementation is fancy. I just said that the
> native flush message (MIRP) is very simple and doesn't require state
> machinery of MRP. It is as simple as sending a pre-canned message.
>
>
> > > It is as simple as building a
> > > pre-canned message and send this message within the L2VPN state
> > machine
> > > - and you should know that
> > > - MIRP involves certification and OSS changes - can you tell me how
> > > adding a simple message to existing L2VPN state machine requires
> > > certification and OSS changes but modifying LDP to do it, it
> doesn't
> > !!
> >
> > [[FB]] You seem to miss again the point here: there is no need to
> > introduce a new control plane, new sessions, no need for
> > reconfiguration or to change any operational model when introducing
> LDP
> > MAC Flush extensions - so no OSS changes. The required certification
> is
> > reduced to a minimal set. MIRP is a new control plane protocol the
> > operator needs to care about in his network and definitely involves
> > more OSS changes, certification and a learning curve. Why would
> > somebody running a VPLS/MPLS network do that when it can do it with
> one
> > tool?
> >
>
> I am wondering who has missed the real point :-) Do you call sending a
> simple pre-canned message a new control plane. Where does a new session
> or new reconfiguration or a change in operational model come from when
> MIRP is used? Have you looked at MIRP spec.? Basically the same info
> that can be encoded in a LDP message, is encoded in native Ethernet
> message. Thus transparent to network configuration and operation.
>
> > > Again, if there is a standard-based solution that is very simple to
> > > implement and:
> > >
> > >   - covers end-to-end MPLS deployments in better way
> > >   - covers any mixed of MPLS and PBB deployments
> > >   - gives faster convergence
> > >   - avoids future interoperability issues and writing more drafts
> > > !!
> >
> > [[FB]] There will always be LDP MAC Flush for regular VPLS, MIRP does
> > not address that space. Even for native Ethernet use cases there will
> > always be multiple MAC Flush mechanisms: ITU-T G.8032 has its own,
> > MSTP-based domains rely on TCN etc... Your goal of one solution
> > covering all of them is unrealistic as MIRP will not cover definitely
> > all native Ethernet cases. So it is not a reason not to proceed with
> > standardization of the LDP MAC Flush extensions.
> >
> I think you confusing B-MAC domain from C-MAC domain. MSTP and G.8032
> operates on B-MAC domain; whereas, MIRP operates on a C-MAC domain. So,
> yes, I can have a 802.1ah network running either MSTP or G.8032 and
> still have a single solution using MIRP which is the idea here :-)
> Also,
> all the points I made above still holds for end-to-end MPLS deployment
> so I still not repeat them again.
>
>
> > >
> > > Then, why do I need to go with a solution that cannot meet all of
> the
> > > above? If there are service providers who feel strongly about  your
> > > proposal, then I'd love to hear the reasoning behind it from them.
> I
> > > can
> > > see your eagerness for pushing a solution that your company has
> > > implemented but that's not the point here.
> >
> > [[FB]] This is again an unprofessional statement that should not be
> > used on this list. We have experience implementing MxRP to which we
> > actually contributed in IEEE.
>
> Previously you and I have discussed MVRP but not MIRP. MIRP is lot
> simpler than MVRP. Unfortunately the name is misleading because people
> get the impression that MIRP requires the same machinery as MVRP as you
> alluded when talking about new protocol with new session and new
> configuration, but that's not the case.
>
>
> -Ali
>
>
> > This is not about pushing one solution or
> > the other. This is about addressing specific customer needs.
> >
> > > The point is what is a
> > > better
> > > and more comprehensive solution.
> > >
> > > -Ali
> > >
> > >
> > > > -----Original Message-----
> > > > From: Balus, Florin Stelian (Florin)
> [mailto:florin.balus@alcatel-
> > > > lucent.com]
> > > > Sent: Thursday, May 06, 2010 12:13 PM
> > > > To: Ali Sajassi (sajassi); Shane Amante; [e-mail]
> > > > Subject: RE: Merge MAC Withdraw Drafts?
> > > >
> > > >
> > > > You seem to ignore on purpose a point we made on the scope of
> this
> > > > draft in a number of IETF sessions: it addresses environments
> where
> > > > VPLS/MPLS is deployed end-to-end with LDP MAC Flush already in
> use.
> > > > Again there is no Native Ethernet interop issue as there is no
> > Native
> > > > PBB domain in these use cases.
> > > >
> > > > There are a lot of deployments like this around the world where
> it
> > is
> > > > much simpler to add a TLV to the LDP MAC Flush message which will
> > > > provide transparently support for PBB-VPLS. Versus introducing a
> > > second
> > > > protocol (MIRP) in the network for PBB-VPLS with all the IT
> > > > certification and OSS changes involved.
> > > >
> > > > As you saw on the list there is a lot of support from the
> operators
> > > > side so we are addressing a real issue they face in their
> networks.
> > > > Also I do not think the argument you used in Anaheim about the
> > "lack
> > > of
> > > > education on the customer side" applies here: as you say below
> you
> > > had
> > > > a lot of opportunities in the last "couple of years" to educate
> > them
> > > > while presenting and arguing for your draft on CMAC flush in a
> > number
> > > > of IETF sessions.
> > > >
> > > > See also in-line...
> > > >
> > > > > -----Original Message-----
> > > > > From: [e-mail] [mailto:[e-mail]] On
> > > > Behalf
> > > > > Of Ali Sajassi (sajassi)
> > > > > Sent: Wednesday, May 05, 2010 5:07 PM
> > > > > To: Shane Amante; [e-mail]
> > > > > Subject: RE: Merge MAC Withdraw Drafts?
> > > > >
> > > > >
> > > > > During the Anaheim meeting I objected to the merge of these two
> > > > drafts
> > > > > because they are apples and oranges and they will create
> > > > > inter-operability issues down the road.
> > > >
> > > > FB> The two drafts are complementary and represent enhancements
> to
> > > > existing LDP MAC Flush mechanisms to address VPLS solution in
> scope
> > > for
> > > > L2VPN WG. We could have gone down the path of just moving draft-
> > balus
> > > > to WG status but discussing with people in Anaheim it seemed
> there
> > is
> > > > value in grouping the rather small changes in one draft to make
> it
> > > > easier to follow and implement in one shot enhancements related
> to
> > a
> > > > common tool.
> > > >
> > > > > Couple of years ago, I
> > > > > introduced a draft (draft-sajassi-l2vpn-pbb-vpls-cmac-flush)
> that
> > > > > discussed the issues and why this CMAC flushing in context of
> > pbb-
> > > > vpls
> > > > > is different from mac-flushing in regular VPLS. The draft
> > > recommended
> > > > > the flushing to be done in native Ethernet mode because of
> number
> > > of
> > > > > reasons:
> > > > >
> > > > > - Fast convergence since the "flush" message is passed through
> > > > > intermediate devices as data
> > > > > - Transparent to all devices operating on B-MAC addresses
> (e.g.,
> > > all
> > > > > intermediate devices)
> > > > > - Applies equally well for both intra and inter I-SID domains
> > > > > - No interworking is required when this message is initiated
> from
> > > > > native
> > > > > 802.1ah network or MPLS access with 802.1ah functionality
> > > > >
> > > > > Interestingly, the draft-sajassi-l2vpn-pbb-vpls-cmac-flush
> > provided
> > > > the
> > > > > ground work for 802.1Qbe which is going through last stage of
> > > > > ratification. So, the question is if a more comprehensive
> > solution
> > > > > exists, then why do we need a sub-par solution to do the same
> > > thing?
> > > >
> > > > FB> You seem to use a lot of generic statements not backed up by
> > > > arguments. Specifically you imply with your generic statement
> "sub-
> > > par
> > > > solution" there is an issue with the current LDP MAC Flush and I
> > > think
> > > > in the past you mentioned scalability.
> > > >
> > > > LDP MAC Flush was used in all the H-VPLS deployments for the last
> > 5-6
> > > > years with a lot of success - see the steep VPLS adoption curve.
> > PE-
> > > rs
> > > > are propagating regular MAC Flush between MTU-s and performing
> > local
> > > > MAC Flush in their data plane. LDP was also standardized and is
> > used
> > > > similarly for propagating PW status through the S-PEs in MS-PW
> > > > deployments around the world.
> > > >
> > > > The LDP MAC Flush extension we propose for PBB-VPLS actually
> > improves
> > > > significantly on both regular LDP MAC Flush and PW Status
> > > propagation:
> > > > the PE-rs just passes the FEC(s) and PBB TLV to the interested
> PEs,
> > > > without any data plane action (MAC Flush) in the PE-rs. Which is
> > not
> > > > the case for regular LDP MAC Flush and PW Status. It also
> > aggregates
> > > in
> > > > one LDP message MAC Flush indication for multiple services.
> > > >
> > > > Based on this we expect a lot of scalability improvements for
> PBB-
> > > VPLS
> > > > so I do not see any reason for your statement. Unless you believe
> > > there
> > > > is a problem with LDP message propagation in the other solution
> in
> > > > which case you need to start pushing back on the "subpar
> solutions"
> > > > PWE3 and MPLS WG developed! :)
> > > >
> > > > >
> > > > > It should be noted that draft-balus-l2vpn-pbb-ldp-ext does NOT
> > > > satisfy
> > > > > some of the interoperability scenarios specified in
> > > > > draft-ietf-l2vpn-pbb-vpls-interop whereas .1Qbe can satisfy all
> > the
> > > > > interop scenarios.
> > > >
> > > > FB> See the first part of my email: our main focus is the MPLS
> use
> > > case
> > > > so the above objection does not apply as there is no interop
> > between
> > > > native PBB and MPLS domain.
> > > >
> > > > >
> > > > > Furthermore, draft-balus-l2vpn-pbb-ldp-ext is inconsistent (and
> > > even
> > > > in
> > > > > conflict) with the pbb-vpls model described in
> > > > > draft-ietf-l2vpn-pbb-vpls-pe-model.
> > > >
> > > > FB> Please refrain from generic statements just for the sake of
> > > > arguing. I am one of the editors for the above draft and LDP MAC
> > > Flush
> > > > extension for PBB-VPLS was developed in line with the PBB-VPLS PE
> > > > model.
> > > >
> > > > >
> > > > > Before, moving any further on this draft, I'd like for these
> > issues
> > > > to
> > > > > be resolved.
> > > >
> > > > FB> I think we addressed your (same) comments/objections a number
> > of
> > > > times in the past. You seem to bring them up anyhow again and
> again
> > > so
> > > > I think it is ok sometimes to agree to disagree and to move ahead
> > > based
> > > > on WG majority.
> > > >
> > > > >
> > > > > Regards,
> > > > > Ali
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:[e-mail]]
> On
> > > > > Behalf
> > > > > > Of Shane Amante
> > > > > > Sent: Monday, May 03, 2010 8:49 PM
> > > > > > To: [e-mail]
> > > > > > Subject: Merge MAC Withdraw Drafts?
> > > > > >
> > > > > > Hi Everyone,
> > > > > >
> > > > > > At the last IETF meeting in Anaheim, there was good consensus
> > in
> > > > the
> > > > > > room to merge the following two drafts in order to have a
> > single
> > > > > > specification that covered all LDP-based MAC Withdraw
> > procedures
> > > in
> > > > a
> > > > > > single place.  Here are the two drafts:
> > > > > >
> http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-01
> > > > > > http://tools.ietf.org/html/draft-balus-l2vpn-pbb-ldp-ext-02
> > > > > >
> > > > > > We would like to reaffirm consensus on the mailing list that
> it
> > > is
> > > > > > acceptable to merge draft-balus-l2vpn-pbb-ldp-ext-02 into the
> > > > > existing
> > > > > > WG draft: draft-ietf-l2vpn-vpls-ldp-mac-opt-01.  Please
> > indicate
> > > > > > whether or not you support merging the two drafts.
> > > > > >
> > > > > >
> > > > > > We will close this call in 2 weeks on Friday, May 14, at COB.
> > > > > >
> > > > > > Giles & Shane
> > > > > >
> > > > > > P.S. -- Here is a snippet of the notes related to this draft
> > that
> > > I
> > > > > > sent out to the WG mailing list back on 4/4/2010:
> > > > > > http://www.ietf.org/mail-
> > archive/web/l2vpn/current/msg02280.html
> > > > > > ---snip---
> > > > > > 4)  Extensions to LDP MAC Withdraw for PBB-VPLS:
> > > > > >    - draft-balus-l2vpn-pbb-ldp-ext-02
> > > > > >      + Addressed previous comments on existing draft.
> > > > > >      + Co-authors suggested merging the above draft with
> > > > > >      draft-ietf-l2vpn-vpls-ldp-mac-opt-01 (LDP Extensions for
> > > > > Optimized
> > > > > > MAC
> > > > > >      Withdrawl in H-VPLS), in order to have a single
> > consolidated
> > > > > > document
> > > > > >      that covers all optimized LDP Extensions for Optimized
> MAC
> > > > > > withdrawl
> > > > > >      for all underlying Ethernet technologies.
> > > > > >      + There were 10 people @ WG meeting that agreed to merge
> > the
> > > > two
> > > > > > drafts,
> > > > > >      and 1 objection.
> > > > > >      + Co-chairs to follow-up with call on WG mailing list to
> > > merge
> > > > > >      the two drafts together before next IETF.
> > > > > > ---snip---