Subject: [nvo3] Document shepherd review for draft-ietf-nvo3-framework-04.txt

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 2 Dec 2013 14:58:14 +0000

Authors,

Here are my comments on this draft. Please treat these as WG LC comments.

Regards

Matthew

I-D Nits
========

Please check ID-nits issues. I get the following:

idnits 2.13.00

tmp/draft-ietf-nvo3-framework-04.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == The page length should not exceed 58 lines per page, but there was 25
     longer pages, the longest (page 19) being 72 lines

  == It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 25 pages

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 314 instances of too long lines in the document, the longest
     one being 3 characters in excess of 72.

  == There are 4 instances of lines with non-RFC5735-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (November 12, 2013) is 20 days in the past.  Is this
     intentional?

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'OF' is mentioned on line 390, but not defined

  == Unused Reference: 'RFC2119' is defined on line 1065, but no explicit
     reference was found in the text

  == Unused Reference: 'OVCPREQ' is defined on line 1074, but no explicit
     reference was found in the text

     Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

General comments:
==================

[...]

    Abstract

       This document provides a framework for Network Virtualization over
       L3 (NVO3) and it defines a reference model along with logical
       components required to design a solution.

MB> Please expand 'L3'.

[...]

    1. Introduction

       This document provides a framework for Data Center Network

MB> Add (DC) abbreviation to 'Data Center'.

[...]

    1.1. General terminology

       This document uses the following terminology:

       NVO3 Network: An overlay network that provides an Layer2 (L2) or

MB> s/an/a

[...]

       environment that allows an operating system or application to be
       aware of the presences of virtualization for optimization purposes.

MB> s/presences>presence

[...]

    Internet-Draft  Framework for DC Network Virtualization      November
    2013

       that the network functional blocks in a DC fit in the architecture
       depicted in Figure 1.

       The following components can be present in a DC:

          o Access switch: Hardware-based Ethernet switch aggregating all
            Ethernet links from the End Devices in a rack representing the
            entry point in the physical DC network for the hosts. It may
            also provide routing functionality, virtual IP network
            connectivity, or Layer2 tunneling over IP for instance. Access
            switches are usually multi-homed to aggregation switches in the
            Intra-DC network. A typical example of an access switch is a
            Top of Rack (ToR) switch. Other deployment scenarios may use an
            intermediate Blade Switch before the ToR, or an EoR (End of
            Row) switch, to provide similar function as a ToR.

MB> s/similar function as / similar functions to

[...]

    2.1. Generic Reference Model

       Figure 2 depicts a DC reference model for network virtualization
       using L3 (IP/MPLS) overlays where NVEs provide a logical
       interconnect between Tenant Systems that belong to a specific VN.

