[Last-Call] Re: draft-ietf-rtgwg-multisegment-sdwan-13 ietf last call Genart review

[Linda Dunbar <[e-mail]>]

Russ,

Thank you very much for the detailed comments.
Please see the resolutions below marked by [Linda]. Let us know if they can address your concerns.

Linda

-----Original Message-----
From: Russ Housley via Datatracker <[e-mail]>
Sent: Friday, July 3, 2026 1:16 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: draft-ietf-rtgwg-multisegment-sdwan-13 ietf last call Genart review

Document: draft-ietf-rtgwg-multisegment-sdwan
Title: Multi-segment SD-WAN via Cloud DCs
Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.

For more information, please see the FAQ at <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C1774cc6d16344c25094e08ded9406c57%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C639187067889579127%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9ZTIfvE5UGtRSIaV8wQCO48SUfQV82U48r%2Bgd%2FgtKTQ%3D&reserved=0>.

Document: draft-ietf-rtgwg-multisegment-sdwan-13
Reviewer: Russ Housley
Review Date: 2026-07-03
IETF LC End Date: 2026-07-08
IESG Telechat date: unknown


Summary: Almost Ready


Major Concerns:

None


Minor Concerns:

Section 3.1: This solution is for customers that have already chosen SD-WAN, and this offers GENEVE as well.  Please avoid the comparison to other inter-connection services.

[Linda] How about the following wording change to emphasize that it is for customers that have already chosen SD-WAN:

Old:
      Stitching SD-WAN segments through a Cloud Gateway provides a way to extend policy enforcement and traffic control across branches, particularly when direct branch-to-branch paths over the public internet are insufficient
New:
      For customers that have already chosen SD-WAN, stitching SD-WAN segments through a Cloud Gateway provides a way to extend policy enforcement and traffic control across branches using their existing SD-WAN-to-cloud connectivity, while avoiding the need to establish separate direct branch-to-branch SD-WAN paths.

The first bullet is changed:

Old:
      The public internet between branches may suffer from limited bandwidth, unpredictable performance, and security risks
New:
      The public Internet path from a branch to its nearby Cloud GW is typically shorter and more controlled than an end-to-end public Internet path between branches, which can reduce exposure to unpredictable performance, limited bandwidth, and security risks.

Section 9.2: What hash function will be used with HMAC?
[Linda]  How about the following wording change:
Old:
      The specific hash algorithm is outside the scope of this document and is pre-configured and distributed by the controller together with the associated keying parameters
New:
      HMAC-SHA-256 [RFC4868] is the default algorithm used for computing the HMAC value. Other HMAC hash algorithms MAY be used when explicitly configured and distributed by the controller together with the associated keying parameters

Section 9.3: How are the keys set up?  IKEv2?
[Linda] How about adding a paragraph at the end of Section 9.2?

      When AH or ESP-NULL is used, the required IPsec SAs and associated keying material SHOULD be established using IKEv2 [RFC7296]. Deployments MAY use manual or controller-based key provisioning when supported by the operational environment, but such provisioning MUST provide equivalent authentication, authorization, replay protection, key freshness, and key rollover properties.

Nits:

Throughout: s/public internet/public Internet/
[Linda] changed.

Section 1: Please expand "Cloud DCs" on first use.
[Linda] added.

IDnits offers a suggestion:

  -- The document has examples using IPv4 documentation addresses according
     to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
     there should be IPv6 examples, too?

[Linda] Inserted the following in the "Conventions" Section:
      The IP addresses used in this document are for illustrative purposes only. IPv4 examples use addresses from the documentation blocks defined in [RFC5737] (192.0.2.0/24 and 198.51.100.0/24). All mechanisms described apply equally to IPv6, where equivalent examples would use addresses from the documentation prefix defined in [RFC3849] (2001:db8::/32).


Thank you very much,

Linda