[bmwg] Comments on draft-skommu-bmwg-nvp-02

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Samuel and Jacob,

below are the comments I promised on your draft
(most sections through 5). 

regards,
Al
(as a participant)

       2. Conventions used in this document
[acm]
There's a new version of this paragraph, see RFC 8137 

             The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
             "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
             document are to be interpreted as described in RFC 2119 [RFC2119].
the new version clarifies that capitalization is needed for requirements,
and includes the word "NOT RECOMMENDED".


           Segment 1                      Packet 1
             +-------------------------+    +-------------------------+
             | Headers                 |    | Headers                 |
             | +---------------------+ |    | +---------------------+ |
             | | Pay Load - upto 64K | |    | | Pay Load < 1500     | |
             | +---------------------+ |    | +---------------------+ |
             +-------------------------+    +-------------------------+
[acm] s/Pay Load/Payload/


            Hence, normal benchmarking methods are not relevant to the NVPs.
[acm]
So far, the only differences I see are 
- TSO for TCP (layer 4) 
- LRO with large payloads.

But we've dealt with Stateful traffic before (TCP connections in Firewalls).
I need to think about how 64k packets affects what we do, it certainly makes
BW the main event, and not header-processing rate.
Essentially, I'm looking to help add more definition and differentiation
for the Scope of this draft.


             With Micro-services architecture, a single web app of the three tier
             application model could now have 100s of smaller apps dedicated to
             do just one job.

             These 100s of small one responsibility only services will MUST be
             secured into their own segment - hence pushing the scale boundaries
             of the overlay from both simple segmentation perspective and also
             from a security perspective.
[acm]
Micro-services means a fairly complete departure from the 
monolithic architectures of the past.  Some include 
Micro-services as an aspect of Cloud-native NFV, where
containers are king  (although, you haven't mentioned
containers yet, why not?). So there is some NVP-NFV overlap 
here, too.

        4. Scope

             This document does not address Network Function Virtualization has
             been covered already by previous IETF documents
             (https://datatracker.ietf.org/doc/draft-ietf-bmwg-virtual-
             net/?include_text=1) the focus of this document is Network
             Virtualization Platform where the network functions are an intrinsic
             part of the hypervisor's TCP stack, working closer to the
             application layer and leveraging performance optimizations such
             TSO/RSS provided by the TCP stack and the underlying hardware.
[acm]
Is this really a hypervisor, or a container management system?


[acm] the next sentence is a key one for the comment that follows:
             ... Because of the nature of
             virtual infrastructures and multiple elements being hosted on the
             same physical infrastructure, influence from other components cannot
             be completely ruled out.  For example, unlike in physical
             infrastructures, logical routing or distributed firewall MUST NOT be
             benchmarked independent of logical switching. System Under Test
             definition MUST include all components involved with that particular
             test.

        Kommu & Rapp             Expires December 27, 2018              [Page 8]

        Internet-Draft        NVP Benchmarking Considerations         June 2018

             +---------------------------------------------------+
             | System Under Test                                 |
             | +-----------------------------------------------+ |
             | | Hyper-Visor                                   | |
             | |                                               | |
             | |                +-------------+                | |
             | |                |     NVP     |                | |
             | | +-----+        |    Switch/  |        +-----+ | |
             | | | VM1 |<------>|   Router/   |<------>| VM2 | | |
             | | +-----+   VW   |  Fire Wall/ |   VW   +-----+ | |
             | |                |     etc.,   |                | |
             | |                +-------------+                | |
             | | Legend                                        | |
             | | VM: Virtual Machine                           | |
             | | VW: Virtual Wire                              | |
             | +------------------------_----------------------+ |
             +---------------------------------------------------+
                                    Figure 2  Intra-Host System Under Test
[acm] Figure 2 is not realistic IMO, there should be at least one
Physical Interface in the path under test. Further, this is exactly the 
sort of testing discussed in RFC 8204 (and the controversial 
China Mobile draft that used VM traffic Generators).
(I think we have used NFVI (Infrastructure) synonymously with your NVP.)


[acm] Need to show the Physical NICs in Figure 3
        Kommu & Rapp             Expires December 27, 2018              [Page 9]

        Internet-Draft        NVP Benchmarking Considerations         June 2018

             +---------------------------------------------------+
             | System Under Test                                 |
             | +-----------------------------------------------+ |
             | | Hyper-Visor                                   | |
             | |                +-------------+                | |
             | |                |     NVP     |                | |
             | | +-----+        |    Switch/  |        +-----+ | |
             | | | VM1 |<------>|   Router/   |<------>| VM2 | | |
             | | +-----+   VW   |  Fire Wall/ |   VW   +-----+ | |
             | |                |     etc.,   |                | |
             | |                +-------------+                | |
             | +------------------------_----------------------+ |
             |                          ^                        |
             |                          | Network Cabling        |
             |                          v                        |
             | +-----------------------------------------------+ |
             | |       Physical Networking Components          | |
             | |     switches, routers, firewalls etc.,        | |
             | +-----------------------------------------------+ |
             |                          ^                        |
             |                          | Network Cabling        |
             |                          v                        |
             | +-----------------------------------------------+ |
             | | Hyper-Visor                                   | |
             | |                +-------------+                | |
             | |                |     NVP     |                | |
             | | +-----+        |    Switch/  |        +-----+ | |
             | | | VM1 |<------>|   Router/   |<------>| VM2 | | |
             | | +-----+   VW   |  Fire Wall/ |   VW   +-----+ | |
             | |                |     etc.,   |                | |
             | |                +-------------+                | |
             | +------------------------_----------------------+ |
             +---------------------------------------------------+
             Legend
             VM: Virtual Machine
             VW: Virtual Wire

                                    Figure 3  Inter-Host System Under Test