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.
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".
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.
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."
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.
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.
Section 4.4: Why is it a "Tunnel Origin Endpoint" rather than just a
"Tunnel Endpoint" 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.
Section 5.5, first paragraph: "should" -> "SHOULD"
Sections 8 and 10 are obviously incomplete at this point.
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?
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
*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.
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.
Should probably expand "SaaS" on first use or include it in the acronym
list in Section 2.
In Sections 4, through 4.5, probably the diagrams should have Figure
numbers and captions.
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.
Section 5.4: "cloud GW do the following" -> "could GW does the following"
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.
Section 9.1: Suggest replacing the "&" in the first paragraph with "and".
Suggest globally replacing "on-prem" with "on-premises".
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
On Thu, Aug 31, 2023 at 4:32 PM Linda Dunbar <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
> https://www.ietf.org/mailman/listinfo/nvo3
>
_______________________________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
