Donald, The revision has been posted: https://datatracker.ietf.org/doc/draft-dmk-rtgwg-multisegment-sdwan/
Please let us know if the revision has addressed all your comments. Thank you very much. Linda From: Linda Dunbar Sent: Monday, September 18, 2023 3:38 PM To: Donald Eastlake <d3e...@gmail.com> Cc: nvo3@ietf.org; rt...@ietf.org; draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org Subject: RE: [nvo3] Need feedback on the GENEVE extension proposed in draft-dmk-rtgwg-multisegment-sdwan Donald, Thank you very much for the detailed comments and suggestions. Resolutions to your comments are inserted below. Linda From: Donald Eastlake <d3e...@gmail.com<mailto:d3e...@gmail.com>> Sent: Thursday, September 14, 2023 10:53 PM To: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Cc: nvo3@ietf.org<mailto:nvo3@ietf.org>; rt...@ietf.org<mailto:rt...@ietf.org>; draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org<mailto:draft-dmk-rtgwg-multisegment-sdwan.auth...@ietf.org> Subject: Re: [nvo3] Need feedback on the GENEVE extension proposed in draft-dmk-rtgwg-multisegment-sdwan Hi, Here is a review of this draft: ISSUES: Section 3.1: "unpredictable connection" occurs in this section but I think it needs at least one more word. It should be "unpredictable connection reliability" or "unpredictable connection performance" or "unpredictable connection x" for some x. [Linda] Changed to “unpredictable connection performance.” Section 3.1: "Cloud-based tools and SaaS can be easily utilized to collect and analyze the threat of traffic." I think "the threat of traffic" isn't right. Probably "the threats to traffic". [Linda] Changed. Section 3.4: I think this Section is not clear. Maybe something like the following? The branch office CPEs can maintain pairwise IPsec SA keying so that traffic between branch CPEs need not be decrypted and re-encrypted by the cloud GWs. [Linda] Yes. Change to the following: “This document describes the mechanisms for the IPsec encrypted traffic between CPEs to traverse the Cloud GWs without being decrypted and re-encrypted.” Section 4.2: IANA shouldn't be mentioned until the IANA Considerations section. Suggest replacing the first line of this section with "A new GENEVE Option Class tbd is used for Multi-segment SD-WAN." [Linda] changed to the following: “ A new GENEVE Option Class (Type value =TBD) is used to indicate that Multi-segment SD-WAN relevant Sub-TLVs are encoded in the GENEVE header.” Section 4.2 and 4.*: The names of the Sub-TLVs in the Section 4.2 diagram should correspond exactly to the Section titles for those Sub-TLVs and the occurences of the Sub-TLV name in the body text except that the word "Optional" should be omitted from the Section titles and where inappropriate in the text. [Linda] Changed. Section 4.3: Surely the transit node node or transit regions/zone either "SHOULD" or "MUST" decrement the TTL. "can decrement" seems kind of feeble. [Linda]Changed. Section 4.4: Why is it a "Tunnel Origin Endpoint" rather than just a "Tunnel Endpoint" Sub-TLV? [Linda] It is SD-WAN Tunnel Originator Sub-TLV Section 5.3: The references to RFCs 2403 and 2404 in Section 5.3 should be square bracketed references to entries for thos RFCs in the References section. I'm not sure this needs to list hash algorithms and in any case use of MD5 and SHA-1 is mostly deprecated. [Linda] changed to “SHA2 224/256/384/512 and SHA512 are some of the cryptographic hashing algorithms.” Section 5.5, first paragraph: "should" -> "SHOULD" Sections 8 and 10 are obviously incomplete at this point. [Linda] We will add later. Section 9.2 is not well enough specified to assure interoperability. You can't just say that the HMAC covers the whole GENEVE header when the HMAC value is inside the GENEVE header. Is it zeroed or pinched out or what when you compute the HMAC? [Linda] changed the text to the following: “The HMAC Authentication Code, a.k.a. the HMAC hash value, is computed including all the bytes in the GENEVE header and with the MultiSDWAN-HMAC value field setting to 0.” Section 11: Here is a complete replacement for the IANA Considerations section, although you might want a different assignment policy for the new registry and might not agree with my choice of reserved values: IANA is request to assign a new GENEVE Option Class from the IETF Review range as shown below: Option Class Description Assignee/Contact Reference ------ ------------------- ---------------- --------------- tbd Multisegment SD-WAN IETF [this document] IANA is requested to create a registry as below with the initial values shown in the Geneve Option Class registry group: Registry: Multisegment SD-WAN Sub-TLVs Assignment Policy: IETF Review Reference: [this document] Sub-TLV Type Description Reference ------------ ---------------------- --------------- 0 Reserved 1 SD-WAN Endpoint [this document] 2 SD-WAN Origin Endpoint [this document] 3 SD-WAN Egress GW [this document] 4 Multi SD-WAN-HMAC [this document] 5-254 Unassigned 255 Reserved [Linda] thank you. Changed to your suggested wording. TYPOs ETC: Section 1, 1st paragraph: the reference [Net2Cloud] does not seem to actually link to the References section. At least, when I look at the htmlized version of the draft, it is not a link as other references are. [Linda] changed. Section 2: Same as the comment above for reference to [https://en.wikipedia.org/wiki/Internet_exchange_point]. You could just have that URL in parenthesis. If it is going to be a square bracketed reference, in my opinion it should really link to an entry in the References. [Linda] changed. Should probably expand "SaaS" on first use or include it in the acronym list in Section 2. [Linda] added. In Sections 4, through 4.5, probably the diagrams should have Figure numbers and captions. [Linda] Added. Looking at the html version, Section 4.7 doesn't seem to be recognized as a Section in the text body. At least its number isn't highlighted like other section numbers. [Linda] the draft is uploaded as *.txt version. Section 5.4: "cloud GW do the following" -> "could GW does the following" [Linda] Changed. Section 7: Suggest making the Section name "Control Plane Considerations" Section 7.1: [SDWAN-Edge-Discover] and [SD-WAN-Edge-Discovery] do not seem to be real references linking to entries in the References section. [Linda] changed. Section 9.1: Suggest replacing the "&" in the first paragraph with "and". [Linda] Changed. Suggest globally replacing "on-prem" with "on-premises". [Linda] changed. I don't know why the first line of Sections 8, 9.1, 9.2, and 9.3 is in bold face. Maybe there needs to be a blank line between the heading of the first line of text. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com<mailto:d3e...@gmail.com> On Thu, Aug 31, 2023 at 4:32 PM Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> wrote: NVO3 participants, This draft proposes to extend GENEVE to get SD-WAN traffic (IPsec encrypted) across the Cloud backbone without Cloud GWs decrypting the traffic: https://datatracker.ietf.org/doc/draft-dmk-rtgwg-multisegment-sdwan/ The traffic between the CPEs is encrypted by the IPsec SAs maintained by the CPEs. As the traffic from the enterprise’s CPEs doesn’t terminate within the Cloud DCs, the goal is to eliminate the decryption and re-encryption processing burden on Cloud GWs for the IPsec encrypted traffic from one CPE via Cloud GWs to another. For Cloud GWs to differentiate the packets destined towards their internal hosts/services, which require decryption, and transit packets to be forwarded to the respective destination branch CPEs, proper marking is needed in the packets’ header. As the GENEVE Encapsulation [RFC8926] is supported by most Cloud Service Providers, GENEVE is chosen as the encapsulation header for Cloud GWs to steer IPsec encrypted packets among CPEs without decryption. We would like to get feedback from NVO3 group about the proposed method. Thank you very much! Linda _______________________________________________ nvo3 mailing list nvo3@ietf.org<mailto:nvo3@ietf.org> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
