Re: [Last-Call] Opsdir last call review of draft-ietf-nvo3-encap-10

[Donald Eastlake <[e-mail]>]

Thanks for your thorough review.

However, I think a few of your questions are not really about document
quality but rather about the reasoning of the Design Team. I was not a
member of the Design Team so I cannot answer those questions.

On Wed, Nov 22, 2023 at 4:14 AM Qin Wu via Datatracker <[e-mail]> wrote:
>
> 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 problems and limitations 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

OK.

>  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)?

I don't think UDP checksum helps if someone is modifying a packet or
forging a packet as they can just modify or calculate the UDP checksum
appropriately for the packet content they want.

It would be possible to extend some nvo3 candidate encapsulations but
the design team concluded that, as currently specified, VXLAN-GPE does
not provide for extension. Of course, VLAN-GPE could be combined with
a NSH and extended that way but so could almost anything.

>  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
>    because GPE is not extensible?

I would say that it is not understood because it has not been
investigated sufficiently. This section is talking about adding a shim
supporting security to the nvo3 headers along with VXLAN-GPE and using
that to "extend" for security. I don't think that possible
difficulties / complexities in offload have much to do with VXLAN-GPE
not being 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"?

IPsec is one type of "payload transform". I think this section is
saying that you can send nvo3 packets with different "payload
transforms" to the same destination port because they can be
distinguished by the Next Protocol field or other information in the
VXLAN-GPE header.

>  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.
>          "

Sure, I can make that into a list as you suggest.

>  6.Section 6.4 said:
>    "
>    The recommended minimum total svailable header length is 64 bytes.
>    "
>    [Qin]s/svailable/available

OK.

> 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?

This report is the conclusion of the Design Team from a time before
GENEVE was chosen.

> 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?

I do not see it as a problem that this consideration is mentioned in
both 6.6 and 6.7.

> 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.

If the number of logical tenants exceeds 2**24 or if VNI identifiers
where assigned in a hierarchical (see [RFC1715]) or otherwise less
efficient manner.

> 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?

See my answer immediately above.

> 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?

I believe it should say "queue size" rather than "queue".

> 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.

I think point 9 is just supposed to be a general catch-all. I will
replace "usage models" with "usage requirements (see Section 6)".

> 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?

This is a purely speculative question about my opinion as to the
process alternatives. I don't see what it has to do with whether or
not this draft is approved.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]