Subject: Re: Merge MAC Withdraw Drafts?

From: Raymond Key <[email-masked]>
Date: Wed, 05 May 2010 08:16:13 +1000

Support.
Raymond

> Shane Amante <[email-masked]> wrote:
> 
> 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---

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Wed, 5 May 2010 18:50:11 -0500

Hi Dave,
This is not only my situation... As you can see from the feedback on the list there are a number of people running into this "situation" in their networks.

Anyhow I think you missed the main point of my reply. In an MPLS only network, LDP MAC Flush is already in place for LDP VPLS and will not go away. Adding PBB-VPLS is supposed to be smooth and avoid changing the basic operational and protocol environment. So it makes sense to maintain here LDP MAC Flush and just add some additional TLV in the message to address PBB-VPLS transparently, using a proven tool.

Adding MIRP for PBB-VPLS will not address LDP VPLS and will not get rid of LDP MAC Flush in use anyhow for regular LDP VPLS. Adding MIRP will just create a second protocol and tool for doing the same thing that can be done with one in an MPLS only environment. Based on my experience and feedback on the list people see value in using one MPLS toolset for this use case (i.e. MPLS E2E). So I think we need to pursue this work in L2VPN.

Also whenever native PBB is deployed and people prefer to use native toolset across we just need to disable the LDP MAC Flush notification accordingly on the PEs. 
Regards,
Florin

> ----- Original Message -----
> From: David Allan I <[email-masked]>
> To: Balus, Florin Stelian (Florin); [email-masked] <[email-masked]>
> Cc: Shane Amante <[email-masked]>
> Sent: Wed May 05 18:05:18 2010
> Subject: RE: Merge MAC Withdraw Drafts?
> 
> Hi Florin:
> 
> I appreciate that is your situation today. What you have is a
> specialized solution that in the future will require you to negotiate
> what is the appropriate notification mechanism ....as it will be
> subtending topology dependent and hence the optimal flush mechanism
> will need to be agreed between individual pairs of Pes on the basis of
> failure type. Meanwhile if .1Qbe is considered you can establish a
> framework that covers the landscape now...as it will be independent of
> where the BEB functionality is placed in the network...
> 
> As yours is an individual draft not likely to hit standards track any
> time sooner than .1Qbe, what is the hurry?
> 
> Cheers
> D
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-
> lucent.com]
> Sent: Wednesday, May 05, 2010 6:43 PM
> To: David Allan I; [email-masked]
> Cc: Shane Amante
> Subject: RE: Merge MAC Withdraw Drafts?
> 
> David,
> 
> We have a number of LDP VPLS deployments that are using/are interested
> to use PBB-VPLS in an MPLS only environment. These deployments already
> use LDP MAC Flush for VPLS and prefer to keep using it for PBB-VPLS.
> There is no subtending native PBB domain so no issue with the proposed
> solution.
> 
> The LDP MAC Flush extensions proposed in draft-balus are designed to
> address the above scenarios. Whoever deploys a native PBB domain and
> whenever MIRP specification passes sponsor ballot in IEEE and gets
> implemented, one can choose to use it.
> 
> Florin
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of David Allan I
> > Sent: Wednesday, May 05, 2010 2:36 PM
> > To: Jiang Yuanlong; [email-masked]
> > Cc: Shane Amante
> > Subject: RE: Merge MAC Withdraw Drafts?
> >
> > I'm a bit confused....
> >
> > 802.1Qbe MIRP appears to be addressing the major headwound implied in
> > the PBB draft (which is an I-SID specific flush)...this is with a
> > modifcation to the existing MVRP/MMRP protocols for 802.1a
> >
> > It has the virtue that it can extend beyond a co-located PE/BEB for
> > the scenarios where there is a subtending PBBN and thus is a much
> more
> > general solution to the problem than what is confined to the LDP
> > control plane....
> >
> > I'm not sure that without better reason I would endorse pursuing a
> > solution largely limited to the complete absence of ethernet
> > networking. The subtending PBBN case should be considered.
> >
> > Cheers
> > D
> >
> > > Date: Mon, 3 May 2010 21:49:02 -0600
> > > From: Shane Amante <[email-masked]>
> > > Subject: Merge MAC Withdraw Drafts?
> > > To: [email-masked]
> > > Message-ID: <[email-masked]>
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > > Hi Everyone,
> > >
> > > WG
> > > draft: draft-ietf-l2vpn-vpls-ldp-mac-opt-01.  Please indicate
> > > whether or not you support merging the two drafts.
> > >
> > > 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:
> > >     draft-ietf-l2vpn-vpls-ldp-mac-opt-01 (LDP Extensions for
> > Optimized MAC
> > > ------------------------------

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 7 May 2010 17:42:37 -0700

Resending  because of large message size error

From: Ali Sajassi (sajassi) 
Sent: Friday, May 07, 2010 5:12 PM
To: 'Balus, Florin Stelian (Florin)'; Dutta, Pranjal K (Pranjal); Shane
Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

I would summarize it as follow: we got two options:

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 will 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, one more comment inline ...

 

From: Balus, Florin Stelian (Florin)
[mailto:[email-masked]] 
Sent: Friday, May 07, 2010 9:27 AM
To: Dutta, Pranjal K (Pranjal); Ali Sajassi (sajassi); Shane Amante;
[email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

I would summarize what Pranjal said here in the following way:

-          All the interop remarks below do not  apply since we never
said we are targeting any Native PBB-VPLS interop. Focusing on MPLS E2E
case.

-          The answer to the second point, inconsistency between
pbb-vpls-pe-model and draft-balus is not applicable - see Ali's
clarification below:

The inconsistency with draft-ietf-l2vpn-pbb-vpls-pe-model, is that as

mentioned above, the C-MACs are within the bridge module and therefore

their flushing should be governed by native Ethernet mechanism and

transparent to VPLS forwarder for a number of reasons and advantages

discussed in draft-sajassi-l2vpn-pbb-vpls-cmac-flush.

I challenge everybody to go in the draft-ietf-l2vpn-pbb-vpls-pe-model
and find the text Ali quotes: "should be governed by native Ethernet
mechanism".

Your challenge is met J Take a look at
draft-ietf-l2vpn-vpls-bridge-interop on which the modeling of PBB-VPLS
was based. It says:

   "This draft extends the PE model described in [RFC-4664] 

   based on IEEE 802.1ad bridge module, and illustrates a clear 

   demarcation between the IEEE bridge module and IETF LAN emulation 

   module. By doing so, it shows that the majority of interoperability 

   issues with CE bridges can be delegated to the 802.1ad bridge 

   module, thus removing the burden on the IETF LAN emulation module 

   within a VPLS PE."

-Ali

And even if the text was there last time I checked SHOULD does not mean
MUST.

I think we need to drop this email chain as irrelevant for the
discussion.