Subject: Merge MAC Withdraw Drafts?

From: Shane Amante <[email-masked]>
Date: Mon, 3 May 2010 21:49:02 -0600

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: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 4 May 2010 06:51:01 +0200

I support merging the 2 drafts

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: dinsdag 4 mei 2010 5:49
To: [email-masked]
Subject: Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Tue, 4 May 2010 10:23:28 +0200

I support merging these 2 drafts.

Marc

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Shane Amante
Envoyé : mardi 4 mai 2010 05:49
À : [email-masked]
Objet : Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

---

From: <[email-masked]>
Date: Tue, 4 May 2010 11:40:13 +0200

I support merging the two drafts.

Regards,
Manuel

> Sent: Tuesday, May 04, 2010 5:49 AM
> To: [email-masked]
> 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:
> 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.  
> 
> 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:

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 4 May 2010 06:42:31 -0400

+1

---

From: Himanshu Shah <[email-masked]>
Date: Tue, 4 May 2010 03:46:38 -0700

Support.
/himanshu

On 5/3/10 11:49 PM, "Shane Amante" <[email-masked]> wrote:

Hi Everyone,

Giles & Shane

---snip---

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Tue, 4 May 2010 12:48:26 +0200

I support the merging.
Thx

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: martes, 04 de mayo de 2010 5:49
To: [email-masked]
Subject: Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

---

From: "Fragassi, Roberto (Roberto)" <[email-masked]>
Date: Tue, 4 May 2010 06:49:41 -0500

Support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Monday, May 03, 2010 11:49 PM
To: [email-masked]
Subject: Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

---

From: "William Zayas" <[email-masked]>
Date: Tue, 4 May 2010 08:23:01 -0400

Support.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fragassi, Roberto (Roberto)
Sent: Tuesday, May 04, 2010 7:50 AM
To: Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shane Amante
Sent: Monday, May 03, 2010 11:49 PM
To: [email-masked]
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.  

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---
     + There were 10 people @ WG meeting that agreed to merge the two
drafts,
---snip---

---

From: Olen Stokes <[email-masked]>
Date: Tue, 4 May 2010 05:32:04 -0700

Support.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Monday, May 03, 2010 11:49 PM
To: [email-masked]
Subject: Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

---

From: "Aissaoui, Mustapha (Mustapha)" <[email-masked]>
Date: Tue, 4 May 2010 08:32:47 -0500

Support.

Mustapha.

---

From: "Mallette, Edwin" <[email-masked]>
Date: Tue, 4 May 2010 09:38:11 -0400

Support.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Monday, May 03, 2010 11:49 PM
To: [email-masked]
Subject: Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.

---

From: Yong Lucy <[email-masked]>
Date: Tue, 04 May 2010 09:14:08 -0500

+1

> Sent: Monday, May 03, 2010 10:49 PM
> To: [email-masked]
> 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:
> 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:

---

From: "Seaton, Mark" <[email-masked]>
Date: Tue, 4 May 2010 15:16:16 +0100

Could someone tell me how I unsubscribe from this email alis? 

Many Thanks 
Mark Seaton GCS
office +44-208-591-1075
Mobile +44 7802 461446
 
AT&T ISTEL Registered office: 
Highfield House, 
Headless Cross Drive, 
Redditch, 
Worcestershire B97 5EQ 
Registered in England: No. 3531467
This message and any attachments to it contain confidential business information intended solely for the recipients. If you have received this e-mail in error please do not forward or distribute it to anyone else, but telephone (+44 2085911075) to report the error, and then delete this message from your system.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yong Lucy
Sent: 04 May 2010 15:14
To: 'Shane Amante'; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

+1

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Tue, 4 May 2010 10:18:20 -0500

Support.

> Sent: Monday, May 03, 2010 8:49 PM
> To: [email-masked]
> 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:
> 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
> 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:

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 04 May 2010 10:34:40 -0500

Support 

Linda Dunbar

-----Original Message-----

Hi Everyone,

Giles & Shane

---snip---

---

From: "Delregno, Christopher N (Nick DelRegno)" <[email-masked]>
Date: Tue, 04 May 2010 15:49:19 +0000

Shane:

I support merging these drafts.

Thanks,
Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: Monday, May 03, 2010 10:49 PM
To: [email-masked]
Subject: Merge MAC Withdraw Drafts?

Hi Everyone,

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.  

Giles & Shane

---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: Simon Delord <[email-masked]>
Date: Wed, 5 May 2010 08:55:21 +1000

Support,

Simon

2010/5/4 Shane Amante <[email-masked]>

> that covered all LDP-based MAC Withdraw procedures in a single place.  Here
> are the two drafts:

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 5 May 2010 08:14:07 +0530

Support.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Monday, May 03, 2010 8:49 PM
To: [email-masked]
Subject: Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 5 May 2010 17:06:33 -0700

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

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.

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. 

Before, moving any further on this draft, I'd like for these issues to
be resolved.

Regards,
Ali

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 6 May 2010 08:51:05 +0530

Hi Ali,
         Please refer inline a few comments.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Wednesday, May 05, 2010 5:07 PM
To: Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

[Pranjal] Are we saying that we will deploy two different MAC flush
          solutions, one for existing "vanilla" VPLS part and another 
          For CMAC Flush? Or are we saying that we need to wipe out 
          existing LDP VPLS mac flush implementations?

[Pranjal] Didn't get exactly. Can you please provide reference to 
          the relevant sections in draft-ietf-l2vpn-pbb-vpls-interop 
          where we think draft-balus-l2vpn-pbb-ldp-ext brings conflict. 
          That would be helpful for further discussions in the list.

[Pranjal] It would help if you can explain in what way it's consistent.

Regards,
Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 6 May 2010 11:51:02 -0700

Hi Pranjal,

Please refer to my comments inline ...

But let me emphasize the interop issue here a bit more. We know the only
way to do C-MAC flushing in PBB network is via .1Qbe, by doing yet
another mechanism without clear advantage, then how are we going to
interoperate between PBB & MPLS access networks? Now, are we going to
create more work for ourselves and come up yet with another
interoperability spec? If the native Ethernet mechanism required a
complex protocol (or even a moderate protocol), then I would have agreed
that it is better to piggy back this C-MAC flush mechanism over existing
LDP MAC withdraw. However, that's not the case and the native Ethernet
mechanism is as simple as building a pre-canned message and transmitting
it - e.g., no MRP state-machine is required for the native mechanism.

>           For CMAC Flush? 

Yes, that's what I am saying. In PBB-VPLS model per figure-2 of
draft-ietf-l2vpn-pbb-vpls-pe-model, C-MACs sits in the bridge module
entirely (in the I-comp of bridge module being more precise) and VPLS
forwarders are completely transparent to these C-MCAS because they
operate on B-MACs. One of the main reason for doing this model was to
simplify our life and try not to reinvent the wheel unnecessarily. If
there is a good reason to reinvent the wheel, then I am O.K. with it but
that's not the case here.

>           That would be helpful for further discussions in the list.

It LDP-based C-MAC scheme cannot be used in the following scenarios: 
	- section 4.2 
	- section 4.3
	- section 5.1
	- section 5.2
	- section 6.1 (w/ mixed of both MPLS & PBB access networks)
	- section 7.2 & 7.3 (w/ mixed of both MPLS & PBB access
networks)

> [Pranjal] It would help if you can explain in what way it's
consistent.

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.

Cheers,
Ali

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Thu, 6 May 2010 14:12:59 -0500

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

> Of Ali Sajassi (sajassi)
> 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

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! :) 

> draft-ietf-l2vpn-pbb-vpls-interop whereas .1Qbe can satisfy all the

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. 

> 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

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.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 6 May 2010 21:25:12 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Balus, Florin Stelian (Florin)
Sent: donderdag 6 mei 2010 21:13
To: Ali Sajassi (sajassi); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

See also in-line...

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 6 May 2010 13:14:40 -0700

Even in case of end-to-end MPLS deployments, the simple native Ethernet
mechanism for C-MAC flushing works much better than your proposal for
LDP-based because:

a) C-MAC flushing is only needed for the edge PEs with I-components
b) PEs with B-components need NOT to be involved in passing this message
hop by hop
c) faster convergence resulting in shorter service interruption
d) consistent with the PBB-VPLS model that you co-authored with me !!

So, please don't muddy the water here and make non-substantiative claims
such as: 

- 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). 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 !!
- Regarding lots of support, yes I saw lots of support from your
colleagues !! If needed I can arrange for lots of support on my side but
people know that I don't play this type of game !! and I rely on sound
technical arguments

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

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. The point is what is a better
and more comprehensive solution. 

-Ali

> From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-
> lucent.com]
> Sent: Thursday, May 06, 2010 12:13 PM
> 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...
> 
> 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
> 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! :)
> 
> >
> 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.
> 
> >
> 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.
> 
> >
> 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.
> > > specification that covered all LDP-based MAC Withdraw procedures
in
> a

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 6 May 2010 13:18:08 -0700

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

The point is that if we implement the simple native mechanism (MIRP),
then we don't need to do anything else and it works for all scenarios
but if we do LDP-based mechanism, then we need to do:

a) implement MIRP anyway
b) implement interop between the two !!

Now which one is more desirable :-)

-Ali

> Of Balus, Florin Stelian (Florin)
second
of
for
in
there
case
based
in

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Thu, 6 May 2010 16:15:22 -0500

