Subject: [nvo3] Last Call for Comments on Proposed Charter

From: Benson Schliesser <[email-masked]>
Date: Wed, 3 Sep 2014 10:29:25 -0700

Dear NVO3 Contributors -

This message initiates a 1 week last call for comments on the proposed
charter. The charter has been discussed on the mailing list for about a
month, and the chairs believe there is consensus to go forward with the
current text. We intend to submit the proposed charter text to the IESG on
10-Sep-2014. The proposed charter text is found at
http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-20140901.txt
and is quoted below.

Just a reminder, this last call is not an opportunity to vote. Please do
not waste time on messages that merely say "support" or "+1". Rather, this
is an opportunity to raise any material issues or feedback that has not yet
been addressed on the mailing list.

Matthew and I are thankful for everybody's contribution to the charter
discussion, and we look forward to making progress in the next phase of the
NVO3 WG.

Cheers,
-Benson & Matthew

http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-20140901.txt

The purpose of the NVO3 WG is to develop a set of protocols and/or protocol
extensions that enable network virtualization within a data center (DC)
environment using an IP-based overlay approach. An NVO3 solution provides layer
2 and/or layer 3 services for virtual networks enabling multi-tenancy, workload
mobility, optimization, management, and security, addressing the issues
described in the problem statement and consistent with the framework previously
produced by the NVO3 WG.

The NVO3 WG will develop solutions for network virtualization based on the
following architectural tenets:
 - Support for an IP-based underlay data plane
 - A logically centralized authority for network virtualization
Network virtualization approaches that do not adhere to these tenets are
explicitly outside of the scope of the NVO3 WG.

In pursuit of the solutions described above, the NVO3 WG will document an
architecture for network virtualization within a data center environment.

The NVO3 WG may produce requirements for a network virtualization control
plane, and will select, extend, and/or develop one or more control plane
protocols to support the architecture. Such protocols are expected to fulfill
the communication requirements between an End Device and Network Virtualization
Edge (NVE), and between an NVE and the Network Virtualization Authority (NVA).
The internal mechanisms and protocols of a logically centralized NVA are
explicitly out of scope of the NVO3 WG.  Architectural issues raised by
coexistence of multiple logically centralized control planes in the same data
center may be considered by the WG. Inter-DC mechanisms are not in scope of
the NVO3 WG at this time.

The NVO3 WG may produce requirements for network virtualization data planes
based on encapsulation of virtual network traffic over an IP-based underlay
data plane. Such requirements should consider OAM and security. Based on these
requirements the WG will select, extend, and/or develop one or more data plane
encapsulation format(s).

Additionally, the WG may document common use-cases for NVO3 solutions.

The working group may choose to adopt a protocol or data encapsulation that was
previously worked on outside the IETF as the basis for the WG's work.  If the
NVO3 WG anticipates the adoption of the technologies of another SDO as part of
the selected protocols or data encapsulation, the NVO3 WG will first liaise
with that SDO.

BGP-based solutions to network virtualization within a data center environment
will be developed in the BGP-Enabled Services (BESS) WG.

MILESTONES

Done - Problem Statement submitted for IESG review
Done - Framework document submitted for IESG review
TBD - Architecture submitted for IESG review
TBD - End Device to NVE Control Plane Protocol Adopted by WG
TBD - NVE to NVA Control Plane Protocol Adopted by WG
TBD - NVE Data Plane Protocol Adopted by WG
TBD - Data Plane Requirements submitted for IESG review
TBD - Control Plane Requirements submitted for IESG review
TBD - OAM Requirements submitted for IESG review
TBD - Security Requirements submitted for IESG review
TBD - Use Cases submitted for IESG review
TBD - End Device to NVE Control Plane Protocol Submitted for IESG review
TBD - NVA to NVA Control Plane Protocol Submitted for IESG review
TBD - NVE Data Plane Protocol Submitted for IESG review
TBD - Recharter or close WG

---

From: Sharon Barkai <[email-masked]>
Date: Wed, 3 Sep 2014 17:33:50 +0000

Support

--szb

On Sep 3, 2014, at 10:29, "Benson Schliesser" <[email-masked]<mailto:[email-masked]>> wrote:

Dear NVO3 Contributors -

