[nvo3] Opsdir last call review of draft-ietf-nvo3-encap-10

[Qin Wu via Datatracker <[e-mail]>]

Reviewer: Qin Wu
Review result: Has Nits

 This document can be seen as NVO3 encapsulation design team report and
 compares 3 typical data plane encapsulation formats including GENEVE, GUE,
 VXLAN-GPE and explores technical problem and limitation and provides guidance
 and recommendation for common encapsulation design. It also lays foundation
 for future extension to Geneve encapsulation defined in RFC8926.

 I believe it is well written and ready for publication, here are a few comments
 to v-(10) I would like author to consider:

Major issues:
 No

 Minor issues:
 1. Section 5.3 said
   "The B bit indicates the packet is an ingress replicated
   Broadcase, Unknown Unicast, or Multicast packet.  The O bit indicates
   an OAM packet.
   Issues with VXLAN-GPE [nvo3_vxlan_gpe] are as follows:"

   [Qin]: s/Broadcase/Broadcast
 2. Section 5.3 said:
   "
      *  Security, e.g., of the VNI, has not been addressed by GPE.
   "
   [Qin]: I am wondering how this statement is related to section 6.2.2? Do we
   need add rationale here to explain why security of VNI can be be addressed?
   e.g., can we use UDP checksum to protect the payload including VNI carried
   in VXLAN-GPE header? or UDP checksum is always set to zero? or can we extend
   VXLAN-GPE to carry HMAC-like Message Authentication Code (MAC)?

 3. Section 5.3 said:
   "
      Although a shim header could be used for security and other
      extensions, this has not been defined yet and its implications on
      offloading in NICs are not understood.
   "
   [Qin]: Can we add rationale why offloading in NIC is not understood, is this
   becos
        GPE is not extensible?
 4.Section 6.2.2 said:
   "
   This is desirable since we still have the UDP header for ECMP, the
   NVO3 header is in plain text so it can be read by network elements,
   and different security or other payload transforms can be supported
   "
   [Qin]:
   I can understand DTLS and IPSEC are two different security schemes.
   How do we understand transforms in the "payload transforms"?

 5. Section 6.3 said:
   "
   It is hard to predict which options will be implemented in which
   piece of hardware and when.  That depends on whether the hardware
   will be in the form of a NIC providing increasing offload
   capabilities to software NVEs, or a switch chip being used as an NVE
   gateway towards non-NVO3 parts of the network, or even a transit
   device that participates in the NVO3 dataplane, e.g., for OAM
   purposes.
   "
   [Qin] The second sentence seems too long, I think the key messages can be
   rephrased as three factors decides which options is implemented in which
   hardware? How about making the following change： " It is hard to predict
   which options will be implemented in which piece of hardware and when. That
   depends on: o whether the hardware will be in the form of a NIC providing
   increasing offload
     capabilities to software NVEs;
   o or a switch chip being used as an NVE gateway towards non-NVO3 parts of
   the network, o or even a transit device that participates in the NVO3
   dataplane, e.g., for OAM
     purposes.
         "
 6.Section 6.4 said:
   "
   The recommended minimum total svailable header length is 64 bytes.
   "
   [Qin]s/svailable/available

7.Section 6.6.  TLV versus Bit Fields
   [Qin]: If we have already decided to choose geneve as common encapsulation
   and geneve chooses to use TLV for extension. Why should we discuss comparison
   between TLV and Bit Fields.
   Should common encapsulation consideration only focus on TLV?

8. Section 6.7.  Control Plane Considerations
   [Qin] The 2nd paragraph of section 6.6 also discuss using control plane to
   control the order of the TLVs, which seems overlapping with section 6.7? Is
   this intentional?

9. Section 6.9
   If we need a larger VNI, an extension can
   be used to support that.
   [Qin]: In which case where we need a larger VNI？ Can we provide a use case
   to demonstrate the limitation of 24 bit VNI.

10.Section 7 said:
   "The DT studied whether VNI should be in the base header or in an
    extension header and whether it should be a 24-bit or 32-bit
    field."1.
   [Qin] Similarly, Not clear when we will use 32 bit field?

11.Section 7 said:
   "
   By using Geneve options it is
   possible to get in band parameters like switch id, ingress port,
   egress port, internal delay, and queue in telemetry defined
   extension TLV from switches.
   "
   [Qin] What is queue in telemetry defined extension TLV? Can not parse.
   Are you saying "queue in telemetry" defined in extension TLV?

12. Section 7 said:
   "
   9.  The DT has addressed the usage models while considering the
       requirements and implementations in general including software
       and hardware.

   "
   [Qin] Are usage models related to Useful Extensions Use Cases defined in
   Section 6.2? If Yes, please add referenced section.

13. With recommendation given in section 7, Do you think RFC8926 Geneve
Document needs
 to be revised as RFC8926bis document, or you expect for each extension for
 OAM, performance measurement, security, a separate document is needed to
 extend RFC8926 to support each extension?