You keep bringing same arguments again instead of answering my initial replies. 

> people know that I don't play this type of game !! and I rely on sound

There were 5 people from different vendors and 5 from different operators who expressed support for merging the draft on the L2VPN list. Everyone of them making up their mind on their own! How can you make these statements? Generic statements in your initial email do not qualify also as technical arguments.

See in-line...

> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 1:15 PM
> To: Balus, Florin Stelian (Florin); Shane Amante; [email-masked]
[[FB]] Flushing is limited to the edge PEs in our proposal

> b) PEs with B-components need NOT to be involved in passing this

[[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? 

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

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

> It is as simple as building a

[[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? 

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

> 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. This is not about pushing one solution or the other. This is about addressing specific customer needs.
 
> The point is what is a
> better
> > > Furthermore, draft-balus-l2vpn-pbb-ldp-ext is inconsistent (and
> even
> > in

---

From: David Allan I <[email-masked]>
Date: Thu, 6 May 2010 17:33:01 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Balus, Florin Stelian (Florin)
Sent: donderdag 6 mei 2010 21:13
To: Ali Sajassi (sajassi); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

See also in-line...

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

> > specification that covered all LDP-based MAC Withdraw procedures in 
> > a single place.  Here are the two drafts:

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Thu, 6 May 2010 17:03:57 -0500

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

> From: David Allan I [mailto:[email-masked]]
> Sent: Thursday, May 06, 2010 2:33 PM
> To: Henderickx, Wim (Wim); Balus, Florin Stelian (Florin); Ali Sajassi
> (sajassi); Shane Amante; [email-masked]
> 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.
> 
> Of Henderickx, Wim (Wim)
> issues with native Ethernet PBB we probably need a new draft to address
> this.
> 
> provide transparently support for PBB-VPLS. Versus introducing a second
> Also I do not think the argument you used in Anaheim about the "lack of
> existing LDP MAC Flush mechanisms to address VPLS solution in scope for
> the case for regular LDP MAC Flush and PW Status. It also aggregates in
> so I do not see any reason for your statement. Unless you believe there
> FB> See the first part of my email: our main focus is the MPLS use case
> I think it is ok sometimes to agree to disagree and to move ahead based
> on WG majority.
> 
> >
> > Regards,
> > Ali
> >

---

From: David Allan I <[email-masked]>
Date: Thu, 6 May 2010 18:29:04 -0400

Hi Florin:

I don't believe there is **one solution**, what needs to be withdrawn or flushed is context dependent. Hence what I'd like to see is some means of knowing the context a PE finds itself in so the "right" thing can be done....

At this point I'm not sure if a PE can self elect the procedure it would use, or needs knowledge of the peer at the other end of the PW. Right now you've simplified the problem by only addressing one context (both Pes are also BEBs)

D 

-----Original Message-----
From: Balus, Florin Stelian (Florin) [mailto:[email-masked]] 
Sent: Thursday, May 06, 2010 6:04 PM
To: David Allan I; Henderickx, Wim (Wim); Ali Sajassi (sajassi); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Dave,

Florin

> address this.
> second protocol (MIRP) in the network for PBB-VPLS with all the IT 
> 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...
> 
> 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
> > 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:
> >
> in one LDP message MAC Flush indication for multiple services.
> 
> 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"
> FB> case
> based on WG majority.
> > > in a single place.  Here are 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:

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Thu, 6 May 2010 18:23:38 -0500

Hi Dave,

If you are talking about a native Ethernet domain connected as an access to the PE-BEB device we would just use mapping between native Ethernet domain the same way we did for QinQ-PE case. There could be flags used at system level or per VPLS to control whether to map or let the native Ethernet mechanism go through.

If you are talking about the MPLS PE space there are two aspects that can be considered:
- how the upgraded PEs know whether it is a CMAC flush or a BMAC Flush? This is based on the presence of the PBB-TLV in the LDP MAC Withdraw message. Or one can use a flag in the flag vector we proposed in the draft. We are open to discuss about the most appropriate procedure.
 
- (old PEs)-(upgraded-PEs) interaction? The worst that can happen is that the old BEB-PE will perform a non-optimized flushing which was in place before the upgrade. Not sure we need to negotiate capabilities; something we can include in the draft if the WG feels strongly about it. 

Florin
 
> Sent: Thursday, May 06, 2010 3:29 PM
> To: Balus, Florin Stelian (Florin); Henderickx, Wim (Wim); Ali Sajassi
> I don't believe there is **one solution**, what needs to be withdrawn
> or flushed is context dependent. Hence what I'd like to see is some
> means of knowing the context a PE finds itself in so the "right" thing
> can be done....
> 
> At this point I'm not sure if a PE can self elect the procedure it
> would use, or needs knowledge of the peer at the other end of the PW.
> Right now you've simplified the problem by only addressing one context
> (both Pes are also BEBs)
> 
> D
> 
> 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
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 6 May 2010 18:28:51 -0700

Florin,  Let's please concentrate on the substance ... 

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

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

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

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

> [[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
> > > > discussed the issues and why this CMAC flushing in context of
> pbb-
> > > vpls
> > recommended
> > > > the flushing to be done in native Ethernet mode because of
number
> > > > native
> > > the
> > > arguments. Specifically you imply with your generic statement
"sub-
> > par
> > > years with a lot of success - see the steep VPLS adoption curve.
> PE-
> > rs
> > > > Before, moving any further on this draft, I'd like for these
> issues
> > > to
> > > > be resolved.
> > >
> > > times in the past. You seem to bring them up anyhow again and
again
> > so
> > > > > From: [email-masked] [mailto:[email-masked]]
On
> > > > Behalf
> > > the
> > > > > We would like to reaffirm consensus on the mailing list that
it
> > is
> that
> > I
> > > > >      + There were 10 people @ WG meeting that agreed to merge
> the
> > > two
> > > > > drafts,
> > > > >      and 1 objection.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 6 May 2010 22:27:10 -0700

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
and
	- N! (factorial) number of interoperability specs

instead of having just a single simple protocol that works across all
these network types?

-Ali 

> Sent: Thursday, May 06, 2010 3:04 PM
> > Right now it appears that we're not going to try to solve the
general
> > case purely as matter of convenience...
> >
> > D
> >
issues
that
the
> > > > two drafts,

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 7 May 2010 07:58:06 +0200

David,

The drafts are addressing the scenario where LDP MAC flush is already enabled for VPLS. When those service providers enable PBB-VPLS in this environment there is an easy extension to the LDP MAC flush procedures described in draft-balus-l2vpn-pbb-ldp-ext-02 to support PBB-VPLS dual homing scenario's.
Those service providers are not going to enable another MAC flush mechanism for PBB-VPLS other than the once for normal VPLS. Hence the support from these service providers to do this.

Now back to the original question to the WG. The question is to combine the different Mac flush drafts together.
- draft-ietf-l2vpn-vpls-ldp-mac-opt-01 is already WG adopted and it makes a lot of sense to extend this draft and include the procedure from draft-balus-l2vpn-pbb-ldp-ext-02.
As such there is one draft describing the procedures for the different use cases using LDP MAC procedures for regular VPLS and PBB-VPLS.

Cheers,
Wim

-----Original Message-----
From: David Allan I [mailto:[email-masked]] 
Sent: vrijdag 7 mei 2010 0:29
To: Balus, Florin Stelian (Florin); Henderickx, Wim (Wim); Ali Sajassi (sajassi); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Florin:

D 

-----Original Message-----
From: Balus, Florin Stelian (Florin) [mailto:[email-masked]] 
Sent: Thursday, May 06, 2010 6:04 PM
To: David Allan I; Henderickx, Wim (Wim); Ali Sajassi (sajassi); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Dave,

Florin

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 7 May 2010 21:27:31 +0530

Hi Ali,

         Please refer my responses inline in blue.

Thanks,

Pranjal

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Thursday, May 06, 2010 11:51 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Pranjal,

[Pranjal] IMO, the question here is not about C-MAC Flushing in native PBB
          network via .1Qbe. In PBB-VPLS PE model (draft-ietf-l2vpn-pbb-vpls-pe)
          we have extended the *existing* VPLS bridge Module (aka VSI) with I/B
          components for service scalability and MAC table scalability. In PBB-VPLS

          PE, the RFC 4762 LDP MAC Flush is already in place. Now regarding the

          question on how we are going to inter-op with PBB access networks -

          the PBB-VPLS PE model doesn't necessitate the presence on a PBB access

          networks. So the question should be other way around - are we going to

          invent something new in RFC 4762 deployments for each access network

          requirement. So in draft-balus-pbb-ldp-ext we are not coining something
          new or re-inventing the wheel and just piggybacking PBB specific info in
          LDP MAC Flush. Using existing LDP based approach is generic and can be
          extended for future applications as well. We don't need run each native
          ethernet protocol in core. Neither we are ruling out that fact the

          native ethernet protocols can't be run between C-MAC components.

[Pranjal] I would probably disagree with this point. In implementations

no such strict separation exists although we place a separate building

block to describe components/functionalities involved such as VPLS

forwarders, CMAC bridging etc. From packet flow perspective, yes I agree

that components are dis-joint but not from control plane perspective

towards the core. The same PE box that has CMAC component also has full
fledged RFC 4762 and LDP implementation already.  Secondly, it's not always
necessary that there is a native PBB network towards CE.

Here is what I read from section 5. Control plane in

   The existing control plane procedures described in [L2VPN-Sig<http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-vpls-pe-model-01#ref-L2VPN-Sig#ref-L2VPN-Sig>] and

   [RFC4762<http://tools.ietf.org/html/rfc4762>] can be re-used in a PBB-VPLS to setup the PW infrastructure

   in the service provider and/or customer bridging space. This allows

   porting the existing control plane procedures (e.g. BGP-AD, PW setup,

   VPLS MAC Flush, PW OAM) for each domain.

So I don't see where we have the conflict between
draft-ietf-l2vpn-pbb-vpls-pe-model and draft-balus-pbb-ldp-ext.
Towards VPLS/Core we would want only one generic protocol catering to
all requirements of MAC Flush. It makes implementations lot simpler from
deployment perspectiive. As mentioned by others in the thread - existing
LDP MAC flush is a proven and simple mechanism being deployed in RFC 4762
deployments for several years. draft-balus-pbb-ldp-ext exactly complies
with Section 5. in draft-ietf-l2vpn-pbb-vpls.

>           where we think draft-balus-l2vpn-pbb-ldp-ext brings

conflict.

-       section 4.2

[Pranjal] I think what protocol we use in core should be orthogonal

          to presence of PBBN access. The PBBN access can definitely

          run native ethernet protocols. As I mentioned above as per

          draft-ietf-l2vpn-pbb-vpls model we have inherited the PBB

          I/B components into existing VPLS PE and doesn't necessitate

          presence on PBBN access network.

      - section 4.3

[Pranjal] Same as comment in 4.2. We can run any X native ethernent

          Protocols on access network but all translates into an

          uniquitous generic mechanism in core for better
          inter-operability.

      - section 5.1

      - section 5.2

[Pranjal] I agree with the fact in all the above sections, that packet

          traverses thru disjoint components (transparent to each other)

          but should be one control plane towards core.

networks)

> [Pranjal] It would help if you can explain in what way it's

consistent.

[Pranjal] I would probably disagree with the point that

"their flushing should be governed by native Ethernet mechanism".

I don't see any reference in existing PBB VPLS WG drafts where

We have mentioned that C-MAC Flushing "SHOULD" be done with

native ethernet mechanism.

Cheers,

Ali

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Fri, 7 May 2010 11:15:06 -0500

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

> Sent: Thursday, May 06, 2010 10:27 PM
> To: Balus, Florin Stelian (Florin); David Allan I; Henderickx, Wim
> (Wim); Shane Amante; [email-masked]
> an
> > To: David Allan I; Henderickx, Wim (Wim); Ali Sajassi (sajassi);
> Shane
> > Amante; [email-masked]

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 7 May 2010 21:49:59 +0530

Hi, 
        Please refer inline some comments.
Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Thursday, May 06, 2010 6:29 PM
To: Balus, Florin Stelian (Florin); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

[Pranjal] I think we are taking a very narrower view based on requirements 
          on CMAC flush only. That is a very specific use case and 
          for PBB-VPLS PE model, CMAC flushing is not only the job. 
          Whether the CMAC flushing message traverses hop by hop or 
          transparent to hops as data is not the critical differentiator
          in the solution set. Note that in implementations, LDP MAC flush 
          can be highly packed (contains multiple vpls instances) and a 
          single message carries larger impact points. I think rests are 
          already replied by Florin and other people.
    
in
your

be
there

LDP
is
one

-Ali

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Fri, 7 May 2010 11:26:37 -0500

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:

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dutta, Pranjal K (Pranjal)
Sent: Friday, May 07, 2010 8:58 AM
To: Ali Sajassi (sajassi); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Ali,

Thanks,

Pranjal

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Thursday, May 06, 2010 11:51 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Pranjal,

conflict.

-  section 4.2

      - section 4.3

      - section 5.1

      - section 5.2

networks)

consistent.

Cheers,

Ali

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Fri, 7 May 2010 12:30:05 -0500

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

> C-MAC needs to be flushed and so there is no need to send the flush

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

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

> > > certification and OSS changes but modifying LDP to do it, it
> doesn't
> > !!
> >
> > > proposal, then I'd love to hear the reasoning behind it from them.
> I
> > > can
> > > > There are a lot of deployments like this around the world where
> it
> > is
> > > > education on the customer side" applies here: as you say below
> you
> > > had
> > > > to WG status but discussing with people in Anaheim it seemed
> there
> > is
> > > > easier to follow and implement in one shot enhancements related
> to
> > a
> > > > common tool.
> > > >
> > > > > Couple of years ago, I
> > > > > - Transparent to all devices operating on B-MAC addresses
> (e.g.,
> > > all
> > > > > intermediate devices)
> > > > Based on this we expect a lot of scalability improvements for
> PBB-
> > > VPLS

---

From: David Allan I <[email-masked]>
Date: Fri, 7 May 2010 14:26:50 -0400

Ok then, can we rename this somthing other than PBB, clearly it isn't...

That would make me very happy, we would have a clear delineation between what the IEEE is doing and what the IETF is doing...
D

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

Hi Ali,

Thanks,

Pranjal

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Thursday, May 06, 2010 11:51 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Pranjal,

conflict.

-  section 4.2

      - section 4.3

      - section 5.1

      - section 5.2

networks)

consistent.

Cheers,

Ali

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Fri, 7 May 2010 14:32:08 -0500

I thought the name we used for the solution was clear:  Extensions to LDP MAC Withdraw for PBB-VPLS. We did not say native PBB. We are opened though to clarify the scope in the next version of the text.
Florin

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

Hi Ali,

Thanks,

Pranjal

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Thursday, May 06, 2010 11:51 AM
To: Dutta, Pranjal K (Pranjal); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Hi Pranjal,

conflict.

-  section 4.2

      - section 4.3

      - section 5.1

      - section 5.2

networks)

consistent.

Cheers,

Ali

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sat, 8 May 2010 01:47:35 +0530

Don't think the discussion is centered on IEEE vs IETF. It's about LDP-VPLS
(RFC4762) extensions for PBB-VPLS. As Florin mentioned we are open to 
clarify the scope.

Thanks,
Pranjal

________________________________________

________________________________________

---

From: David Allan I <[email-masked]>
Date: Fri, 7 May 2010 16:42:32 -0400

< resend trimmed for length>
"PBB-encapsulation over VPLS" works for me, and is exactly descriptive....

D

________________________________
From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
Sent: Friday, May 07, 2010 4:15 PM
To: David Allan I; Balus, Florin Stelian (Florin); Ali Sajassi (sajassi); Shane Amante; [email-masked]
Subject: RE: Merge MAC Withdraw Drafts?

Don't think the discussion is centered on IEEE vs IETF. It's about LDP-VPLS (RFC4762) extensions for PBB-VPLS.
As Florin mentioned we are open to clarify the scope.

Thanks,
Pranjal

<snipped>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 7 May 2010 16:26:09 -0700

Hi Pranjal,

Please refer to my comment inline ...

[Pranjal] IMO, the question here is not about C-MAC Flushing in native
PBB 
          network via .1Qbe. In PBB-VPLS PE model
(draft-ietf-l2vpn-pbb-vpls-pe) 
          we have extended the *existing* VPLS bridge Module (aka VSI)
with I/B 
          components for service scalability and MAC table scalability.
In PBB-VPLS

          PE, the RFC 4762 LDP MAC Flush is already in place. Now
regarding the 

          question on how we are going to inter-op with PBB access
networks - 

          the PBB-VPLS PE model doesn't necessitate the presence on a
PBB access

          networks. So the question should be other way around - are we
going to 

          invent something new in RFC 4762 deployments for each access
network 

          requirement. So in draft-balus-pbb-ldp-ext we are not coining
something 
          new or re-inventing the wheel and just piggybacking PBB
specific info in 
          LDP MAC Flush. Using existing LDP based approach is generic
and can be 
          extended for future applications as well. We don't need run
each native 
          ethernet protocol in core. Neither we are ruling out that fact
the 

          native ethernet protocols can't be run between C-MAC
components.

It seems like there may be confusion between flushing mechanism for
B-MAC and C-MAC domains. In one of my emails, I described that the two
are apples and oranges and although one can extend the flushing
mechanism of the B-MAC domain for C-MAC domain, it is not a  good
solution since it will requires each network-type protocol be extended
to do that - for example each of the following protocols need to be
extended for doing this:

-          LDP for PBB-VPLS

-          MSTP for PBB

-          R-APS for G.8032

-          802.1aq for SPB-M

Furthermore, it now creates a massive interop issue since we have so
many different permutation to worry about interop for C-MAC flushing -
e.g., O(N!); where N is number of protocols.

A much cleaner way of addressing C-MAC flushing is to consider it
independent from B-MAC domain and use a simple native Ethernet message .
Since this message is an Ethernet message, it will work across all
different types of network.

 

towards the core. The same PE box that has CMAC component also has full 
fledged RFC 4762 and LDP implementation already.  Secondly, it's not
always 
necessary that there is a native PBB network towards CE.

The implementation can be anything but that's why we went through the
exercise of this modeling to have a clear demarcation and not burden
ourselves with reinventing bridging protocols when such protocols work
just fine. The reasons for this having PBB-VPLS PE model is the same as
that we did for  draft-ietf-l2vpn-vpls-bridge-interop:

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

   The existing control plane procedures described in [L2VPN-Sig
<http://tools.ietf.org/html/draft-ietf-l2vpn-pbb-vpls-pe-model-01#ref-L2
VPN-Sig#ref-L2VPN-Sig> ] and
   [RFC4762 <http://tools.ietf.org/html/rfc4762> ] can be re-used in a
PBB-VPLS to setup the PW infrastructure
   in the service provider and/or customer bridging space. This allows
   porting the existing control plane procedures (e.g. BGP-AD, PW setup,
   VPLS MAC Flush, PW OAM) for each domain.
 
I don't see any mention to flushing C-MAC addresses, so if there was an
implicit assumption then that's was not my intention. 

The conflict is with the model and the reason for me describing such
model was to make it clear that the same principles described in
draft-ietf-l2vpn-vpls-bridge-interop draft to apply here.

LDP MAC flush is a proven and simple mechanism being deployed in RFC
4762 
deployments for several years. draft-balus-pbb-ldp-ext exactly complies 
with Section 5. in draft-ietf-l2vpn-pbb-vpls.

If creating a canned Ethernet message was difficult or complex, then I
would have agreed. But we are talking about also very simple native
Ethernet scheme which consists of basically building a canned message.
So, it basically comes done to encoding the information that we already
have in either LDP message or Ethernet message. And using Native
Ethernet message gives us faster convergence and works well for all
mixed of network including  all-MPLS and avoid any interoperability down
the road.

-  section 4.2 

The point is how do we handle a scenario where we have both PBB access
and CE hanging off of the PE. In such case, can either do:

              a) LDP-based mechanism

              b) MIRP mechanism

              c) interop between the two

or simply just do (b).

      - section 4.3

Same comment as bove.

      - section 5.1

      - section 5.2

Same comment as above.

networks)

consistent.

Please refer to my previous comments above.

-Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 7 May 2010 16:39:55 -0700

Hi Pranjal,

message. 

[Pranjal] I think we are taking a very narrower view based on
requirements 

          in the solution set. Note that in implementations, LDP MAC
flush 
          can be highly packed (contains multiple vpls instances) and a 
          single message carries larger impact points. I think rests are

Pranjal, the native Ethernet mechanism (MIRP) also provides for highly
packed (multiple service instances)format. So, I can see that LDP based
mechanism will provide:

a)      Simple mechanism (thus simple implementation)

b)      No OSS modification - per Florin's claim J

c)       No new certification - per Florin's claim)

