Subject: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

From: Giles Heron <[email-masked]>
Date: Mon, 09 Jan 2012 18:39:44 +0000

This is a request to gauge consensus as to whether:
 
http://tools.ietf.org/html/draft-raggarwa-sajassi-l2vpn-evpn-04

should be accepted as an L2VPN WG draft.

Now that we've accepted the requirements and framework drafts (I think
Nabil's about to send email to the list re the framework!), it's time to
start considering whether the solutions drafts we have (this draft and the
pbb-epvn draft) are the right basis for our solutions docs.

Please review the draft and respond by Monday January 23rd with comments as
to its suitability for WG adoption.

Giles

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Mon, 9 Jan 2012 20:11:04 +0100

Support as a co-author

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: maandag 9 januari 2012 19:40
To: [email-masked]
Subject: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Giles

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 9 Jan 2012 11:57:16 -0800

Support the work.

-Vishwas

---

From: John E Drake <[email-masked]>
Date: Mon, 9 Jan 2012 12:02:10 -0800

Support

> Sent: Monday, January 09, 2012 10:40 AM
> To: [email-masked]

---

From: Nadeem Mohammad <[email-masked]>
Date: Mon, 9 Jan 2012 15:04:41 -0500

Support

Nadeem.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Monday, January 09, 2012 3:02 PM
To: Giles Heron; [email-masked]
Subject: RE: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Support

---

From: Alia Atlas <[email-masked]>
Date: Mon, 9 Jan 2012 15:37:58 -0500

Support

---

From: "DelRegno, Christopher N (Nick)" <[email-masked]>
Date: Mon, 9 Jan 2012 15:51:06 -0500

Support.

Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Monday, January 09, 2012 12:40 PM
To: [email-masked]
Subject: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Now that we've accepted the requirements and framework drafts (I think Nabil's about to send email to the list re the framework!), it's time to start considering whether the solutions drafts we have (this draft and the pbb-epvn draft) are the right basis for our solutions docs.

Please review the draft and respond by Monday January 23rd with comments as to its suitability for WG adoption.

Giles

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Mon, 9 Jan 2012 13:00:37 -0800

Support as co-editor.

-Ali

---

From: "Balus, Florin Stelian (Florin)" <[email-masked]>
Date: Mon, 9 Jan 2012 16:30:02 -0600

Support as a co-author.

---

From: Keyur Patel <[email-masked]>
Date: Mon, 09 Jan 2012 14:33:04 -0800

Support.

Regards,
Keyur

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 9 Jan 2012 14:44:18 -0800

Support.

Giles

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 9 Jan 2012 17:48:41 -0500

Yes/support

Regards,
Jeff

---

From: Prabakaran Thirumali Sampath <[email-masked]>
Date: Mon, 9 Jan 2012 14:55:12 -0800

Support

Regards,
Prabakaran T Sampath

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Monday, January 09, 2012 10:40 AM
To: [email-masked]
Subject: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Giles

---

From: Paul Unbehagen <[email-masked]>
Date: Mon, 9 Jan 2012 16:55:55 -0700

Support

---

From: Aldrin Isaac <[email-masked]>
Date: Mon, 9 Jan 2012 20:29:47 -0500

Support.

---

From: Shishio Tsuchiya <[email-masked]>
Date: Tue, 10 Jan 2012 11:05:34 +0900

Support

---

From: Phil <[email-masked]>
Date: Tue, 10 Jan 2012 01:35:07 -0500

Support.

---

From: Jounay Frédéric <[email-masked]>
Date: Tue, 10 Jan 2012 08:52:34 +0100

Support.

Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: maandag 9 januari 2012 19:40
To: [email-masked]
Subject: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Giles

---

From: <[email-masked]>
Date: Tue, 10 Jan 2012 09:14:29 +0100

Support.

-Thomas

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Tue, 10 Jan 2012 07:07:37 -0500

+1 as co-author

---

From: <[email-masked]>
Date: Tue, 10 Jan 2012 15:55:52 +0100

Support.

Regards

   Nic

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Giles Heron
Gesendet: Montag, 9. Januar 2012 19:40
An: [email-masked]
Betreff: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Giles

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 10 Jan 2012 15:23:09 +0000

Support..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali Sajassi (sajassi)
Sent: Monday, January 09, 2012 4:01 PM
To: Giles Heron; [email-masked]
Subject: RE: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Support as co-editor.

-Ali

---

From: "Fragassi, Roberto (Roberto)" <[email-masked]>
Date: Tue, 10 Jan 2012 09:32:09 -0600

Support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Giles Heron
Sent: Monday, January 09, 2012 1:40 PM
To: [email-masked]
Subject: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Giles

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Jan 2012 15:42:19 +0000

Support. 

Linda Dunbar

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 11 Jan 2012 17:52:49 +0900

Yes, support.

Kenichi

---

From: "iLya" <[email-masked]>
Date: Wed, 11 Jan 2012 12:42:48 +0100

I tentatively support this draft. However I'd like to ask whether it would 
be not more proper to decouple control-plane flooding (BGP-related stuff) 
and learning/forwarding? The reason is that it's possible to devise a method 
other than described in the draft to distribute MAC addresses (e.g. using 
IGP) while utilising the same learning/forwarding mechanism described in 
this draft. Likewise, a forwarding mechanism supporting active-active 
multihoming for Broadcast, Unknown unicast, Multicast traffic can be 
envisioned that could use same flooding method (BGP) as described in this 
draft. To avoid future works to be build upon 
draft-raggarwa-sajassi-l2vpn-evpn a split would be helpful.

