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

[Donald Eastlake <[e-mail]>]

Hi,

I've posted a -11 version that I believe resolves your comments.

On Fri, Nov 24, 2023 at 2:15 AM Qin Wu <[e-mail]> wrote:
> 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.

Thanks.

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

OK.

I've deleted some sections below where we are in agreement.

> -----邮件原件-----
> 发件人: 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:
> >
> > ...
>
> >  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.

OK, I'll add such a reference.

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

It's the shim that is a possible problem for offloading, not GPE. I'll
try to clarify the wording.

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

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.

OK.

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

OK.

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

I can change the sentence in question to "If we need a larger VNI,
perhaps for a telemetry case, an extension can be used to support
that."

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

I'll add a reference to Section 6.9 in the first point in Section 7.

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

I'm OK with your suggested wording and will change to it.

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

OK.

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

Yes. The plan is to close down the nvo3 WG so a RTGWG or AD sponsored
draft might be best. But I don't think that should be in this
document.

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