d)      Works for End-to-end MPLS deployment

And I can see wit MIRP based mechanism, I will get the above four plus
the following:

e)      Faster convergence

f)       Working with any mixed of networks

g)      Avoid inventing many interop solutions

h)      Avoid implementing & testing & operating many interop solutions

-Ali

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 7 May 2010 16:56:20 -0700

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

> Sent: Friday, May 07, 2010 9:15 AM
> To: Ali Sajassi (sajassi); David Allan I; Henderickx, Wim (Wim); Shane
> Amante; [email-masked]
> Where in my email you see anything of this sort? My text is right
> underneath your reply, it's not two replies back.
> 
> 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 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
> 
> > However, in all the above cases MIRP can be and should be used for
C-
> > > fact there are more existing QinQ deployments than PBBNs.
xSTP/ITU-
> T
> > > QinQ domains, each of them with their own MAC Flush procedures.
> None
> > of
> > > > OK, then we are on track to produce something that is not IEEE,
> it
> > is
> > > > across a number of subtending scenarios, where one wants to
limit
On
> > > > > During the Anaheim meeting I objected to the merge of these
two
> > > > drafts
> > > > LDP MAC Flush was used in all the H-VPLS deployments for the
last
> > 5-6
> > > > > draft-ietf-l2vpn-pbb-vpls-interop whereas .1Qbe can satisfy
all
> > > > FB> I think we addressed your (same) comments/objections a
number
> > > > > > a single place.  Here are the two drafts:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-
> 01
> > > > > > acceptable to merge draft-balus-l2vpn-pbb-ldp-ext-02 into
the
> > > > > existing
> > > > > >      draft-ietf-l2vpn-vpls-ldp-mac-opt-01 (LDP Extensions
for
> > > > > Optimized
> > > > > >      + Co-chairs to follow-up with call on WG mailing list
to
> > > merge

---

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

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 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, a few comments inline to your response
 
- Ali  

> Sent: Friday, May 07, 2010 10:30 AM
> To: Ali Sajassi (sajassi); Shane Amante; [email-masked]; Giles Heron
> ([email-masked])
> 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,
> 
> - 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.

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

---

From: Shane Amante <[email-masked]>
Date: Fri, 7 May 2010 19:46:30 -0600

Ali, Florin, Pranjal, et. al,

> should have the final say.

I agree that this particular dialogue has played itself out.  And, it does appear like you're at the point of "agreeing to disagree", which is perfectly fine.  I think all parties have had the opportunity to present their case in the open light of the mailing list and now it's up the individual members of the WG (who represent both operators _and_ equipment vendors, as should be evident by all the e-mails from people who've weighed in on this particular thread) to take all of the points raised into consideration and decide for themselves what should be done.  This is why the call on whether or not to merge these two drafts will remain open for another week until Friday, May 14th, as was pointed out in the original e-mail that we sent out on this subject.  Once the call closes, we will attempt to determine the consensus of the WG with respect to these two drafts, as we would normally do.

In the mean time, we would appreciate if everyone would continue to maintain a professional tone in their e-mails, (as everyone has done), as well as avoid a point-by-point or mail-by-mail back-and-forth, particularly on areas that have been previously covered.  IOW, making the same point over-and-over is not very constructive, particularly if other WG members want to ask questions or cast their opinion.  Of course, if there are incorrect technical facts that are brought up in subsequent discussions, then those should be duly corrected.

Thanks,

-shane
(co-chair L2VPN WG)

---

From: <[email-masked]>
Date: Sat, 8 May 2010 12:04:02 +0100

A few observations:

Firstly, I would tend to trust Ali's technical judgement/comments...esp
when it comes to Ethernet. This is based on personal experience of
dealing with him. 

Wearing a G.800 functional architecture hat I could very easily write
many pages on why the LDP form of MPLS has 'architectural challenges'
and causes complexity/problems.  Indeed, one need only look at the
effort on MPLS-TP in IETF to verify the correctness of this point....and
one of the first tasks here is to deprecate LDP's merging behaviour
because one MUST only allow p2p and p2mp constructs (==connections) in
order to provide deterministic resource to clients.....which is a fairly
fundamental requirement of any transport network.

Besides the merging problem of LDP (and PHP), one of the more serious
architectural problems with MPLS is that it does not treat all its
clients equally and in a proper client/server sense.  Wrt to IP this is
also being addressed in MPLS-TP....and the key point here being the
differentiation of IP as a *DP client* and IP as a *CP/MP adjunct cl-ps
layer network* that is providing a logically OOB CP/MP to manage the
MPLS-TP DP co-ps mode network.

However, there is still a major problem with the handling of nested LSPs
in MPLS-TP, ie MPLS as a client of MPLS.  In a nutshell, a transport
network must not use sublayering (ie the S bit, typical of how nested
LSPs appear today) as this is simply partitioning of a *single* layer
network and it is not the client/server relationship between different
layer networks wrt nested LSPs that MPLS-TP requires *if* it is to
provide a transport role.

Now a rather sad consequence of the architectural problems noted above
is the emergence of PWs, ie the treatment of clients other than IP and
MPLS....and when these are allowed to be multi-hop they generate yet
another co-ps mode (PW) layer network above MPLS/MPLS-TP.  Like LSP
sublayering (S bit) these should also not exist in MPLS-TP.  So we are
not really facing up to our past errors here even in the work on
MPLS-TP.  And I see a very similar situation here.

VPLS IMO is yet another errors that builds on the arch mistakes noted
above...but this takes it to a new level by creating functional coupling
of MPLS/PWs layer networks and an Ethernet layer network...and this is a
really bad idea architecturally.

One of the key planks of networking is that we do not create functional
coupling between different layer networks....and in particular a server
layer network must provide transparency to a client layer network.  In
essence, transparency means that a server layer network must never try
and infer meaning of client layer symbols and for sure must never change
them.  IP has been very successful because it always ensured it was
always treated in a transparent manner by whatever the server layer it
was carried over as a client, eg Ethernet, SDH VC4, PDH E1, etc, etc.

When it comes to MPLS however, we seem to have forgotten this very
important architectural rule on transparency...and VPLS is an example of
such.

**If we are wanting to impose functional behaviours in an Ethernet layer
network then the only correct architectiral solution is to address this
in the Ethernet layer network (in the DP/CP/MP as appropriate)....we
should not (IMO must not) be trying to impose those behavious by
DP/CP/MP actions in a different server layer network which are then
functionally coupled in some manner to the client Ehernet layer
network.**

One closing remark...I noted folks talking about QinQ in some of the
earlier mails in this thread.  QinQ in Ethernet is in many ways similar
to sublayering of LSPs in MPLS as-is.  That is, QinQ is also NOT a
client/server relationship but simply a form of partitioning a single
Ethernet layer network......one still has the same set of Ethernet
access point addressing here.  MACinMAC (ie PBB) OTOH is a proper
client/server relationship and correctly functionally partitions the
client (eg CMAC) addressing from the server (BMAC) addressing.

regards, Neil

> On Behalf Of Ali Sajassi (sajassi)
> Sent: 08 May 2010 02:00
> To: Balus, Florin Stelian (Florin); Shane Amante; 
> [email-masked]; Heron,GDY,Giles,DMF R
> 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:
> 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).
> 
> 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.
>

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Sat, 8 May 2010 12:29:22 -0500

Neil,
I think this email goes well beyond the scope of this discussion about a simple LDP extension for existing VPLS/MPLS deployments. 
I am seeing below a number of issues related to at least 3 IETF WGs:

1. LDP has a lot of issues
2. MPLS-TP requires some fixes - "there is still a major problem with MPLS-TP"
3. PWs seem to be a wrong step as a "rather sad consequence of the architectural problems noted above" (probably referring to 1 and 2)
4. same kind of issues for VPLS which is "yet another error"
 
If you or you and Ali want to debate these items I suggest we split the discussion as follows:

- issues 1. and 2. should be placed in one or more different emails addressed to MPLS WG
- issue 3 is of interest for PWE3 - so let's do another email for that one
- issue 4 is for L2VPN WG but should be debated on another email thread.

About issues 3 and 4: if this is the case then indeed we should not bother with any new developments in these areas. I think we should actually close the L2VPN and PWE3 WGs and leave it to IEEE to develop everything.

Personally I do not agree with the statements made for 3 and 4 and I think the large deployments around the world of the PWE3 and VPLS technologies is a proof that there was something right about them. But let's debate the specifics in the proper forums and see whether we need to throw them away.

Florin
PS: I am adding also MPLS, PWE3 WGs as I think they should be involved in this discussion.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, May 08, 2010 4:04 AM
> To: [email-masked]; Balus, Florin Stelian (Florin);
> [email-masked]; [email-masked]; [email-masked]

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Sat, 8 May 2010 13:12:21 -0500

Shane,

I am fine to stick to the process and give people more time considering it is a weekend and they need to try to follow the exchanges on the list. Personally I think there were no arguments that were not discussed at length for the last couple of years in IETF L2VPN sessions or in Ali's expired draft on native CMAC flushing for PBB-VPLS.

I will also be happy to discuss new feedback from new voices or from whoever spoke before on the list.

Can you clarify though what do you expect to happen from people that already voted one way or another and did not change their opinion? Do you want another round of votes?

Thanks,
Florin

> From: Shane Amante [mailto:[email-masked]]
> Sent: Friday, May 07, 2010 6:47 PM
> To: Ali Sajassi
> Cc: Balus, Florin Stelian (Florin); [email-masked]; [email-masked]
> Subject: Re: Merge MAC Withdraw Drafts?
>
> I agree that this particular dialogue has played itself out.  And, it
> does appear like you're at the point of "agreeing to disagree", which
> is perfectly fine.  I think all parties have had the opportunity to
> present their case in the open light of the mailing list and now it's
> up the individual members of the WG (who represent both operators _and_
> equipment vendors, as should be evident by all the e-mails from people
> who've weighed in on this particular thread) to take all of the points
> raised into consideration and decide for themselves what should be
> done.  This is why the call on whether or not to merge these two drafts
> will remain open for another week until Friday, May 14th, as was
> pointed out in the original e-mail that we sent out on this subject.
> Once the call closes, we will attempt to determine the consensus of the
> WG with respect to these two drafts, as we would normally do.
>
> In the mean time, we would appreciate if everyone would continue to
> maintain a professional tone in their e-mails, (as everyone has done),
> as well as avoid a point-by-point or mail-by-mail back-and-forth,
> particularly on areas that have been previously covered.  IOW, making
> the same point over-and-over is not very constructive, particularly if
> other WG members want to ask questions or cast their opinion.  Of
> course, if there are incorrect technical facts that are brought up in
> subsequent discussions, then those should be duly corrected.
>
> Thanks,
>
> -shane
> (co-chair L2VPN WG)
>
>
>
>
>

---

From: <[email-masked]>
Date: Sat, 8 May 2010 21:17:52 +0100

Thanks Florin,

I think most folks know my personal views on the technical matters I
have raised here...but to be strictly accurate these are actually not
'my views', they are simply conclusions from logical technical analysis
so I have no choice in arriving at these facts.  

Please note that in the co-ps mode we can do many things 'just because
we can' that are not possible in either the cl-ps mode or the co-cs
mode.  So the mere fact certain things exist and are doable is not
evidence they are a good idea and/or technically sound....which I would
differentiate from good marketing of such ;-).

Further, there are large time constants at play between cause and effect
in networking....so it often takes a long time (and large scale) to
start to get a feel for the real impacts of arch errors/complexity (and
even then in my experience true causal reasons are not always correctly
identified).

The reason why it is so easy to do the wrong things in the co-ps mode is
that resource assignment and labelling are decoupled actions.  I'll not
go into the underlying detail here, but it essentially comes down to how
we partition AND label a space/freq/time dimension of resource.....and
in the co-ps mode this is all about the labelling of irregular
time-slices of resource.  Those who want to pursue the detail can look
at G.800....and I am quite happy to go into off-line technical detail.

All I was trying to do in this mail was:
-	present a little bit of the history as to how we arrived at this
point;
-	give some insight as to what the architectural problems are that
we are now having to try and deal with...MPLS-TP is an example of one
reaction to this wrt attempting to provide a proper transparent
transport function in MPLS;
-	urge that in the future we try harder to have proper transparent
client/server relationships....and of course here we have the specific
case of MPLS/PW layer networks as the server to an Ethernet layer
network as the client.

So:  If we want a given functional behaviour in an Ethernet layer
network we should be addressing this in the DP/CP/MP of the Ethernet
layer network...not some other/lower layer network like MPLS, PWs, SDH
VC4 etc.  This is plain/obvious common sense anyway IMO.

Now wrt your remarks below please see in-line:

> Sent: 08 May 2010 18:29
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: Harrison,N,Neil,DKQ7 R; [email-masked]; 
> [email-masked]; Heron,GDY,Giles,DMF R
> I think this email goes well beyond the scope of this 
> discussion about a simple LDP extension for existing 
> VPLS/MPLS deployments. 

NH=> You can look at it this way, and I can easily understand why you
say this.  However, I am merely showing why we are at this juncture and
why, IMO, folks should stand back and look at the bigger networking
picture instead of just ploughing on from where we are now at.
 
> 1. LDP has a lot of issues

NH=> Yes it has Florin....it's an interesting technique and useful for
certain applications, but it has no basis in a transport network...which
is why it (and PHP and ECMP) are excluded in MPLS-TP.
 
> 2. MPLS-TP requires some fixes - "there is still a major 

NH=> Yes there are...the MPLS-TP folks in both IETF and ITU are well
aware of my observations.  I guess however it's not easy to accept that
MPLS-TP needs to do a little more than simple deprecate LDP, deprecate
PHP, deprecate ECMP and take its  CP/MP OOB.  It is, whether one likes
it or not, a simple technical fact that a properly designed co-ps mode
transport network would not have sublayering nor would it have PWs (or
even functions like TTL).  These are all 'carry-over' artefacts due to
the influence of LDP on MPLS's origins.

> 3. PWs seem to be a wrong step as a "rather sad consequence 
> of the architectural problems noted above" (probably 
> referring to 1 and 2)