Thoughts?

Cheers,
iLya

--------------------------------------------------
From: "Giles Heron" <[email-masked]>
Sent: Monday, January 09, 2012 7:39 PM
To: <[email-masked]>
Subject: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jan 2012 06:41:25 +0100

Hi Giles & L2VPN WG,

I do not support acceptance of this document. (Yes I realize I am a bit 
original in this thread with 26.5 supports already ;-)

I find draft-sajassi-l2vpn-pbb-evpn as much more scalable solution yet 
fully covering services which draft-raggarwa-sajassi-l2vpn-evpn claims 
to offer.

I also do not think this WG should proceed with both.

Regarding Ilya's comment I 100% agree that control plane and data plane 
should be described in separate documents - that is referring to both 
pbb-evpn and evpn drafts.

The fundamental reason for this is that while documents describe very 
well how to construct data plane they only bring "learning" based 
control plane as example. I think this is clear to everyone that there 
are other more efficient control planes today which do not follow 
"distribute information everywhere" flooding model. Especially in EVPN 
distributing customer MACs everywhere where there may never be a 
conversation seems in the number of applications as not even suboptimal 
.. but just broken.

Editorial nit to draft-raggarwa-sajassi-l2vpn-evpn-04.txt .. line 363 
contains ref to [BGP-VPLS-MH] which is not found in references. The 
closest one is: [VPLS-MULTIHOMING]. Another nit is that it is hard to 
tell which references are normative and which are only informational.

Rgs,
R.

---

From: Jie Dong <[email-masked]>
Date: Thu, 12 Jan 2012 07:09:34 +0000

Hi Robert,

> I think this is clear to everyone that there

Agree that flooding customer MACs everywhere is not good. Here we may consider using RTC mechanism [RFC4684]. Then one of my concern is about the Auto-Derivation of the Route Target from Ethernet Tag ID. This way the automatically generated RTs may be overlapped with RT spaces of other VPN services (e.g. L3VPN), and we know overlapped RT space would impact the effect of RTC.

Regards,
Jie

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jan 2012 08:17:12 +0100

Hello Jie,

> Agree that flooding customer MACs everywhere is not good. Here we may
> consider using RTC mechanism [RFC4684].

Well I am well going beyond that. I actually assumed RFC4684 is in 
effect already .. one of the reasons I asked for normative references :).

In particular I am talking about data center inter-connectivity
where large number of the VMs _belonging_ to the same customer E-VPN may 
never need to exchange data between each other yet their respective MSEs 
may be loaded with huge number of MAC addresses for no reason.

As a matter of fact PBB-EVPN doc says is very clearly:

    In typical operation, an [E-VPN] MES sends a BGP MAC Advertisement
    Route per customer/client MAC (C-MAC) address. In certain
    applications, this poses scalability challenges, as is the case in
    virtualized data center environments where the number of virtual
    machines (VMs), and hence the number of C-MAC addresses, can be in
    the millions. In such scenarios, it is required to reduce the number
    of BGP MAC Advertisement routes by relying on a MAC 'summarization'
    scheme, as is provided by PBB. Note that the MAC sub-netting
    capability already built into E-VPN is not sufficient in those
    environments, as will be discussed next.

Best,
R.

---

From: Jie Dong <[email-masked]>
Date: Thu, 12 Jan 2012 07:48:47 +0000

Hi Robert,

> effect already .. one of the reasons I asked for normative references :).

OK

>     environments, as will be discussed next.

For MES to learn only C-MACs of active traffic, PBB-EVPN draft proposes to learn C-MAC through data-plane:

	The MES nodes perform the following functions:
 	- Learn customer/client MAC addresses (C-MACs) over the attachment
 	 circuits in the data-plane, per normal bridge operation.
  
 	- Learn remote C-MAC to B-MAC bindings in the data-plane from
 	 traffic ingress from the core per [802.1ah] bridging operation.

Data-plane learning means unknown unicast broadcasting cannot be eliminated. And as you say that "there are other more efficient control planes today which do not follow "distribute information everywhere" flooding model", can one of them replace the C-MAC data-plane learning in PBB-EVPN draft? 

Best regards,
Jie

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Jan 2012 18:31:10 +0100

Hi Jie,

> Data-plane learning means unknown unicast broadcasting cannot be
> eliminated. And as you say that "there are other more efficient
> control planes today which do not follow "distribute information
> everywhere" flooding model", can one of them replace the C-MAC
> data-plane learning in PBB-EVPN draft?

Yes it can. However I do not see this as showstopper from proceeding 
forward with current pbb-evpn document including data plane based MAC 
learning.

Thx,
R.

---

From: Haoweiguo <[email-masked]>
Date: Mon, 16 Jan 2012 01:44:33 +0000

Support
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Giles Heron [[email-masked]]
发送时间: 2012年1月10日 2:39
到: [email-masked]
主题: WG adoption of draft-raggarwa-sajassi-l2vpn-evpn

Giles

---

From: Samer Salam <[email-masked]>
Date: Mon, 16 Jan 2012 13:51:30 -0800

Support.

Regards,
Samer