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 protected]] On Behalf Of Thomas Narten
Sent: Monday, September 08, 2014 2:07 PM
To: Benson Schliesser
Cc: [email protected]
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.
> http://svn.tools.ietf.org/svn/wg/nvo3/charter-ietf-nvo3-01-rev-2014090
> 1.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.
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:
> - 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.
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.
>
> 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.
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).
>
> 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
Better: Control Plane for Split-NVE case Adopted
> 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
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