NH=> This is also just a technical fact. If you want I can explain in
great detail why this is the situation.  However, I am also aware these
exist now and we cannot simply remove/ignore them.  However, this is no
excuse for not being technically accurate or honest about them is it?
And I for sure agree we have to cater for their legacy as we move
forward...but doing so does not mean these past errors should dictate
all future progress in standards...we really ought to strive to do be
'right first time' in the future.  Surely we can all agree with that.

 4. same kind of issues for VPLS which 
> is "yet another error"

NH=> This simply follows from the previous points and the functional
coupling of different layer network technologies.  This is just a fact.

> split the discussion as follows:

NH=> I have no need to debate them *here*.  They are simply facts that
we now have to live with.  If I am asking for anything here it is simply
this:  (i) can we please have some integrity/honesty about these facts
and (ii) can we please stop promulgating/compounding arch errors going
forward?  We cannot change history..... what is done is done, and we now
live with that legacy.  However, we should try and stop making things
worse going forward.

> About issues 3 and 4: if this is the case then indeed we 
> should not bother with any new developments in these areas. I 
> think we should actually close the L2VPN and PWE3 WGs and 
> leave it to IEEE to develop everything.

NH=> I suspect you might be slightly over-reacting here.  I totally
agree we need to cater for what is out there now, but my major plea is
let's not make things worse going forward by having a clear functional
separation of functions that apply to the Ethernet layer networks and
those that apply to the serving MPLS/PW layer networks (subject to the
architectural problems MPLS-TP is now wrestling with that I noted
above).  However, for further functional developments in Ethernet
DP/CP/MP then yes it should be down to IEEE to lead on this.  
> 
> Personally I do not agree with the statements made for 3 and 
> 4

