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

[Qin Wu <[e-mail]>]

Hi, Donald:
Thanks for promptly answer and clarification, I think this draft is useful work and could serve foundation for many future work to improve interoperability, even though it has been progressed for years.
I think even some of my questions are related to reasoning of the design team, it will be interesting to call out these reasons if possible which really help new readers and later follower navigate
through the history of encapsulation and see they are evolved, shed a light on some potential future work. A few follow up comments in line below.
-----邮件原件-----
发件人: Donald Eastlake [mailto:[e-mail]] 
发送时间: 2023年11月24日 12:40
收件人: Qin Wu <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Re: Opsdir last call review of draft-ietf-nvo3-encap-10

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.

[Qin Wu] If this statement is related to section 6.2.2, maybe adding reference to specific paragraph of section 6.2.2 will be useful to help reader understand the reasoning.

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

[Qin Wu] As new reader to this paragraph, what I found is Geneve encapsulation defined in RFC8926 supports offloading in NICs while GPE not, but I don't know why, if this is outcome of design team analysis, maybe add some text to say based on design team analysis at that time, offloading in NICs are not understood.
>  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.

[Qin Wu] Clear. Transform is a strange wording. But never mind.
>  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.

[Qin Wu] Works for me.
> 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.

[Qin Wu] I have no strong opinion about this, happy to leave this to author.

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

[Qin Wu] I still feel use case is not clear, e.g., if you tell me that in telemetry case, we need larger VNI, I will be convinced, but the current text is very brief, can not figure out the use case or motivation.

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

[Qin Wu] The proposed is much better, still wording needs further improvement, e.g.,
OLD TEXT:
"
    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.
"
NEW TEXT:
"
    By using Geneve options it is
    possible to get in band parameters like switch id, ingress port,
    egress port, internal delay, and queue size using 
    TLV extension for telemetry purpose from switches.
"
> 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)".

[Qin Wu] The proposed change looks good.
> 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.

[Qin Wu] Tend to agree, I just think it might be useful for this document to provide hint for the developers or implementers who want to propose some extension to geneve, 
how to proceed their work in the future. If authors strongly believe it is beyond scope for this document, I can live with this.

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