Subject: [nvo3] I-D Action: draft-ietf-nvo3-hpvr2nve-cp-req-10.txt

From: [email-masked]
Date: Thu, 26 Oct 2017 23:28:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Virtualization Overlays WG of the IETF.

        Title           : Split-NVE Control Plane Requirements
        Authors         : Yizhou Li
                          Donald Eastlake
                          Lawrence Kreeger
                          Thomas Narten
                          David Black
	Filename        : draft-ietf-nvo3-hpvr2nve-cp-req-10.txt
	Pages           : 24
	Date            : 2017-10-26

Abstract:
   In a Split-NVE architecture, the functions of the NVE (Network
   Virtualization Edge) are split across a server and an external
   network equipment which is called an external NVE.  The server-
   resident control plane functionality resides in control software,
   which may be part of a hypervisor or container management software;
   for simplicity, this draft refers to the hypervisor as the location
   of this software.

   Control plane protocol(s) between a hypervisor and its associated
   external NVE(s) are used by the hypervisor to distribute its virtual
   machine networking state to the external NVE(s) for further handling.
   This document illustrates the functionality required by this type of
   control plane signaling protocol and outlines the high level
   requirements. Virtual machine states as well as state transitioning
   are summarized to help clarify the needed protocol requirements.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-nvo3-hpvr2nve-cp-req-10
https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-hpvr2nve-cp-req-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-hpvr2nve-cp-req-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 29 Oct 2017 10:58:09 -0400

Looking at draft-ietf-nvo3-hpvr2nve-cp-req-10, there is

   Req-12: The protocol MUST be able to run over L2 links between the
   End Device and its External NVE.

This seems to envision a scenario where the networking services provided
to the Tenant Systems are layer 2 (virtualized Ethernet) and it's
expected that the trunk between the tVNE and the nVNE will be at layer
2.

However, logically, the situation seems to be much more general than
that.  It looks like it's quite possible to do the tVNE/nVNE trunking at
layer 3.  It also allows provisioning of VN services to the TS at
multiple layers.  For instance, if the TS VM is a "container", it's
quite possible that the TS receives only layer 3 services.  And for a
more service-oriented architecture, the TS network attachment may be at
layer 4 or higher.

None of these possibilities seem to affect the structure of the
tVNE/nVNE protocol, other than that the address families of the network
identifiers passed in the protocol vary.  (These are the identifiers in
both the "overlay" family, the service provided to the TS, and in the
"underlay" family, the trunking connection.)

So it seems to me that we could gain considerable generality at little
cost by changing Req-12 to something like:

   Req-12a: The protocol MUST be configurable to run over links of any
   particular networking protocol between the End Device and its
   External NVE.

   Req-12b: The protocol MUST be configurable to support network
   services at any particular layer to Tenant Systems.

In practice, this only requires that addresses contained in the protocol
are tagged with address families, or that the configuration of the
protocol instance is understood to include the address family
information.

Dale