NH=> This does not surprise me...a whole industry has now been created
on these architectural errors, so it is not in the interests of many
parties to 'agree' with the points I have made.  This, however, does not
detract from their technical accuracy of course.

> and I think the large deployments around the world of the 
> PWE3 and VPLS technologies is a proof that there was 
> something right about them.

NH=> Ah yes, the 'it exists therefore it must be right argument'.  There
are some significant commercial/marketing forces at play here that I'd
rather avoid, but I do have to acknowledge they are pertinent.  However,
at a *technical level* the argument that 'it exists therefore it must be
right' does not follow if one is being strictly honest with oneself as
an engineer.  I have already conceded we need to deal/live with our past
mistakes...human history is full of mistakes.....but when one has
figured out what the mistake is one should be somewhat wiser for this.
That is all I am asking for here.

> But let's debate the specifics in 
> the proper forums and see whether we need to throw them away.

NH=> We cannot "throw them away".....it's too late, they exist.
However, let's try and not make things worse going forward.  
regards, Neil

> > Firstly, I would tend to trust Ali's technical 
> > judgement/comments...esp when it comes to Ethernet. This is 
> based on 
> > personal experience of dealing with him.
> > 
> > effort on MPLS-TP in IETF to verify the correctness of this 
> > point....and one of the first tasks here is to deprecate 
> LDP's merging 
> > behaviour because one MUST only allow p2p and p2mp constructs 
> > (==connections) in order to provide deterministic resource to 
> > clients.....which is a fairly fundamental requirement of 
> any transport 
> > network.
> > 
> > clients equally and in a proper client/server sense.  Wrt 
> to IP this 
> > is also being addressed in MPLS-TP....and the key point 
> here being the 
> > differentiation of IP as a *DP client* and IP as a *CP/MP adjunct 
> > cl-ps layer network* that is providing a logically OOB 
> CP/MP to manage 
> > the MPLS-TP DP co-ps mode network.
> > 
> > However, there is still a major problem with the handling of nested 
> > LSPs in MPLS-TP, ie MPLS as a client of MPLS.  In a nutshell, a 
> > transport network must not use sublayering (ie the S bit, 
> typical of 
> > how nested LSPs appear today) as this is simply partitioning of a 
> > *single* layer network and it is not the client/server relationship 
> > between different layer networks wrt nested LSPs that 
> MPLS-TP requires 
> > *if* it is to provide a transport role.
> > 
> > above...but this takes it to a new level by creating functional 
> > coupling of MPLS/PWs layer networks and an Ethernet layer 
> > network...and this is a really bad idea architecturally.
> > 
> > One of the key planks of networking is that we do not create 
> > functional coupling between different layer networks....and in 
> > particular a server layer network must provide transparency to a 
> > client layer network.  In essence, transparency means that a server 
> > layer network must never try and infer meaning of client 
> layer symbols 
> > and for sure must never change them.  IP has been very successful 
> > because it always ensured it was always treated in a transparent 
> > manner by whatever the server layer it was carried over as 
> a client, 
> > eg Ethernet, SDH VC4, PDH E1, etc, etc.
> > 
> > important architectural rule on transparency...and VPLS is 
> an example 
> > of such.
> > 
> > **If we are wanting to impose functional behaviours in an Ethernet 
> > layer network then the only correct architectiral solution is to 
> > address this in the Ethernet layer network (in the DP/CP/MP as 
> > appropriate)....we should not (IMO must not) be trying to 
> impose those 
> > behavious by DP/CP/MP actions in a different server layer network 
> > which are then functionally coupled in some manner to the client 
> > Ehernet layer
> > network.**
> > 
> > earlier mails in this thread.  QinQ in Ethernet is in many ways 
> > similar to sublayering of LSPs in MPLS as-is.  That is, 
> QinQ is also 
> > NOT a client/server relationship but simply a form of 
> partitioning a 
> > single Ethernet layer network......one still has the same set of 
> > Ethernet access point addressing here.  MACinMAC (ie PBB) OTOH is a 
> > proper client/server relationship and correctly functionally 
> > partitions the client (eg CMAC) addressing from the server 
> (BMAC) addressing.
> > 
> > regards, Neil
> > 
> > 
> > 
> > > To: Balus, Florin Stelian (Florin); Shane Amante; [email-masked]; 
> > > Heron,GDY,Giles,DMF R
> > > 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.
> > >
> > > > night job! I wonder what will happen if we have to debate a 20 
> > > > page draft! :)
> > > >
> > > > Ali,
> > > >
> > > > 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 have been saying that is a bad solution for C-MACs 
> because of the 
> > > above reasons (refer to the summary).
> > >
> > > 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
> > > > The rest is just academic discussion. I will try to address 
> > > > in-line anything that resembles some scalability 
> discussion just 
> > > > because I
> > > like
> > > > Ali. :)
> > >

