Hi, I've posted a -11 version that I believe resolves your comments. On Fri, Nov 24, 2023 at 2:15 AM Qin Wu <bill.wu@xxxxxxxxxx> 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:d3e3e3@xxxxxxxxx] > 发送时间: 2023年11月24日 12:40 > 收件人: Qin Wu <bill.wu@xxxxxxxxxx> > 抄送: ops-dir@xxxxxxxx; draft-ietf-nvo3-encap.all@xxxxxxxx; last-call@xxxxxxxx; nvo3@xxxxxxxx > 主题: 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 > <noreply@xxxxxxxx> 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 +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
