RE: Merge MAC Withdraw Drafts?

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

Florin,

Although, we can take a short-sighted view of just addressing E2E MPLS
and interop of MPLS with other networks is outside the scope and it is
not "my problem", that will create lot more issues down the road and
create more hassles for the operators and that's why in L2VPN WG we
spent some cycles to look at such interop issues and see how we can
alleviate/eliminate the burden of such work in L2VPN WG. That was the
purpose of the following drafts:

	- draft-ietf-l2vpn-vpls-bridge-interop
	- draft-ietf-l2vpn-pbb-vpls-pe-model
	- draft-ietf-l2vpn-pbb-vpls-interop

So, if we have an option to eliminate interop issue versus creating one,
I opt for the former.

-Ali

> -----Original Message-----
> From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-
> lucent.com]
> Sent: Friday, May 07, 2010 9:15 AM
> To: Ali Sajassi (sajassi); David Allan I; Henderickx, Wim (Wim); Shane
> Amante; [e-mail]
> Subject: RE: Merge MAC Withdraw Drafts?
> 
> 
> Ali,
> 
> Where in my email you see anything of this sort? My text is right
> underneath your reply, it's not two replies back.
> 
> This discussion thread anyhow was outside of the scope of draft-balus
> and the subject of this email anyhow.
> We are focusing in draft-balus on the MPLS E2E case and I never said
> people should not use for native PBB MIRP if they like it.
> 
> I just said that before asking L2VPN WG for a common toolset for
> interoperability scenario between native Ethernet and MPLS we should
> consider the following:
> - There are also lots of QinQ deployments that should be also
> considered
> - There are a lot of protocols developed outside L2VPN WG, in
different
> SDOs - see ITU-T G.8032 and IEEE 802.1aq examples - all of them
> developing their own MAC Flush procedures.
> 
> What I suggested in my email is that L2VPN might not be the right
place
> to develop the common solution. Also even assuming we manage to find a
> way in other SDO to start the work, it will take a long time to sync
up
> SDOs, to develop and the final result in my opinion will not be based
> on MIRP spec who's covering just the PBBN space.
> 
> Florin
> 
> > -----Original Message-----
> > From: Ali Sajassi (sajassi) [mailto:[e-mail]]
> > Sent: Thursday, May 06, 2010 10:27 PM
> > To: Balus, Florin Stelian (Florin); David Allan I; Henderickx, Wim
> > (Wim); Shane Amante; [e-mail]
> > Subject: RE: Merge MAC Withdraw Drafts?
> >
> >
> > Florin,
> >
> > We need to make a distinction between B-MAC domain and C-MAC domain
> and
> > that the flushing mechanism needed for each is independent as I
> > mentioned in my previous emails. PBB encapsulation can be used in a
> > number of different networks and the flushing for B-MAC addresses
are
> > governed by that network's protocol type but that is completely
> > independent from C-MAC address flushing, for example:
> >
> >       - PBB with MSTP uses TCN for B-MAC flush
> >       - PBB with VPLS uses LDP for B-MAC flush
> >       - PBB with G.8032 uses R-APS for B-MAC flush
> >       - PBB with 802.1aq doesn't use one
> >
> > However, in all the above cases MIRP can be and should be used for
C-
> > MAC
> > flushing.
> >
> > Are you suggesting that we come up with
> >       - N number of protocol extensions - one for each network type
> > an
> >       - N! (factorial) number of interoperability specs
> >
> > instead of having just a single simple protocol that works across
all
> > these network types?
> >
> > -Ali
> >
> >
> >
> > > -----Original Message-----
> > > From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-
> > > lucent.com]
> > > Sent: Thursday, May 06, 2010 3:04 PM
> > > To: David Allan I; Henderickx, Wim (Wim); Ali Sajassi (sajassi);
> > Shane
> > > Amante; [e-mail]
> > > Subject: RE: Merge MAC Withdraw Drafts?
> > >
> > > Hi Dave,
> > >
> > > I do not think the all encompassing solution is in L2VPN WG scope
> and
> > > definitely it should not gate the solution needed for the MPLS use
> > > cases.
> > >
> > > Also the whole discussion around MIRP being the common tool misses
> an
> > > important point. The native Ethernet space is not just about PBBN.
> In
> > > fact there are more existing QinQ deployments than PBBNs.
xSTP/ITU-
> T
> > > G.8032/IEEE 802.1aq are technologies that are/may be deployed in
> > these
> > > QinQ domains, each of them with their own MAC Flush procedures.
> None
> > of
> > > these specifications are waiting for the ideal one solution
> covering
> > > all use cases.
> > >
> > > Florin
> > >
> > > > -----Original Message-----
> > > > From: David Allan I [mailto:[e-mail]]
> > > > Sent: Thursday, May 06, 2010 2:33 PM
> > > > To: Henderickx, Wim (Wim); Balus, Florin Stelian (Florin); Ali
> > > Sajassi
> > > > (sajassi); Shane Amante; [e-mail]
> > > > Subject: RE: Merge MAC Withdraw Drafts?
> > > >
> > > > Hi Wim:
> > > >
> > > > OK, then we are on track to produce something that is not IEEE,
> it
> > is
> > > > purely (a rather bloated) encapsulation...
> > > >
> > > > If we are to acknowldege that subtending PBBN networks be it
> G.8032
> > > > based, 802.1aq based, (I'll not mention RSTP), MC-LAG subtending
> > etc.
> > > > then we need a better solution. I do not see a way around
this...
> > > >
> > > > Some kind of framework for when the PE is a BCB and can have
> > > arbitrary
> > > > topology subtending is called for. I can see the utility of MAC
> > flush
> > > > across a number of subtending scenarios, where one wants to
limit
> > the
> > > > scope of a TCN into Ethernet.
> > > >
> > > > Right now it appears that we're not going to try to solve the
> > general
> > > > case purely as matter of convenience...
> > > >
> > > > D
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > > > Of Henderickx, Wim (Wim)
> > > > Sent: Thursday, May 06, 2010 3:25 PM
> > > > To: Balus, Florin Stelian (Florin); Ali Sajassi (sajassi); Shane
> > > > Amante; [e-mail]
> > > > Subject: RE: Merge MAC Withdraw Drafts?
> > > >
> > > > I agree with Florin here, since this solution is targeted for
> MPLS
> > > > deployments where interoperability  does not exist. In case of
> > > interop
> > > > issues with native Ethernet PBB we probably need a new draft to
> > > address
> > > > this.
> > > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> > > Behalf
> > > > Of Balus, Florin Stelian (Florin)
> > > > Sent: donderdag 6 mei 2010 21:13
> > > > 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---