---

From: Shane Amante <[email-masked]>
Date: Sat, 8 May 2010 14:19:23 -0600

Florin,

> Can you clarify though what do you expect to happen from people that already voted one way or another and did not change their opinion? Do you want another round of votes?

I do not want to start "another round of votes", since people should have been familiar with the drafts, use cases and related technologies when their cast their opinion on the list.  That said, if as a result of the discussion over the past few days a WG member has had a change of opinion, then they are free to do so on the list.  It would also be useful if, at the same time, they could share the reasons why they were changing their opinion in order to ensure there aren't any misunderstandings.

Thanks,

-shane
(co-chair L2VPN WG)

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Sat, 8 May 2010 21:21:22 -0500

Thanks Neil for the clarifications. I am familiar with your views and I see a consistent reasoning here.

I believe though we should not use the architectural considerations presented below to block enhancements of any particular MPLS toolset required to address particular MPLS deployment needs. We have across the 3 WGs active drafts like this, many of them more complex that the current L2VPN proposal under debate. To evaluate them we are bound to use the architectural documents that each WG developed and previous experience (implementation and deployment) to evaluate whether there are any technical issues and whether they are consistent with the previously used models.

Unless you intend to reopen the architectural discussion in the above WGs I suggest we close this thread, go back to l2vpn and focus on evaluating the proposed LDP MAC Flush extension based on the architectural documents and models developed in the L2VPN WG.

Florin

