I agree with Larry that both L2 over L3 and L3 over L3 should be considered and 
be included in the charter. However, the term “layer agnostic”  seems not 
concrete enough and hence may cause some confusion. For example, it could be 
interpreted as “underlying network agnostic” (e.g., L2 over L2, L2 over 
nickname…)

Best regards,
Xiaohu

发件人: [email protected] [mailto:[email protected]] 代表 Larry Kreeger
发送时间: 2012年4月21日 6:48
收件人: Bocci, Matthew (Matthew); John E Drake; David Black; Stewart Bryant; 
[email protected]
抄送: Yakov Rekhter; Nitin Bahadur; [email protected]; [email protected]
主题: Re: [nvo3] NVO3 charter 1530UK 12April

I support the sentence below from Matthew which reads “ The WG will determine 
whether an IP, and/or an emulated Ethernet service is needed to satisfy the 
needs of the typical data centre." because I just noticed that the latest 
charter is missing the following sentence that was in the charter Benson sent 
out after the BOF which read, “This approach should provide an Ethernet 
service.  It may provide an IP service; an important goal is to develop a  
"layer agnostic" framework and architecture meeting data center requirements.".

I agreed that keeping the architecture “layer agnostic” is a very good idea to 
leave room for how DC networking may evolve in the future.  A Layer 2 service 
may be needed now (at least for some applications), but layer 3 service may 
suffice for many applications and give benefits in terms of scale and/or 
simplification and/or interoperability.  Lets not decide at the time of charter.

 - Larry


On 4/20/12 4:31 AM, "Bocci, Matthew (Matthew)" 
<[email protected]> wrote:
John,

How about the following changes to the paragraph below? The intention is to 
clearly phrase the charter in terms of requirements work that the WG will do, 
while at the same time scope the requirements we will work on, rather than 
predicate any ultimate solutions.

"NVO3 will consider approaches to multi-tenancy that use an
encapsulation header that resides at or above the network layer, rather than 
relying on
traditional L2 isolation mechanisms (e.g., VLANs) to support
multi-tenancy. The WG will determine whether an IP, and/or an emulated Ethernet 
service is needed to satisfy the needs of the typical data centre."

Regards,

Matthew


On 19/04/2012 16:24, "John E Drake" <[email protected]> wrote:
David,

I don’t think you have the authority to change the words in the charter, which 
reads:

“It will also address requirements driven by cloud computing services and data 
centers as they apply to Layer-2 VPN services."

Further, as I have told you and Thomas multiple times, a data center operator 
is not required to provide a certificate indicating they are a ‘provider’ 
before they are allowed to deploy L3/L2 VPN technology, and many large 
enterprise networks consider themselves to be service providers in their own 
right.

Thanks,

John


Sent from my iPhone


From: [email protected] [mailto:[email protected]]
Sent: Thursday, April 19, 2012 7:17 AM
To: John E Drake; [email protected]; [email protected]; 
[email protected]
Cc: Yakov Rekhter; Nitin Bahadur; [email protected]; [email protected]
Subject: RE: [nvo3] NVO3 charter 1530UK 12April

John,

I think the potential “data center” overlap with L2VPN can be resolved by 
carefully understanding the first text extract from L2VPN charter.  I read the 
second sentence as implying a couple of crucial words in [square brackets]:

"The L2VPN working group is responsible for defining and specifying a limited 
number of solutions for supporting provider-provisioned Layer-2 Virtual Private 
Networks (L2VPNs). It will also address requirements driven by cloud computing 
services and data centers as they apply to [provider-provisioned] Layer-2 VPN 
services."


We can split hairs over what “provider” means, but I believe the primary 
distinction in initial focus is data center infrastructure vs. network carrier 
(provider) provisioning and operation of the overlay (or VPN if one wants to 
use that term).

The following definition from RFC 4664, Framework for Layer 2 Virtual Private 
Networks (L2VPNs), may also help in understanding the L2VPN WG’s scope:

   The term "provider provisioned VPNs" refers to Virtual Private
   Networks (VPNs) for which the Service Provider (SP) participates in
   management and provisioning of the VPN.

In this context, many data centers of importance to nvo3 (e.g., enterprise data 
centers) are not operated by the Service Provider, as the term is used in this 
RFC 4664 definition.

Thanks,
--David


From: [email protected] [mailto:[email protected]] On Behalf Of John E 
Drake
Sent: Thursday, April 19, 2012 8:06 AM
To: Bocci, Matthew (Matthew); Stewart Bryant; Kireeti Kompella
Cc: Yakov Rekhter; Nitin Bahadur; [email protected]; [email protected]
Subject: Re: [nvo3] NVO3 charter 1530UK 12April

Matthew,

Snipped, comment inline.

Thanks,

John


Sent from my iPhone



Why not just rephrase the paragraph so that it does not appear to prescribe 
protocol development, but rather scopes the solutions to those that the IETF 
traditionally deals with and that meet the requirements/gap analysis?:



“NVO3 will consider an approach to multi-tenancy that uses a Layer 3 
encapsulation rather than relying on traditional L2 isolation mechanisms (e.g., 
VLANs) to support multi-tenancy, and consistent with a requirements gathering 
and gap analysis exercise. The approach will provide an emulated Ethernet 
service capable of satisfying typical data center deployments.”

[JD]   I also have a problem with the last sentence as it sounds as though NV03 
will be encroaching on the charter of the L2VPN WG, which reads, in part:

"The L2VPN working group is responsible for defining and specifying a limited 
number of solutions for supporting provider-provisioned Layer-2 Virtual Private 
Networks (L2VPNs). It will also address requirements driven by cloud computing 
services and data centers as they apply to Layer-2 VPN services."

And:

"5. Ethernet VPN (E-VPN) - An enhanced Layer-2 service that emulates an 
Ethernet (V)LAN across a PSN. E-VPN supports load-sharing across multiple 
connections from a Layer-2 site to an L2VPN service. E-VPN is primarily 
targeted to support large-scale L2VPNs with resiliency requirements not 
satisfied by other L2VPN solutions."


________________________________
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to