This message initiates a 1 week last call for comments on the proposed charter. The charter has been discussed on the mailing list for about a month, and the chairs believe there is consensus to go forward with the current text. We intend to submit the proposed charter text to the IESG on 10-Sep-2014. The proposed charter text is found at http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-20140901.txt and is quoted below.

Just a reminder, this last call is not an opportunity to vote. Please do not waste time on messages that merely say "support" or "+1". Rather, this is an opportunity to raise any material issues or feedback that has not yet been addressed on the mailing list.

Matthew and I are thankful for everybody's contribution to the charter discussion, and we look forward to making progress in the next phase of the NVO3 WG.

Cheers,
-Benson & Matthew

MILESTONES

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 3 Sep 2014 10:52:54 -0700

Looks good to me; please move forward with it. 

On Sep 3, 2014:10:29 AM, at 10:29 AM, Benson Schliesser <[email-masked]> wrote:

> [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Mon, 08 Sep 2014 15:07:24 -0400

Hi Benson.

Thanks for the updated charter. Here are some possible wording
clarifications. I do not believe the change the charter in a material
way (and are not intended to). But they may make aspects of it a bit
clearer.

> described in the problem statement and consistent with the framework previously

better:

I suggest removing " optimization, management, and security" because
they are not things that are "enabled" by NVO3 per se. At least not
without more words explaining what is meant. If I were an IESG member,
I'd ask "what do those words mean?". I think all these things are
covered in the problem statement/framework anyway, and folk with
questions should be pointed there.

> explicitly outside of the scope of the NVO3 WG.

The above (mentioning logically centralized) I think continues to be
confusing because it could use more context. How about:

The NVO3 WG will develop solutions for network virtualization based on the
following architectural tenets:
  - Support for an IP-based underlay data plane
  - A Network Virtualization Edge (NVE) that sits at the edge of an
    underlay network and provides L2 and/or L3 network virtualization
    functions to Tenant Systems
  - A logically centralized Network Virtualization Authority (NVA)
    that NVEs interact with to obtain the information necessary to
    provide a virtualized service.
Network virtualization approaches that do not adhere to these tenets are
explicitly outside of the scope of the NVO3 WG.

> the NVO3 WG at this time.

Above can be shortened or redone based on previous suggestion. Also,
actually think the use of "end device" above is not sufficient/precise
enough, because we are NOT talking about a generic "end device", but
the split-NVE case in particular. Better to just say that. (And note
that the WG document that covers this case is
draft-ietf-nvo3-hpvr2nve-cp-req, which is called "Hypervisor to NVE
Control Plane Requirements".)

E.g., something like:

The NVO3 WG may produce requirements for a network virtualization
control plane, and will select, extend, and/or develop one or more
control plane protocols to support the architecture. Such protocols
are expected to fulfill the following communication requirements:
 - for a "split-NVE", where the NVE functions are split between an end
   device and an adjacent switch,
 - between an NVE and an NVA.
The internal mechanisms and protocols of a logically centralized NVA
are explicitly out of scope of the NVO3 WG.  Architectural issues raised by
coexistence of multiple logically centralized control planes in the
same data center may be considered by the WG. Inter-DC mechanisms are
not in scope of the NVO3 WG at this time.

> TBD - End Device to NVE Control Plane Protocol Adopted by WG

Better: Control Plane for Split-NVE case Adopted

> TBD - Recharter or close WG

Thanks!

Thomas

---

From: Lucy yong <[email-masked]>
Date: Mon, 8 Sep 2014 20:55:44 +0000

Thomas,

Some Comments:

"A Network Virtualization Edge (NVE) that sits at the edge of an
    underlay network and provides L2 and/or L3 network virtualization
    functions to Tenant Systems"

Comment: If NVE resides on a Server that is a host in an underlay network, IMO: this is not the case that NVE sits at the edge of underlay network. Should we state that an NVE that either resides at the edge of an underlay network or co-locate with Tenant Systems on an end device, or both and provides ...

Regards,
Lucy
-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Monday, September 08, 2014 2:07 PM
To: Benson Schliesser
Cc: [email-masked]
Subject: Re: [nvo3] Last Call for Comments on Proposed Charter

Hi Benson.

Thanks for the updated charter. Here are some possible wording clarifications. I do not believe the change the charter in a material way (and are not intended to). But they may make aspects of it a bit clearer.

> The purpose of the NVO3 WG is to develop a set of protocols and/or 
> protocol extensions that enable network virtualization within a data 
> center (DC) environment using an IP-based overlay approach. An NVO3 
> solution provides layer
> 2 and/or layer 3 services for virtual networks enabling multi-tenancy, 
> workload mobility, optimization, management, and security, addressing 
> the issues described in the problem statement and consistent with the 
> framework previously produced by the NVO3 WG.

better:

I suggest removing " optimization, management, and security" because they are not things that are "enabled" by NVO3 per se. At least not without more words explaining what is meant. If I were an IESG member, I'd ask "what do those words mean?". I think all these things are covered in the problem statement/framework anyway, and folk with questions should be pointed there.

> The NVO3 WG will develop solutions for network virtualization based on 
> the following architectural tenets:
> Network virtualization approaches that do not adhere to these tenets 
> are explicitly outside of the scope of the NVO3 WG.

The above (mentioning logically centralized) I think continues to be confusing because it could use more context. How about:

The NVO3 WG will develop solutions for network virtualization based on the following architectural tenets:
  - Support for an IP-based underlay data plane
  - A Network Virtualization Edge (NVE) that sits at the edge of an
    underlay network and provides L2 and/or L3 network virtualization
    functions to Tenant Systems
  - A logically centralized Network Virtualization Authority (NVA)
    that NVEs interact with to obtain the information necessary to
    provide a virtualized service.
Network virtualization approaches that do not adhere to these tenets are explicitly outside of the scope of the NVO3 WG.

> In pursuit of the solutions described above, the NVO3 WG will document 
> an architecture for network virtualization within a data center environment.
> 
> are expected to fulfill the communication requirements between an End 
> Device and Network Virtualization Edge (NVE), and between an NVE and the Network Virtualization Authority (NVA).
> are explicitly out of scope of the NVO3 WG.  Architectural issues 
> raised by coexistence of multiple logically centralized control planes 
> in the same data center may be considered by the WG. Inter-DC 
> mechanisms are not in scope of the NVO3 WG at this time.

Above can be shortened or redone based on previous suggestion. Also, actually think the use of "end device" above is not sufficient/precise enough, because we are NOT talking about a generic "end device", but the split-NVE case in particular. Better to just say that. (And note that the WG document that covers this case is draft-ietf-nvo3-hpvr2nve-cp-req, which is called "Hypervisor to NVE Control Plane Requirements".)

E.g., something like:

The NVO3 WG may produce requirements for a network virtualization control plane, and will select, extend, and/or develop one or more control plane protocols to support the architecture. Such protocols are expected to fulfill the following communication requirements:
 - for a "split-NVE", where the NVE functions are split between an end
   device and an adjacent switch,
 - between an NVE and an NVA.
The internal mechanisms and protocols of a logically centralized NVA are explicitly out of scope of the NVO3 WG.  Architectural issues raised by coexistence of multiple logically centralized control planes in the same data center may be considered by the WG. Inter-DC mechanisms are not in scope of the NVO3 WG at this time.

> 
> The NVO3 WG may produce requirements for network virtualization data 
> planes based on encapsulation of virtual network traffic over an 
> IP-based underlay data plane. Such requirements should consider OAM 
> and security. Based on these requirements the WG will select, extend, 
> and/or develop one or more data plane encapsulation format(s).
> 
> The working group may choose to adopt a protocol or data encapsulation 
> that was previously worked on outside the IETF as the basis for the 
> WG's work.  If the
> NVO3 WG anticipates the adoption of the technologies of another SDO as 
> part of the selected protocols or data encapsulation, the NVO3 WG will 
> first liaise with that SDO.
> 
> BGP-based solutions to network virtualization within a data center 
> environment will be developed in the BGP-Enabled Services (BESS) WG.
> 
> MILESTONES
> 
> Done - Problem Statement submitted for IESG review Done - Framework 
> document submitted for IESG review TBD - Architecture submitted for 
> IESG review TBD - End Device to NVE Control Plane Protocol Adopted by 
> WG

> TBD - NVE to NVA Control Plane Protocol Adopted by WG TBD - NVE Data 
> Plane Protocol Adopted by WG TBD - Data Plane Requirements submitted 
> for IESG review TBD - Control Plane Requirements submitted for IESG 
> review TBD - OAM Requirements submitted for IESG review TBD - Security 
> Requirements submitted for IESG review TBD - Use Cases submitted for 
> IESG review TBD - End Device to NVE Control Plane Protocol Submitted 
> for IESG review TBD - NVA to NVA Control Plane Protocol Submitted for 
> IESG review TBD - NVE Data Plane Protocol Submitted for IESG review 

Thanks!

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Mon, 08 Sep 2014 17:14:39 -0400

Hi Lucy.

At Mon, 8 Sep 2014 20:55:44 +0000, Lucy yong wrote:
> Comment: If NVE resides on a Server that is a host in an underlay
> network, IMO: this is not the case that NVE sits at the edge of
> underlay network.

Why do you say that? In the case of the server, it has an interface on
the underlay network, and is thus at the edge of the network.

Even then, I don't think we need to get too precise in what we mean by
"edge", i.e., whether it is at the very edge, or one hop in (as the
case might be for split-NVE).

To me, by definition, the NVE is always at the edge, because it has
one interface on the underlay, and one "interface" towards the End
System it is providing the virtual network service to.

> Should we state that an NVE that either resides at
> the edge of an underlay network or co-locate with Tenant Systems on an
> end device, or both and provides ...

I think this wording is making things more complicated than is needed
for the charter.

BTW, the "edge" wording you are questioning comes directly from the
framework document!

Thomas
> 
> Regards, Lucy -----Original Message----- From: nvo3
> [mailto:[email-masked]] On Behalf Of Thomas Narten Sent:
> Monday, September 08, 2014 2:07 PM To: Benson Schliesser Cc:
> [email-masked] Subject: Re: [nvo3] Last Call for Comments on Proposed
> Charter
> 
> Hi Benson.
> 
> > solution provides layer 2 and/or layer 3 services for virtual
> > networks enabling multi-tenancy, workload mobility, optimization,
> > management, and security, addressing the issues described in the
> > problem statement and consistent with the framework previously
> > produced by the NVO3 WG.
> 
> better:
> 
> > In pursuit of the solutions described above, the NVO3 WG will
> > document an architecture for network virtualization within a data
> > center environment.
> > 
> > are expected to fulfill the communication requirements between an
> > End Device and Network Virtualization Edge (NVE), and between an NVE
> > and the Network Virtualization Authority (NVA).  The internal
> > mechanisms and protocols of a logically centralized NVA are
> > explicitly out of scope of the NVO3 WG.  Architectural issues raised
> > by coexistence of multiple logically centralized control planes in
> > the same data center may be considered by the WG. Inter-DC

---

From: Lucy yong <[email-masked]>
Date: Mon, 8 Sep 2014 21:41:22 +0000

If Server has an interface to underlay network, I am not sure if we can call the server as the edge of underlay network.

NVE is the edge of a virtual network.  

Lucy

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Monday, September 08, 2014 4:15 PM
To: Lucy yong
Cc: Benson Schliesser; [email-masked]
Subject: Re: [nvo3] Last Call for Comments on Proposed Charter

Hi Lucy.

> network, IMO: this is not the case that NVE sits at the edge of 

Why do you say that? In the case of the server, it has an interface on the underlay network, and is thus at the edge of the network.

Even then, I don't think we need to get too precise in what we mean by "edge", i.e., whether it is at the very edge, or one hop in (as the case might be for split-NVE).

To me, by definition, the NVE is always at the edge, because it has one interface on the underlay, and one "interface" towards the End System it is providing the virtual network service to.

> Should we state that an NVE that either resides at the edge of an 
> underlay network or co-locate with Tenant Systems on an end device, or 
> both and provides ...

I think this wording is making things more complicated than is needed for the charter.

BTW, the "edge" wording you are questioning comes directly from the framework document!

Thomas
> > http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-20140
> > 90
> > 1.txt
> > 
> > and security. Based on these requirements the WG will select, 
> > extend, and/or develop one or more data plane encapsulation format(s).
> > 
> > The working group may choose to adopt a protocol or data 
> > encapsulation that was previously worked on outside the IETF as the 
> > basis for the WG's work.  If the
> > NVO3 WG anticipates the adoption of the technologies of another SDO 
> > as part of the selected protocols or data encapsulation, the NVO3 WG 
> > will first liaise with that SDO.
> > 
> > IESG review TBD - End Device to NVE Control Plane Protocol Adopted 
> > by WG
> 
> > review TBD - OAM Requirements submitted for IESG review TBD - 
> > Security Requirements submitted for IESG review TBD - Use Cases 
> > submitted for IESG review TBD - End Device to NVE Control Plane 
> > Protocol Submitted for IESG review TBD - NVA to NVA Control Plane 
> > Protocol Submitted for IESG review TBD - NVE Data Plane Protocol 
> > Submitted for IESG review TBD - Recharter or close WG
> 
> Thanks!
> 
> Thomas
>

---

From: Thomas Narten <[email-masked]>
Date: Mon, 08 Sep 2014 18:09:47 -0400

Sorry, I'm not following what your concern is. Here is the definition
of NVE from the framework document:

   Network Virtualization Edge (NVE). An NVE is the network entity that
   sits at the edge of an underlay network and implements L2 and/or L3
   network virtualization functions. The network-facing side of the NVE
   uses the underlying L3 network to tunnel tenant frames to and from
   other NVEs. The tenant-facing side of the NVE sends and receives
   Ethernet frames to and from individual Tenant Systems.  An NVE could
   be implemented as part of a virtual switch within a hypervisor, a
   physical switch or router, a Network Service Appliance, or be split
   across multiple devices.

Are you disagreeing with that?

Thomas

At Mon, 8 Sep 2014 21:41:22 +0000, Lucy yong wrote:
> 
> If Server has an interface to underlay network, I am not sure if we
> can call the server as the edge of underlay network.
> 
> -----Original Message----- From: Thomas Narten
> [mailto:[email-masked]] Sent: Monday, September 08, 2014 4:15 PM
> To: Lucy yong Cc: Benson Schliesser; [email-masked] Subject: Re: [nvo3]
> Last Call for Comments on Proposed Charter
> 
> Hi Lucy.
> 
> >     underlay network and provides L2 and/or L3 network
> >     virtualization functions to Tenant Systems"
> > 
> > underlay network or co-locate with Tenant Systems on an end device,
> > or both and provides ...
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 8 Sep 2014 22:16:07 +0000

We need move forward on the framework and live with this statement. 
Lucy

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Monday, September 08, 2014 5:10 PM
To: Lucy yong
Cc: Benson Schliesser; [email-masked]
Subject: Re: [nvo3] Last Call for Comments on Proposed Charter

Sorry, I'm not following what your concern is. Here is the definition of NVE from the framework document:

Thomas

At Mon, 8 Sep 2014 21:41:22 +0000, Lucy yong wrote:
> > clarifications. I do not believe the change the charter in a 
> > material way (and are not intended to). But they may make aspects of 
> > it a bit clearer.
> > 
> > > protocol extensions that enable network virtualization within a 
> > > data center (DC) environment using an IP-based overlay approach. 
> > > An NVO3 solution provides layer 2 and/or layer 3 services for 
> > > virtual networks enabling multi-tenancy, workload mobility, 
> > > optimization, management, and security, addressing the issues 
> > > described in the problem statement and consistent with the 
> > without more words explaining what is meant. If I were an IESG 
> > member, I'd ask "what do those words mean?". I think all these 
> > things are covered in the problem statement/framework anyway, and 
> > folk with questions should be pointed there.
> > 
> > > The NVO3 WG will develop solutions for network virtualization 
> > > based on the following architectural tenets:
> > > Network virtualization approaches that do not adhere to these 
> > > tenets are explicitly outside of the scope of the NVO3 WG.
> > 
> > > control plane protocols to support the architecture. Such 
> > > protocols are expected to fulfill the communication requirements 
> > > between an End Device and Network Virtualization Edge (NVE), and 
> > > between an NVE and the Network Virtualization Authority (NVA).  
> > > The internal mechanisms and protocols of a logically centralized 
> > > NVA are explicitly out of scope of the NVO3 WG.  Architectural 
> > > issues raised by coexistence of multiple logically centralized 
> > > control planes in the same data center may be considered by the 
> > > WG. Inter-DC mechanisms are not in scope of the NVO3 WG at this time.
> > 
> > actually think the use of "end device" above is not 
> > sufficient/precise enough, because we are NOT talking about a 
> > generic "end device", but the split-NVE case in particular. Better 
> > to just say that. (And note that the WG document that covers this 
> > case is draft-ietf-nvo3-hpvr2nve-cp-req, which is called "Hypervisor 
> > to NVE Control Plane Requirements".)
> > 
> > E.g., something like:
> > 
> > raised by coexistence of multiple logically centralized control 
> > planes in the same data center may be considered by the WG. Inter-DC 
> > > The NVO3 WG may produce requirements for network virtualization 
> > > data planes based on encapsulation of virtual network traffic over 
> > > an IP-based underlay data plane. Such requirements should consider 
> > > OAM and security. Based on these requirements the WG will select, 
> > > encapsulation that was previously worked on outside the IETF as 
> > > the basis for the WG's work.  If the
> > > NVO3 WG anticipates the adoption of the technologies of another 
> > > SDO as part of the selected protocols or data encapsulation, the 
> > > NVO3 WG will first liaise with that SDO.
> > > 
> > > Done - Problem Statement submitted for IESG review Done - 
> > > Framework document submitted for IESG review TBD - Architecture 
> > > Protocol Adopted by WG
> > > TBD - NVE to NVA Control Plane Protocol Adopted by WG TBD - NVE 
> > > Data Plane Protocol Adopted by WG TBD - Data Plane Requirements 
> > > submitted for IESG review TBD - Control Plane Requirements 
> > > submitted for IESG review TBD - OAM Requirements submitted for 
> > > IESG review TBD - Security Requirements submitted for IESG review 
> > > TBD - Use Cases submitted for IESG review TBD - End Device to NVE 
> > > Control Plane Protocol Submitted for IESG review TBD - NVA to NVA 
> > > Control Plane Protocol Submitted for IESG review TBD - NVE Data 
> > > Plane Protocol Submitted for IESG review TBD - Recharter or close 
> > > WG
> > 
> > Thanks!
> > 
> > Thomas
> >

---

From: Sharon Barkai <[email-masked]>
Date: Tue, 9 Sep 2014 03:00:27 +0000

One last try to split this nose hair:

NVA: Find  "logically centralized" replace with  "logically distinguished" a service defined by the NVE-NVA interface

 (and not by implementation eg BGP, DHT, X500..)

The NVO3 WG will develop solutions for network virtualization based on the
following architectural tenets:
 - Support for an IP-based underlay data plane
 - A Network Virtualization Edge (NVE) that sits at the edge of an
   underlay network and provides L2 and/or L3 network virtualization
   functions to Tenant Systems
 - A logically distinguished Network Virtualization Authority (NVA), a service that NVEs interact with to obtain the information necessary to
   provide a virtualized service, and is defined by the NVE-NVA interface and API.

--szb

> On Sep 8, 2014, at 12:08 PM, "Thomas Narten" <[email-masked]> wrote:
> 
> Hi Benson.
>

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 11 Sep 2014 01:40:36 +0000

Hi Sharon,

I really have not idea what the term "logically distinguished" means.  It
seem to suggest that the NVA can be distinguished (recognized as
different) from something else by using logic, but I assume that isn't
what you meant.  I'm not in favor of this term.

 - Larry

On 9/8/14 8:00 PM, "Sharon Barkai" <[email-masked]> wrote:

>NVA: Find  "logically centralized" replace with  "logically
>distinguished" a service defined by the NVE-NVA interface
>
> - A logically distinguished Network Virtualization Authority (NVA), a
>service that NVEs interact with to obtain the information necessary to
>>>protocol
>>>workload
>>>are
>>>an
>>>control
>>>are
>>>same data
>>raised by
>>>planes
>>>that was
>>>part of
>>>environment

---

From: Sharon Barkai <[email-masked]>
Date: Thu, 11 Sep 2014 03:52:12 +0000

Hi Larry, Trying to capture the point about separating the NVA, a pervasive service centralized, clustered, or federated, from the meshed-aggregation topology constrains of the NVEs. 

Such separation is not mandatory in traditional routing, but is mandatory to scale NVOs. The NVE-NVO interface defined by this separation should be key target for standardization.

However, like most folks on the WG also all for moving forward.
Once we separate what's NVE-NVE  (examp L2/3 encap, echos, measurements..) and what's NVE-NVA (RLOC/VTEP, Mcast, affinity..) the right language will hopefully emerge.

--szb

> On Sep 10, 2014, at 6:40 PM, "Larry Kreeger (kreeger)" <[email-masked]> wrote:
> 
> Hi Sharon,
>