> Sent: Saturday, May 08, 2010 1:18 PM
> To: Balus, Florin Stelian (Florin); [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> > > > my previous email:

---

From: <[email-masked]>
Date: Mon, 10 May 2010 08:17:51 +0100

Thanks Florin,

I agree wrt to closing this thread here wrt points of historical
significance that have led us to where we are today.  I do hope,
however, that by providing this brief look at our heritage we can all
see/agree with the major point I am making...which is:

We should not be functionally coupling different layer networks.  This
has been a central tenet of why IP has been so successful in being able
to be carried over any lower layer network (ie "IP over
everything")....and this is literally all about adhering to the rigorous
architectural requirements of transparency and functional decoupling in
a client/server network.  We should therefore *consistently* practice
what we preach.

I simply provided this background so that one can see that my support of
Ali's position was not a random choice.....though my point is even
broader, ie for functional behaviour changes in layer network X (any
mode) then this should only be effected by changes to the DP/CP/MP
protocols of layer X and not some other layer network Y (any mode)
technology.

regards, Neil

> Sent: 09 May 2010 03:21
> To: Harrison,N,Neil,DKQ7 R; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; Heron,GDY,Giles,DMF R
> Thanks Neil for the clarifications. I am familiar with your 
> views and I see a consistent reasoning here.
> 
> I believe though we should not use the architectural 
> considerations presented below to block enhancements of any 
> particular MPLS toolset required to address particular MPLS 
> deployment needs. We have across the 3 WGs active drafts like 
> this, many of them more complex that the current L2VPN 
> proposal under debate. To evaluate them we are bound to use 
> the architectural documents that each WG developed and 
> previous experience (implementation and deployment) to 
> evaluate whether there are any technical issues and whether 
> they are consistent with the previously used models.
> 
> Unless you intend to reopen the architectural discussion in 
> the above WGs I suggest we close this thread, go back to 
> l2vpn and focus on evaluating the proposed LDP MAC Flush 
> extension based on the architectural documents and models 
> developed in the L2VPN WG.
> 
> Florin
> 
> > 'my views', they are simply conclusions from logical technical 
> > analysis so I have no choice in arriving at these facts.
> >
> > evidence they are a good idea and/or technically sound....which I 
> > would differentiate from good marketing of such ;-).
> >
> > Further, there are large time constants at play between cause and 
> > effect in networking....so it often takes a long time (and large 
> > scale) to start to get a feel for the real impacts of arch 
> > errors/complexity (and even then in my experience true 
> causal reasons 
> > are not always correctly identified).
> >
> > The reason why it is so easy to do the wrong things in the 
> co-ps mode 
> > is that resource assignment and labelling are decoupled 
> actions.  I'll 
> > not go into the underlying detail here, but it essentially 
> comes down 
> > to how we partition AND label a space/freq/time dimension of 
> > resource.....and in the co-ps mode this is all about the 
> labelling of 
> > irregular time-slices of resource.  Those who want to pursue the 
> > detail can look at G.800....and I am quite happy to go into 
> off-line 
> > technical detail.
> >
> > > I think this email goes well beyond the scope of this discussion 
> > > about a simple LDP extension for existing VPLS/MPLS deployments.
> >
> > say this.  However, I am merely showing why we are at this juncture 
> > and why, IMO, folks should stand back and look at the bigger 
> > networking picture instead of just ploughing on from where 
> we are now at.
> >
> > certain applications, but it has no basis in a transport 
> > network...which is why it (and PHP and ECMP) are excluded 
> in MPLS-TP.
> >
> > aware of my observations.  I guess however it's not easy to accept 
> > that MPLS-TP needs to do a little more than simple deprecate LDP, 
> > deprecate PHP, deprecate ECMP and take its  CP/MP OOB.  It 
> is, whether 
> > one likes it or not, a simple technical fact that a 
> properly designed 
> > co-ps mode transport network would not have sublayering nor 
> would it 
> > have PWs (or even functions like TTL).  These are all 'carry-over' 
> > artefacts due to the influence of LDP on MPLS's origins.
> >
> >
> >
> > > 3. PWs seem to be a wrong step as a "rather sad 
> consequence of the 
> > > architectural problems noted above" (probably referring 
> to 1 and 2)
> >
> > great detail why this is the situation.  However, I am also aware 
> > these exist now and we cannot simply remove/ignore them.  However, 
> > this is no excuse for not being technically accurate or 
> honest about them is it?
> > > If you or you and Ali want to debate these items I 
> suggest we split 
> > > the discussion as follows:
> >
> > forward?  We cannot change history..... what is done is 
> done, and we 
> > now live with that legacy.  However, we should try and stop making 
> > things worse going forward.
> >
> > >
> > > - issues 1. and 2. should be placed in one or more 
> different emails 
> > > addressed to MPLS WG
> should not 
> > > bother with any new developments in these areas. I think 
> we should 
> > > actually close the L2VPN and PWE3 WGs and leave it to IEEE to 
> > > develop everything.
> >
> > parties to 'agree' with the points I have made.  This, 
> however, does 
> > not detract from their technical accuracy of course.
> >
> > at a *technical level* the argument that 'it exists 
> therefore it must 
> > be right' does not follow if one is being strictly honest 
> with oneself 
> > as an engineer.  I have already conceded we need to 
> deal/live with our 
> > past mistakes...human history is full of mistakes.....but 
> when one has 
> > > > However, there is still a major problem with the handling of 
> > > > nested LSPs in MPLS-TP, ie MPLS as a client of MPLS.  In a 
> > > > nutshell, a transport network must not use sublayering 
> (ie the S 
> > > > bit,
> > > typical of
> > > > *single* layer network and it is not the client/server 
> > > > relationship between different layer networks wrt 
> nested LSPs that
> > > MPLS-TP requires
> > > > another co-ps mode (PW) layer network above MPLS/MPLS-TP.  Like 
> > > > LSP sublayering (S bit) these should also not exist in MPLS-TP.
> > >  So we are
> > > > client layer network.  In essence, transparency means that a 
> > > > server layer network must never try and infer meaning of client
> > > layer symbols
> > > > Ethernet access point addressing here.  MACinMAC (ie 
> PBB) OTOH is 
> > > > a proper client/server relationship and correctly functionally 
> > > > > From: [email-masked] 
> [mailto:[email-masked]] On 
> > > > > Behalf Of Ali Sajassi (sajassi)
> > > > > Sent: 08 May 2010 02:00
> > > > > subject and I hope this discussion has been 
> informative to our 
> > > > > SP colleagues and the pros/cons of these two approaches are
> > > now clear
> > > > > -       None ( based on this long email thread, no 
> one has pointed
> > a
> > > > > > To: Ali Sajassi (sajassi); Shane Amante; 
> [email-masked]; Giles
> > > > Heron
> > > > > > ([email-masked])
> > > > > > 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
> > > > > > I will summarize the point that is left on 
> scalability to make 
> > > > > > some steps towards the closure:
> > > > > For B-MACs !! and there is perfect reason for not 
> doing it for 
> > > > > C-MACs
> > > > > :-)
> > > > >
> 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

---

From: <[email-masked]>
Date: Mon, 10 May 2010 09:42:55 +0200

I support merging these two drafts.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Shane Amante
Envoyé : mardi 4 mai 2010 05:49
À : [email-masked]
Objet : Merge MAC Withdraw Drafts?

Hi Everyone,

Giles & Shane

---snip---

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 10 May 2010 03:32:44 -0500

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

> Sent: Friday, May 07, 2010 6:00 PM
> [email-masked]
> -	Creates interop issues and wll require additional interop
> solutions

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 May 2010 12:31:15 -0700

Florin,

In all my previous emails on this thread, I never said there is an issue
with MPLS or PW (as you have listed below in response to Neil) so please
stop muddying the water and confusing the people. What I have said over
and over again is that the use of LDP for flushing C-MAC addresses in
PBB-VPLS is a bad idea and I have refuted your claims of the need for
re-certification and OSS changes !! and I have given you a list of
reasons as to why it is a bad idea to do C-MAC flushing using LDP and
why the native flush is a much better solution (e.g., faster service
convergence, works for E2E MPLS with both LDP and BGP signaling, works
with any mixed of network, etc.). However, I never heard back from you
to challenge me on re-certification or OSS changes or the benefits of
native flush over LDP-based approach, instead I have heard the
repetition of the same argument from you: "there is no issue with LDP
for VPLS and thus it should also be used for PBB-VPLS". I have explained
many time on this thread why the flushing of MACs in VPLS/H-VPLS is like
apples and oranges when compared to flushing of C-MACs in PBB-VPLS and I
won't repeat them here. With enough thrust you can make pig flies but it
doesn't mean there is something wrong with your thruster :-)

-Ali

> Sent: Saturday, May 08, 2010 10:29 AM
> Cc: [email-masked]; Ali Sajassi (sajassi);
> [email-masked]; [email-masked]
> I think this email goes well beyond the scope of this discussion about
> a simple LDP extension for existing VPLS/MPLS deployments.
> 3. PWs seem to be a wrong step as a "rather sad consequence of the
> architectural problems noted above" (probably referring to 1 and 2)
> If you or you and Ali want to debate these items I suggest we split
the
> discussion as follows:
> About issues 3 and 4: if this is the case then indeed we should not
> bother with any new developments in these areas. I think we should
> actually close the L2VPN and PWE3 WGs and leave it to IEEE to develop
> everything.
> 
> Personally I do not agree with the statements made for 3 and 4 and I
> think the large deployments around the world of the PWE3 and VPLS
> technologies is a proof that there was something right about them. But
> let's debate the specifics in the proper forums and see whether we
need
> to throw them away.
> judgement/comments...esp
> > point....and
cl-
> ps
> > LSPs
> > coupling
> > of MPLS/PWs layer networks and an Ethernet layer network...and this
> is
> > a
> functional
> > important architectural rule on transparency...and VPLS is an
example
> > layer
> similar
> page
> > > > I will summarize the point that is left on scalability to make
> some
> experience
> > > > - So we should conclude that this procedure is working just fine
> in
> > > > real life deployments.
> procedure

---

From: Shane Amante <[email-masked]>
Date: Mon, 10 May 2010 14:20:29 -0600

Ali,

On May 10, 2010, at 13:50 MDT, Ali Sajassi (sajassi) wrote:
> Yes, the issues have been captured in my expired draft which provided the ground work for MIRP standard. The draft served its purpose of stating the issues and suggesting a native flush mechanism flush (similar to the one standardized in MIRP).   Although, the draft has been around for couple of years, we never had any discussions on why we should ignore a more general “standard-based” approach and doing a LDP specific approach for C-MAC flushing till now.
>  
> Given that many of the issues that we discussed over the past week, was not clear to many people, I would have rather to take another poll.

I would rather we didn't take another poll, since there is still 1 more week left for people to voice or change their opinions.  IMO, that should be adequate time for people to digest the dialogue that has occurred and decide what to do, while at the same time not holding up progress in the WG.  Please refer to my previous e-mail addressing that very point:
http://www.ietf.org/mail-archive/web/l2vpn/current/msg02387.html

-shane
(co-chair L2VPN WG)

> Sent: Saturday, May 08, 2010 11:12 AM
> To: Shane Amante
> Cc: [email-masked]; [email-masked]

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 10 May 2010 15:37:36 -0500

Ali,
I said "if you or you and Ali want to reopen the discussion". I did not say you want to re-open it. The beginning of your email clarifies the your position. I don't think the rest of your email is required - you already sent your summary of arguments to L2VPN after a long exchange.
Let's just restrict the distribution list back to L2VPN WG and leave it now to the WG to decide.
Thanks,
Florin

> Sent: Monday, May 10, 2010 12:31 PM
> Cc: [email-masked]; [email-masked]; [email-masked]
> about
> > - issue 3 is of interest for PWE3 - so let's do another email for
> that
> > one
> > PS: I am adding also MPLS, PWE3 WGs as I think they should be
> involved
> > in this discussion.
> >
> >
> > > clients equally and in a proper client/server sense.  Wrt to IP
> this
> > is
> > > > > anything that resembles some scalability discussion just
> because
> > I
> > > > like
> > > > > Ali. :)
> > > >

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 10 May 2010 16:30:53 -0500

Ali,
I did not see before my initial reply the text at the end of your email below.

Can you limit yourself to a civilized language? The reference "something wrong with your thruster" is way out of line and I do not think the 3 WG lists are a place for such remarks!