MB> Please see comments from Lucy Yong on the following figure and fix accordingly.

             +--------+                                    +--------+
             | Tenant +--+                            +----| Tenant |
             | System |  |                           (')   | System |
             +--------+  |    .................     (   )  +--------+
                         |  +---+           +---+    (_)
                         +--|NVE|---+   +---|NVE|-----+
                            +---+   |   |   +---+
                            / .    +-----+      .
                           /  . +--| NVA |      .
                          /   . |  +-----+      .
                         |    . |               .
                         |    . |  L3 Overlay +--+--++--------+
             +--------+  |    . |   Network   | NVE || Tenant |
             | Tenant +--+    . |             |     || System |
             | System |       .  \ +---+      +--+--++--------+
             +--------+       .....|NVE|.........
                                   +---+
                                     |
                                     |
                           =====================
                             |               |
                         +--------+      +--------+
                         | Tenant |      | Tenant |
                         | System |      | System |
                         +--------+      +--------+

          Figure 2 : Generic reference model for DC network virtualization
                         over a Layer3 (IP) infrastructure

       In order to get reachability information, NVEs may exchange
       information directly between themselves via a protocol. In this
       case, a control plane module resides in every NVE. This is how
       routing control plane modules are implemented in routers for
       instance.

MB> The last sentences seem redundant. I suggest rephrasing the paragraph as follows:
       "In order to obtain reachability information, NVEs may exchange
       information directly between themselves via a control plane protocol. In this
       case, a control plane module resides in every NVE. "

[...]

       A Tenant System can be attached to an NVE in several ways:

         - locally, by being co-located in the same End Device

         - remotely, via a point-to-point connection or a switched network

       When an NVE is co-located with a Tenant System, the state of the
       Tenant System can be provided without protocol assistance. For

MB> I think you mean 'determined' rather than 'provided'.

       instance, the operational status of a VM can be communicated via a
       local API. When an NVE is remotely connected to a Tenant System, the
       state of the Tenant System or NVE needs to be exchanged directly or
       via a management entity, using a control plane protocol or API, or
       directly via a dataplane protocol.

MB> Do you mean an OAM protocol?

       The functional components in Figure 2 do not necessarily map
       directly to the physical components described in Figure 1. For
       example, an End Device can be a server blade with VMs and a virtual
       switch. A VM can be a Tenant System and the NVE functions may be
       performed by the host server. In this case, the Tenant System and
       NVE function are co-located. Another example is the case where the
       End Device is the Tenant System, and the NVE function can be
       implemented by the connected ToR. In this case, the Tenant System
       and NVE function are not co-located.

 [..]

    2.3.1. L2 NVE providing Ethernet LAN-like service

       An L2 NVE implements Ethernet LAN emulation, an Ethernet based
       multipoint service similar to an IETF VPLS or EVPN service, where

 MB> Please add references for VPLS and EVPN.

       the Tenant Systems appear to be interconnected by a LAN environment
       over an L3 overlay. As such, an L2 NVE provides per-tenant virtual
       switching instance (L2 VNI), and L3 (IP/MPLS) tunneling
       encapsulation of tenant MAC frames across the underlay. Note that
       the control plane for an L2 NVE could be implemented locally on the
       NVE or in a separate control entity.

 [...]

    3.1.5.2. Auto-provisioning/Service discovery

       NVEs must be able to identify the appropriate VNI for each Tenant
       System. This is based on state information that is often provided by
       external entities. For example, in an environment where a VM is a
       Tenant System, this information is provided by VM orchestration
       systems, since these are the only entities that have visibility of
       which VM belongs to which tenant.

       A mechanism for communicating this information to the NVE is
       required. VAPs have to be created and mapped to the appropriate VNI.
       Depending upon the implementation, this control interface can be
       implemented using an auto-discovery protocol between Tenant Systems
       and their local NVE or through management entities. In either case,
       appropriate security and authentication mechanisms to verify that
       Tenant System information is not spoofed or altered are required.
       This is one critical aspect for providing integrity and tenant
       isolation in the system.

       NVEs may learn reachability information to VNIs on other NVEs via a
       control protocol exchanging such information among NVEs or via a
       management control entity.

 MB> grammar / a control plane exchanging such information among NVEs or.. /
     a control plane that exchanges such information among NVEs, or ...

    3.1.5.3. Address advertisement and tunnel mapping

   [...]

       When a control plane protocol is used to distribute address
       reachability and tunneling information, the auto-
       provisioning/Service discovery could be accomplished by the same
       protocol. In this scenario, the auto-provisioning/Service discovery
       could be combined with (be inferred from) the address advertisement
       and associated tunnel mapping. Furthermore, a control plane protocol
       that carries both MAC and IP addresses eliminates the need for ARP,
       and hence addresses one of the issues with explosive ARP handling.

MB> Please can you explain this incendiary issue, or give a reference e.g. to the
problem statement.

    3.1.5.4. Overlay Tunneling

       For overlay tunneling, and dependent upon the tunneling technology
       used for encapsulating the Tenant System packets, it may be
       sufficient to have one or more local NVE addresses assigned and used
       in the source and destination fields of a tunneling encapsulating
       header. Other information that is part of the

MB> s/encapsulating/encapsulation

       tunneling encapsulation header may also need to be configured. In
       certain cases, local NVE configuration may be sufficient while in
       other cases, some tunneling related information may need to
       be shared among NVEs. The information that needs to be shared will
       be technology dependent. For instance, potential information could
       include tunnel identity, encapsulation type, and/or tunnel
       resources. In certain cases, such as when using IP multicast in the
       underlay, tunnels may need to be established, interconnecting
       NVEs. When tunneling information needs to be exchanged or shared

MB> s/interconnecting/which interconnect

       among NVEs, a control plane protocol may be required. For instance,
       it may be necessary to provide active/standby status information
       between NVEs, up/down status information, pruning/grafting
       information for multicast tunnels, etc.

       In addition, a control plane may be required to setup the tunnel
       path for some tunneling technologies. This applies to both unicast
       and multicast tunneling.

    3.2. Multi-homing

  [...]

       Multi-homing can be enabled in various nodes, from Tenant Systems
       into TORs, TORs into core switches/routers, and core nodes into DC
       GWs.

MB> s/TORs/ToRs ?

  [...]

       External connectivity out of a DC can be handled by two or more DC
       gateways. Each gateway provides access to external networks such as
       VPNs or the Internet. A gateway may be connected to two or more edge
       nodes in the external network for redundancy. When a connection to
       an upstream node is lost, the alternative connection is used and the
       failed route withdrawn.

MB> s/out of / from

    4.1. Pros & Cons

MB> please fix the formatting of sub-bullets below

       An overlay network is a layer of virtual network topology on top of
       the physical network.

       Overlay networks offer the following key advantages:

          o Unicast tunneling state management and association of Tenant
            Systems reachability are handled at the edge of the network (at
            the NVE). Intermediate transport nodes are unaware of such
            state. Note that when multicast is enabled in the underlay
            network to build multicast trees for tenant VNs, there would be
            more state related to tenants in the underlay core network.

          o Tunneling is used to aggregate traffic and hide tenant
            addresses from the underlay network, and hence offer the
            advantage of minimizing the amount of forwarding state required
            within the underlay network

          o Decoupling of the overlay addresses (MAC and IP) used by VMs
            from the underlay network for tenant separation and separation
            of the tenant address spaces from the underlay address space.

    Lasserre, et al.        Expires May 12, 2014                 [Page 18]

    Internet-Draft  Framework for DC Network Virtualization      November
    2013

          o Support of a large number of virtual network identifiers

       Overlay networks also create several challenges:

          o Overlay networks have typically no control of underlay networks
            and lack underlay network information (e.g. underlay
            utilization):

               o Overlay networks and/or their associated management
                 entities typically probe the network to measure link or
                 path properties, such as available bandwidth or packet
                 loss rate. It is difficult to accurately evaluate network
                 properties. It might be preferable for the underlay
                 network to expose usage and performance information.

               o
                Miscommunication or lack of coordination between overlay
                 and underlay networks can lead to an inefficient usage of
                 network resources.

               o
                When multiple overlays co-exist on top of a common underlay
                 network, the lack of coordination between overlays can
                 lead to performance issues and/or resource usage
                 inefficiencies.

          o Traffic carried over an overlay may not traverse firewalls and
            NAT devices.

MB> Belonging to the underlay?

  [...]

    4.2. Overlay issues to consider

          o Ingress replication

          o Use of underlay multicast trees

       There is a bandwidth vs state trade-off between the two approaches.
       Depending upon the degree of replication required (i.e. the number
       of hosts per group) and the amount of multicast state to maintain,
       trading bandwidth for state should be considered.

       When the number of hosts per group is large, the use of underlay
       multicast trees may be more appropriate. When the number of hosts is
       small (e.g. 2-3) and/or the amount of multicast traffic is small,
       ingress replication may not be an issue.

       Depending upon the size of the data center network and hence the
       number of (S,G) entries, but also the duration of multicast flows,
       the use of underlay multicast trees can be a challenge.

MB> s/but/and

       When flows are well known, it is possible to pre-provision such
       multicast trees. However, it is often difficult to predict
       application flows ahead of time, and hence programming of (S,G)
       entries for short-lived flows could be impractical.

       A possible trade-off is to use in the underlay shared multicast
       trees as opposed to dedicated multicast trees.

 [...]

    7. References

    7.1. Normative References

       [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

MB> I think you can remove this reference because you don't use any RFC2119 language.

    7.2. Informative References

       [NVOPS] Narten, T. et al, "Problem Statement : Overlays for Network
                 Virtualization", draft-narten-nvo3-overlay-problem-
                 statement (work in progress)

       [OVCPREQ] Kreeger, L. et al, "Network Virtualization Overlay Control
                 Protocol Requirements", draft-kreeger-nvo3-overlay-cp
                 (work in progress)

MB> you should probably add a draft version

       [FLOYD] Sally Floyd, Allyn Romanow, "Dynamics of TCP Traffic over
                 ATM Networks", IEEE JSAC, V. 13 N. 4, May 1995

       [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
                 Networks (VPNs)", RFC 4364, February 2006.

       [RFC1191] Mogul, J. "Path MTU Discovery", RFC1191, November 1990

       [RFC1981] McCann, J. et al, "Path MTU Discovery for IPv6", RFC1981,
                 August 1996

       [RFC4821] Mathis, M. et al, "Packetization Layer Path MTU
                 Discovery", RFC4821, March 2007