Some of your answers address the raised concerns. However, some of them
indicate I was insufficiently clear, as they do not address the issue.
I will not in line where things are fine,a nd where I think there is
still a problem. I will delimit my comments with <jmh></jmh> in case of
indenting problems.
Yours,
Joel
On 7/17/2025 9:12 PM, Linda Dunbar wrote:
Joel,
Thank you very much for reviewing the document and the valuable feedback.
Please see below for the detailed resolutions.
If they are okay with you, we can upload the revision on Monday.
Linda
-----Original Message-----
From: Joel Halpern via Datatracker <nore...@ietf.org>
Sent: Thursday, July 17, 2025 10:46 AM
To: rtg-...@ietf.org
Cc: draft-ietf-rtgwg-multisegment-sdwan....@ietf.org; rtgwg@ietf.org
Subject: draft-ietf-rtgwg-multisegment-sdwan-04 early Rtgdir review
Document: draft-ietf-rtgwg-multisegment-sdwan
Title: Multi-segment SD-WAN via Cloud DCs
Reviewer: Joel Halpern
Review result: Not Ready
Hello
I have been selected to do a routing directorate “early” review of
this draft.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-multisegment-sdwan%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415554778%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0rGQhV01eJsDerr6g1jxCzUIkhF5vlwTPOohcWDo3%2Bg%3D&reserved=0
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-multisegment-sdwan%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415554778%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0rGQhV01eJsDerr6g1jxCzUIkhF5vlwTPOohcWDo3%2Bg%3D&reserved=0>
The routing directorate will, on request from the working group chair,
perform an “early” review of a draft before it is submitted for
publication to the IESG. The early review can be performed at any time
during the draft’s lifetime as a working group document. The purpose
of the early review depends on the stage that the document has reached.
This draft describes the extensions to Geneve to enable using it to
interconnect multiple SD-WAN segments, with particular attention to
the case when the carried payload is IPSec protected.
For more information about the Routing Directorate, please see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415582636%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rne%2Fx6T0XCvkiaZPqAx%2F6%2BWGFFOY7%2FXs9tPq%2BmBi5G4%3D&reserved=0
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cde59685e54d84193978008ddc559be0d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638883711415582636%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rne%2Fx6T0XCvkiaZPqAx%2F6%2BWGFFOY7%2FXs9tPq%2BmBi5G4%3D&reserved=0>
Document: draft-ietf-rtgwg-multisegment-sdwan-04
Reviewer: Joel Halpern
Review Date: 17-July-2025
Intended Status: Proposed Standard
Summary:
I have some minor concerns about this document that I think should be
resolved before it is submitted to the IESG. I also have one major
concern that was flagged by I-D nits. And one major concern where a
procedural element does nto sem to work.
Major issues: The example topologies use all sorts of IP v4
addresses. It should use exclusively example addresses. And mixing
private and public IP addresses in examples is even more confusing.
(Note that this problem might be slightly easier to address if all
examples were IPv6 instead of IPv4.)
[Linda] Changed to use example IP addresses per RFC5737 for all the
client addresses attached to CPEs: 192.0.2.0/24 and 198.51.100.0/24;
Do you think adding the following Note at the end of the Introduction
section would be enough?
/"Note: All IP addresses used in this document are for illustrative
purposes only. They are drawn from address blocks designated for use
in documentation as specified in [RFC5737] and [RFC3849], and do not
represent real or routable network addresses."/
<jmh>I do not think there is a need for the paragraph if example
addresses are used. I do note that the IESG frequently complains if
there is no use of IPv6 in examples, but that is up to you and the
working group. </jmh>
Section 4.5 on including specific SD-WAN transitsegments eems an
understandable goal. However, it also seems fraught with failure
potential. In simple topologies, yes, it works. But suppose that the
actual path to the destination is SD-WAN segments A-B-C-D-E. And
suppose
the include requirement says "B". When the GENEVE packet arrives
at the
C-D boundary, it says that its path must include B. But the path
to the
destination from there does not include B. How is the C-D boundary
supposed to know that B has alreay been traversed?
[Linda] Some SD-WAN deployments require specific transit segments to
be included in the end-to-end path for regulatory, security, or
service chaining purposes, rather than for path optimization. The
Include-Transit Sub-TLV, an optional field, is used to signal such
requirements. It allows explicitly specifying a list of Cloud
Availability Regions or Zones that a packet must traverse when
forwarded through the Cloud Backbone.
<jmh> I apparently did not explain my concern well enough. I understand
why one would want to mandate that a (or several (specific SD-WAN are
traversed. (I could debate the utility, but operators and customers
often want things I wonder about.) That is not the source of my
concern. It is unclear who is expected to enforce the mandatory
traverse case, and how loops are avoided. Suppose that SD-WAN A is
connected to SDS-WAN B, which is connected to SD-WAN C and D. And D is
connect to SD-WAN B and E, where the egress exists. A Geneve packet is
sent with an include indicating that SD-WAN B must be traversed. The
packet happens to go theorugh SD-WAN A to SD-WAN B (meeting the
traversal requirement), then to SD-WAN C, and then to the SD-WAN D.
However, by the time the packet arrives at SD-WAN D, there is no
indication in the packet that it went through SD-WAN B. WHich would
seem to require D to send the packet back to SD-WAN B. Which is clearly
not what is desired. How does the gateway to SD-WAN D know that it si
fine to keep forwarding towards the destination (egress from E) rather
than returning the packet to B? I could understand how it worked if
there was also a route record. Or if the Include was removed once it
was satisfied. But the draft does not call for either of those
behaviors. </jmh>
Minor Issues:
The description of SD-WAN in the second paragraph of the
introduction could
use some clarification. The text reads: "Multi-segment SD-WAN
refers to
SD-WAN deployments where different segments-such as branch
offices, cloud
regions, and data centers" But a branch office is a location. It
is not
an SD-WAN segment. Some set of branch offices might be
interconnected by
an SD-WAN segment, but that is not what this text says. I think a
multi-segment SD-WAN is simply several SD-WAN services from several
providers with a means (unclear from whom) to interconnect those
SD-WAN
services? The text later refers to a backbone network, which seems to
imply a more specific structuring for this interconnection. If so, a
description or reference would seem appropriate.
[Linda] How about revising the second paragraph to the following:
/Multi-segment SD-WAN refers to deployments where multiple SD-WAN
segments—such as those connecting branch CPE to cloud gateways—are
used together to form an end-to-end service path. These segments may
be independently //managed//by different service providers,
enterprises, or cloud operators. A Cloud Backbone—typically operated
by a cloud provider or network service //provider//—acts as the
interconnect fabric that stitches these segments together. This
architecture is often necessary when enterprises span multiple
geographic regions, use different SD-WAN vendors, or have regulatory
constraints requiring segmented traffic management. /
/<jmh> That seems to fix the problem. </jmh>/
Section 3.1 reads more as a marketing section for SD-WAN. This
draft, as I
understand it, is for the case where the customer has already
chosen to use
an SD-WAN, and wants the added benefits of the GENEVE traffic
directing
encapsulation. So stick to that. Don't talk about hypothetical
stability
benefits of SD-WAN as compared with other inter-connection services.
[Linda] How about the following text for Section 3.1?
/Enterprise branches with established SD-WAN paths to a Cloud GW for
accessing cloud services can also use the Cloud GW to interconnect
with one another, as shown in Figure 1.////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. This
approach is beneficial for several reasons:/
* /The public internet between branches may suffer from limited
bandwidth, unpredictable performance, and security risks//./
* /Centralized enforcement of enterprise security policies is
possible through cloud-hosted security services (e.g., firewalls,
DDoS protection), ensuring consistent treatment of traffic across
sites./
* /Cloud platforms often offer enhanced monitoring, proprietary
threat detection tools, and analytics services that can inspect
and respond to suspicious traffic crossing segments./
<jmh>Personally, I would simply cite other documents on why SD-WAN is
desirable, and leave out the promotional material. If you feel you must
include it, then yes, this is an improvement. </jmh>
Section 4.3 discusses the origin identification sub-TLV. Having
such a
sub-TLV seems reasonable. However, the text in explaining the
reason says
"These policies may include routing optimization based on the
origin,". I
have trouble understanding under what circumstance, given taht the
packet
is at the processing gateway, knowledge of the origin can enable
any more
optimal route selection than would otherwise be available. I can
understand that paths may be restricted to certain sources by
policy, but
that is not an optimization.
[Linda] How about the following wording changes?
Old:
These policies may include routing optimization based on the origin,
security enforcement tailored to the source, or traffic engineering
rules specific to the originating CPE.
New:
/These policies may include traffic engineering rules specific to the
originating CPE, security enforcement tailored to the source, or path
selection constraints based on the origin./
<jmh>Yes, thank you. </jmh>
Section 4.4 on the egress gateway identifier again asserts taht
allowing
the source CPE to specify the egress gateway optimizes path
selection. It
seems difficult to construct cases where that will optimize, and
easy to
construct cases where it will make things worse. It may again be
desirable
for policy reasons. But let's not conflate policy with optimization.
[Linda] How about changing the text to the following:
Old:
This ensures predictable routing and optimized packet delivery across
the Cloud Backbone
New:
/This ensures predictable routing behavior and enables policy-driven
packet delivery across the Cloud Backbone.//./
<jmh>Yes, thank you. </jmh>
I presume that the processing SD-WAN gateway logic in section 5
includes
checking for the SD-WAN option class being present, as this draft
does not
otherwise apply? Shouldn't the text include that check?
[Linda] Good catch. How about adding this sentence to Section 5:
/The procedures described in this section apply only to packets that
carry the SD-WAN Option Class in the GENEVE header. Packets without
this option are processed using default forwarding behavior./
<jmh>Yes, Thank you.</jmh>
In section 5, in describing the Ingress GW processing, the text is
written
as if the outer IP destination address will always become the egress
gateway. As I understand it, if the path goes through multiple
SD-WAN, the
outer IP address at each stage is that of the next gateway? Could
the text
be rewritten to make that clear. Also, doesn't this imply there is a
"transit gateway" case as well as ingress and egress?
[Linda] The GENEVE header remains during transit across the Cloud
Backbone and is removed by the egress Cloud Gateway before the packet
is forwarded to the destination CPE. The packet is forwarded natively
on the final SD-WAN segment (egress GW to destination CPE) without
GENEVE encapsulation.
<jmh>I am still missing something. It may be that I am misunderstanding
the interaction between mutli-segment SD-WAN and GENEVE. Suppose that we
have GW1 - SDWAN A - GW 2 - SDWAN B - GW-3. When the packet arrives at
GW-1 with the multi-segment SD-WAN option, GW1 decides (subject to the
constraints of the options in the packet) that the packet should go to
GW2 in orderr to get to GW3. As I understand it, GW1 will replace the
outer IP destination (which was GW-1 upon arrival) with the IP address
of GW2. But the text says that it will replace the destination address
with the egress IP address (GW-3, or maybe something beyond that.) </jmh>
I do not know if this is a major concern, a minor concern, or merely a
confused reviewer. There is a description in section 9 of an
attack to
steal data service (conceptually, an understandable problem.)
However, I
am unable to figure out what set of access to what set of places the
attacker must have, nor how adding authentication to the CPE / GW
exchange
would actually help prevent this attack. In part this is because the
attack appears underspecified, and in part this is because the
remediation
appears underspecified.
[Linda] does it help to add this sentence to the introduction?
/In this document, “multi-segment SD-WAN” refers specifically to
deployments with two SD-WAN edge segments: one from the originating
CPE to the ingress Cloud Gateway, and one from the egress Cloud
Gateway to the destination CPE. There may be additional SD-WAN
segments or forwarding domains between the ingress and egress Cloud
Gateways across the Cloud Backbone, but their internal behavior is out
of scope for this specification./
<jmh>Nope, sorry. That does not tell me what the security threat is
that leads to wanting authentication. It also does not tell me how the
authentication is actually to be done. (I naive reading is that you are
inventing an authentication extension, with insufficient specificity, to
some unspecified protocol between the CPE and the first SD-WAN gateway.)
</jmh>
Section 11 on IANA consideration should note that IANA has already
assigned
the code point. Otherwise, specifying the value would be improper.
[Linda] Changed.
<jmh>Thanks.</jmh>
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