Let's stick to technical debate - you sent your objections on the L2VPN list, I sent my replies, the WG will decide one way or another and I am fine with whatever is decided.
Florin

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 May 2010 14:48:15 -0700

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

> Sent: Monday, May 10, 2010 1:33 AM
> To: [email-masked]; [email-masked]; [email-masked]
> 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.
> 
> - 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)
> 
> 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.
> 
> 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.
> 
> - 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.
> 
> - 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
> 
subject
page
> > > I will summarize the point that is left on scalability to make
some
> > > steps towards the closure:
experience
> > Again, my issue is not with B-MAC flushing. As I said numerous
times,
in
procedure
> > > So in conclusion I think we need to close this thread too: there
is
> > no
in-line

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 May 2010 14:57:54 -0700

Florin,

"With enough thrust you can make pigs fly" is an English adage. The
entire quote was:
" With enough thrust you can make pig flies but it doesn't mean there is
something wrong with your thruster :-)"

It was a light-hearted sentence and that's why you see the smiley face
":-)" at the end of the sentence. lighten up.

-Ali

> Sent: Monday, May 10, 2010 2:31 PM
> To: Ali Sajassi (sajassi)
> Cc: [email-masked]; [email-masked]; [email-masked];
> Subject: Inappropriate email content
> 
> 
> Ali,
> I did not see before my initial reply the text at the end of your
email
> below.
> 
> Can you limit yourself to a civilized language? The reference
> "something wrong with your thruster" is way out of line and I do not
> think the 3 WG lists are a place for such remarks!
> 
> Let's stick to technical debate - you sent your objections on the
L2VPN
> list, I sent my replies, the WG will decide one way or another and I
am
> fine with whatever is decided.
> Florin
> 
> > apples and oranges when compared to flushing of C-MACs in PBB-VPLS
> and
> > I
> > won't repeat them here. With enough thrust you can make pig flies
but
> > > 2. MPLS-TP requires some fixes - "there is still a major problem
> with
> > > MPLS-TP"
> > > - issues 1. and 2. should be placed in one or more different
emails
> develop
> > > > because one MUST only allow p2p and p2mp constructs
> (==connections)
> > > in
> > > > order to provide deterministic resource to clients.....which is
a
> > > > fairly
> nested
> > > > is the emergence of PWs, ie the treatment of clients other than
> IP
> > > and
> LSP
> > > > sublayering (S bit) these should also not exist in MPLS-TP.  So
> we
> > > are
> > > > layer network must provide transparency to a client layer
> network.
> > > In
> > > > essence, transparency means that a server layer network must
> never
> > > try
> > > > and infer meaning of client layer symbols and for sure must
never
> > > > change
> > > > always treated in a transparent manner by whatever the server
> layer
> > > it
> > > > network then the only correct architectiral solution is to
> address
> > > this
> > > > > -       None ( based on this long email thread, no one has
> pointed
> > a
> > > > > > To: Ali Sajassi (sajassi); Shane Amante; [email-masked];
> Giles
> > > > Heron
> > > > > > ([email-masked])
> > > > > > conclude it is ok to agree to disagree - this is supposed to
> be
> > > my
> > > > > For B-MACs !! and there is perfect reason for not doing it for
> C-
> > > MACs
> > > > > :-)
> > > > >
> > > > > > with implementing and deploying HVPLS, MS-PWs and I did not
> see
> > > any
> > > > > > reply.
> > > > >
> in-
> > > line

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 10 May 2010 17:08:07 -0500

There are jokes I can accept easily in a private setting and jokes with sexual connotation that are not acceptable, in my culture at least, on a public distribution list.

Florin

> Sent: Monday, May 10, 2010 2:58 PM
> To: Balus, Florin Stelian (Florin)
> Subject: RE: Inappropriate email content
>
> Florin,
>
> > > > Personally I do not agree with the statements made for 3 and 4
> and
> > I
> > > > technologies is a proof that there was something right about
> them.
> > > But
> > > > > layer network* that is providing a logically OOB CP/MP to
> manage
> > > the
> > > > > Now a rather sad consequence of the architectural problems
> noted
> > > > above
> > > > > MPLS....and when these are allowed to be multi-hop they
> generate
> > > yet
> > > > > coupling between different layer networks....and in particular
> a
> > > > server
> > > > > was carried over as a client, eg Ethernet, SDH VC4, PDH E1,
> etc,
> > > etc.
> > > > >
> > > > > One closing remark...I noted folks talking about QinQ in some
> of
> > > the
> > > > > to sublayering of LSPs in MPLS as-is.  That is, QinQ is also
> NOT
> > a
> > > > > client/server relationship and correctly functionally
> partitions
> > > the
> > > > > > > With the reply below I think we are at a point where we
> need
> > to

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 10 May 2010 15:21:09 -0700

"Thruster" in that sentence refers to the device that "thrust" the pigs to make them fly. Please refer to your dictionary before making an embarrassing statement of  "jokes with sexual connotation"

Definitions of thruster (n) [from merriam-webster dictionary]
thrust·er [ thrústər ]   
rocket that controls altitude: a rocket on a spacecraft or high-altitude aircraft that controls an altitude or flight path

This is my last reply on this subject as all these WG groups should not be copied for this kind of emails in first place !!

> Sent: Monday, May 10, 2010 3:08 PM
> There are jokes I can accept easily in a private setting and jokes with
> sexual connotation that are not acceptable, in my culture at least, on
> a public distribution list.
> 
> Florin
> 
> > > > In all my previous emails on this thread, I never said there is
> an
> > > > issue
> > > > stop muddying the water and confusing the people. What I have
> said
> > > over
> > > > and over again is that the use of LDP for flushing C-MAC
> addresses
> > in
> > > > with any mixed of network, etc.). However, I never heard back
> from
> > > you
> > > > to challenge me on re-certification or OSS changes or the
> benefits
> > of
> > > > many time on this thread why the flushing of MACs in VPLS/H-VPLS
> is
> > > > like
> discussion
> > > > > architectural problems noted above" (probably referring to 1
> and
> > 2)
> > > > > - issue 4 is for L2VPN WG but should be debated on another
> email
> > > > > thread.
> > > > >
> > > > > > when it comes to Ethernet. This is based on personal
> experience
> > > of
> > > > > > dealing with him.
> > > > > >
> > > > > > Wearing a G.800 functional architecture hat I could very
> easily
> > > > write
> > > > > > and causes complexity/problems.  Indeed, one need only look
> at
> > > the
> > > > > > architectural problems with MPLS is that it does not treat
> all
> > > its
> > > > > > also being addressed in MPLS-TP....and the key point here
> being
> > > the
> > > > > > network must not use sublayering (ie the S bit, typical of
> how
> > > > nested
> > > > > > LSPs appear today) as this is simply partitioning of a
> *single*
> > > > layer
> > > > > > layer networks wrt nested LSPs that MPLS-TP requires *if* it
> is
> > > to
> > > > > > VPLS IMO is yet another errors that builds on the arch
> mistakes
> > > > noted
> > > > > > of MPLS/PWs layer networks and an Ethernet layer
> network...and
> > > this
> > > > > is
> > > > > > a
> > > > > > them.  IP has been very successful because it always ensured
> it
> > > was
> > > > > > DP/CP/MP actions in a different server layer network which
> are
> > > then
> > > > > > client/server relationship but simply a form of partitioning
> a
> > > > single
> > > > > > > -       No additional interop solution development,
> testing,
> > > and
> > > > > > > operating
> > > > > > > Cons:
> > > > > > > > night job! I wonder what will happen if we have to debate
> a
> > > 20
> > > > > page
> > > > > > > > draft! :)
> > > > > > > >
> > > > > > > > Ali,
> > > > > > > >
> > > > > > > > - I asked you to highlight also any initiative targeted
> at
> > > > fixing
> > > > > > > these
> just
> > > > fine
> > > > > > > > data plane function. Worthwhile to note for completion
> that
> > > > > > > VPLS Mesh
> > > > > > > > So in conclusion I think we need to close this thread
> too:
> > > > > > > there is no

---

From: Shane Amante <[email-masked]>
Date: Mon, 10 May 2010 18:55:09 -0600

Ali, Florin,

Let this be second and final warning that if you persist with this back-and-forth, particularly on points that have been made again and again, I will temporarily moderate your posts to the L2VPN WG mailing list through the remainder of the week during this call to merge these two documents so as to be less disruptive to the rest of the WG.

-shane
(co-chair L2VPN WG)

---

From: Shane Amante <[email-masked]>
Date: Sat, 15 May 2010 08:28:32 -0600

Hello All,

This concludes the call to merge draft-balus-l2vpn-pbb-ldp-ext-02 into draft-ietf-l2vpn-vpls-ldp-mac-opt-01.

Based on responses on the mailing list there appears to be overwhelming consensus to adopt the two drafts, notably 22 people in favor and 1 opposed.  FWIW, there appeared to be good representation from a variety of equipment vendors and SP's.   Specifically, those in favor of merging the two drafts comprised people believed to be affiliated with 5 different equipment vendors and 8 different SP's.

Would the authors please consider Dave Allan's comment about retitling the appropriate section(s) in the new draft to avoid confusion down the road?
http://www.ietf.org/mail-archive/web/l2vpn/current/msg02376.html

Thanks,

-shane & Giles
(co-chair L2VPN WG)