Hi Linda，
I have reviewd draft-ietf-rtgwg-multisegment-sdwan-07, as its shepherd I think
it is well written. Also, I have the following comments,
1) A definition of "Cloud backbone" should be added upon it first appears in
this draft. An example is given as below,
The term of "Cloud backbone" refers to a high-speed network
infrastructure that provides connectivity and communication between cloud data
centers and other network endpoints.
2) Figure 1 and Figure 2 appear somewhat abstract. If possible, it is
recommended to optimize them to make them more intuitive and visually appealing.
3) In section 3, there is ,
"To address this issue, this document proposes a method where
Cloud GWs explicitly interconnect SD-WAN segments, ensuring
that branch-to-branch traffic is steered through the Cloud
Backbone rather than taking unpredictable Internet routes."
[Chongfeng]: It is proposed to change "unpredicatable" into "conventional
destination address based"
4) in section 4.1,
"Type = 2: Multi-hop transit SD-WAN with an explicitly
specified egress Cloud GW (via Sub-TLV )."
[Chongfeng]: I guess the "Sub-TLV" is Egress GW Sub-TLV, if my guess is
right, can it be changed to " Egress GW Sub-TLV defined in section 4.4"?
5）In figure 4，
I guess the field of “SD-WAN Dst Addr Family ”should changed be "SD-WAN
End Point Address Family".
6) For the defintion of TTL in section 4.2, is there any specific meaning by
using "logical", if not, it is recommend to be removed.
7) In section 4.5,
The first field at the format of the Restricted Regions Sub-TLV should be
changed to "Restricted Regions", to maintain consistency with the preceding
format definitions.
8) In section 4.6,
For the same reason, the first field at the format of the Exclude Transit
Sub-TLV should be changed to "Exclude Transit".
Please feel free to contact me if you have any questions regarding the above
comments.
Best regards
Chongfeng
China Telecom
From: 【外部账号】Linda Dunbar
Date: 2025-09-11 14:19
To: Gabriele Galimberti; ops-...@ietf.org
CC: draft-ietf-rtgwg-multisegment-sdwan....@ietf.org; rtgwg@ietf.org
Subject: RE: draft-ietf-rtgwg-multisegment-sdwan-07 early Opsdir review
Gabriele,
Thank you very much for the review. Below are the responses to your comments.
Linda
-----Original Message-----
From: Gabriele Galimberti via Datatracker <nore...@ietf.org>
Sent: Tuesday, September 9, 2025 8:51 AM
To: ops-...@ietf.org
Cc: draft-ietf-rtgwg-multisegment-sdwan....@ietf.org; rtgwg@ietf.org
Subject: draft-ietf-rtgwg-multisegment-sdwan-07 early Opsdir review
Document: draft-ietf-rtgwg-multisegment-sdwan
Title: Multi-segment SD-WAN via Cloud DCs
Reviewer: Gabriele Galimberti
Review result: Ready
Hello,
I have been selected as the Operational Directorate reviewer for this draft.
The draft is well written, clear and easy to read. It just requires some
cosmetic changes and very small explanations.
I appreciate the examples to explain how the TLV are used and combined to
implement the proposed solution.
Below are the few comments marked as [gmg]
4.2. SD-WAN Tunnel Endpoint Sub-TLV
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SD-WAN Endpoint| length | Reserved | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SD-WAN Dst Addr Family | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| SD-WAN end point Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 SD-WAN Endpoint Sub-TLV
- SD-WAN Endpoint (8 bits): Identifies the SD-WAN Tunnel
Endpoint Sub-TLV with a Type value of 1.
- Length (8 bits): Specifies the total length of the value
field in 4-byte units.
- TTL (Time to Live): This field is set by the originating
CPE to indicate the maximum number of logical transit
nodes or regions, those that are visible to the CPEs,
that a packet is permitted to traverse across the Cloud
Backbone. Only transit nodes or regions that are
externally visible (i.e., known to or tracked by the
CPEs) MUST decrement the TTL by one. Internal cloud
forwarding elements that are opaque to the CPEs MUST NOT
modify the TTL. If the TTL reaches zero, the packet MUST
be dropped, and an alert MAY be generated. This
mechanism allows enterprises to constrain the path scope
of their packets, enforce traversal policies, and detect
anomalies (e.g., excessive transit hops).
[gmg] It would be nice to have also the "SD-WAN Dst Addr Family" description
[Linda] Thanks for this catch. Here is the explanation:
SD-WAN Dst Addr Family (16 bits): Identifies the address family of the
destination endpoint. Values follow the Address Family Numbers registry
[IANA-AF]. For example, a value of 1 indicates an IPv4 address and a value of 2
indicates an IPv6 address.
4.3. SD-WAN Tunnel Originator Sub-TLV
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SDWAN Origin | length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SD-WAN Org Addr Family | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| SD-WAN Tunnel Originator Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 SD-WAN Tunnel Originator Sub-TLV
- SDWAN Origin (8 bits): Identifies the SDWAN Tunnel
Originator Sub-TLV with a Type value of 2.
- Length (8 bits): Specifies the total length of the value
field in 4-byte units, excluding the first 4 bytes,
which include the SD-WAN Origin (1 byte), Length (1
byte), and Reserved (2 bytes) fields.
- Reserved (16 bits): Reserved for future. Must set to 0.
Ignored by recipients.
[gmg] It would be nice to have also the "SD-WAN Org Addr Family" description
[Linda] Add this bullet:
- SD-WAN Org Addr Family (16 bits): Identifies the family address of the
originator. A value of 1 indicates an IPv4 address and a value of 2 indicates
an IPv6 address.
4.4. Egress GW Sub-TLV
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SDWAN EgressGW | length | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Egress GW Addr Family | Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable) +
~ ~
| Egress GW Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 SD-WAN Egress GW Sub-TLV
- SDWAN EgressGW (8 bits): Identifies the Egress GW Sub-
TLV with a Type value of 3.
- Length (8 bits): Specifies the total length of the value
field in 4-byte units, excluding the first 4 bytes,
which include the SD-WAN Origin Sub-TLV Type (1 byte),
Length (1 byte), and Reserved (2 bytes) fields.
- Reserved (16 bits): Reserved for future. Must set to 0.
Ignored by recipients.
[gmg] It would be nice to have also the "Egress GW Addr Family" description
[Linda] added the following bullet:
- Egress GW Addr Family: Identifies the family address of the Egress GW.
A value of 1 indicates an IPv4 address and a value of 2 indicates an IPv6
address.
Multiple region entries MAY be specified in a single Sub-TLV.
Each region is identified by a variable length UTF-8 encoded
name or numeric ID, preceded by a length field. This Sub-TLV
expresses explicit exclusions and supports both soft and hard
enforcement.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (=5) | length |E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Region Len | UTF-8 encoding of Region Name or ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[gmg] having an empty row between the text end the TLV would improve
the readability, the above is just an example, please, fix also
the other parts in the draft.
[Linda] Added an empty row.
7.2. Control Plane between CPEs and Cloud GWs
There are typically eBGP sessions between a CPE and a Cloud
GW for exchanging routing information related to services
that terminate within the cloud. This allows the CPE to learn
routes to cloud-hosted resources and enables the Cloud GW to
learn routes to the CPE's on-premises networks. This control-
plane relationship is separate from the CPE-to-CPE encrypted
traffic that transits the Cloud Backbone, which remains end-
to-end encrypted and is not decrypted at the Cloud GWs.
When the connection between a CPE and a Cloud GW traverses a
public or otherwise untrusted network, an IPsec tunnel may
also be established to secure that traffic. In such cases,
IKEv2 is used to exchange the necessary IPsec security
parameters.
[gmg] it is not clear what traffic ("to secure that traffic")
is referred here: the CPE to CPE traffic or the eBGP traffic ?
Can You please clarify ?
[Linda] an IPsec tunnel may also be established to secure that traffic (between
CPE and Cloud GW.
9. Security Considerations
9.1. Threat Analysis
The GENEVE header used for steering is not encrypted, making
it susceptible to man-in-the-middle (MitM) attacks between
CPEs and Cloud GWs.
Key risks include:
a) Eavesdropping: Attackers can learn branch and Cloud GW
locations, though payload remains protected by IPsec.
b) Header Manipulation: Altered Sub-TLVs may cause misrouting
or packet drops.
c) Bandwidth Theft: A malicious or misconfigured CPE could
spoof SD-WAN metadata to use Cloud Backbone resources
without authorization.
Mitigation requires authenticating and validating SD-WAN
metadata to ensure it originates from authorized CPEs.
[gmg] please re-format the above text accordingly
[Linda] meant to say: “Mitigation above risks requires authenticating and
validating SD-WAN metadata to ensure it originates from authorized CPEs.”
10. Manageability Considerations
In multi-segment SD-WAN deployments where the Cloud GW and
CPEs belong to different administrative domains,
manageability must address the challenges of secure,
interoperable, and policy-compliant operation across
organizational boundaries. Key considerations include:
- Cross-Domain Authentication and Authorization:
Ensure that CPEs connecting to the Cloud GW are
authenticated using mutually agreed methods, and that
authorization policies are enforced to prevent
unauthorized use of Cloud Backbone resources.
- Metadata Validation and Policy Enforcement:
Cloud GWs must validate SD-WAN metadata (e.g., GENEVE
Sub-TLVs) against the registered information for each
CPE. This prevents spoofing, misrouting, and cross-
tenant traffic leakage.
- Operational Coordination and Fault Handling:
Define inter-organization procedures for troubleshooting
and incident response. This should include point-of-
contact directories, escalation processes, and shared
logging formats for event correlation.
- Change Management and Configuration Synchronization:
Coordinate configuration changes-such as policy updates,
region restrictions, or authentication parameters-so
that both the Cloud GW and CPEs apply them consistently,
avoiding mismatches that disrupt traffic.
- Policy Automation Using I2NSF Principles ([RFC8192]):
Where feasible, leverage I2NSF concepts to automate
policy configuration, exchange, and enforcement between
domains, reducing manual coordination and improving
operational consistency.
[gmg] any reference document can help to elaborate/define the above
considerations ?
[Linda] Added the following reference to the Section 10:
consistent with the service framework defined in MEF 70.1 [MEF70.1]
A.1 Single Hop Cloud GW
Assuming that all CPEs are under one administrative control
(e.g., iBGP).
Using Figure 1 as an example:
- There is a bidirectional IPsec tunnel between CPE1 and
Cloud GW; with IPsec SA1 for the traffic from the CPE1
to the Cloud-GW; and IPsec SA2 for the traffic from
the Cloud-GW to the CPE1.
- There is a bidirectional IPsec tunnel between CPE2 and
Cloud GW; with IPsec SA3 for the traffic from the CPE2
to the Cloud-GW; and IPsec SA4 for the traffic from
the Cloud-GW to the CPE2.
- All the CPEs are under one iBGP administrative domain,
with a Route Reflector (RR) as their controller. The
CPEs notify their peers of their corresponding Cloud
GW addresses (which is out of the scope of this
document).
When 192.0.2.0/26 and 192.0.2.64/26 need to communicate
with each other, CPE1 and CPE2 establish a bidirectional
IPsec Tunnel, with SA5 for the traffic from CPE1 to CPE2
and SA6 for the traffic from CPE2 to CPE1. Assume the IPsec
ESP Tunnel Mode is used. A packet from 192.0.2.1 to
192.0.2.65 has the following outer header:
[gmg] shouldn't be 192.0.2.64 instead of 192.0.2.65 and
192.0.2.0 instead of 192.0.2.1 ?
Same also in the Fig. 10
[Linda] 192.0.2.64/26 can have 64 addresses total, All IPs from 192.0.2.64
through 192.0.2.127 belong to this prefix . 192.0.2.0/26 can have 64 addresses
in total: All IPs from 192.0.2.0 through 192.0.2.63 belong to this prefix.
.
A.2 Multi-hop Transit GWs
Traffic to/from geographic apart CPEs can cross multiple
Cloud DCs via Cloud backbone.
The on-premises CPEs are under one administrative control
(e.g., iBGP).
Using Figure 2 as an example:
- There is a bidirectional IPsec tunnel between CPE1 and
the Cloud GW1; with IPsec SA1 for the traffic from the
CPE1 to the Cloud-GW1; and IPsec SA2 for the traffic
from the Cloud-GW1 to the CPE1.
- There is a bidirectional IPsec tunnel between CPE10
and the Cloud GW2; with IPsec SA3 for the traffic from
the CPE10 to the Cloud-GW2; and IPsec SA4 for the
traffic from the Cloud-GW2 to the CPE10.
- All the CPEs are under one iBGP administrative domain,
with a Route Reflector (RR) as their controller. CPEs
notify their peers of their corresponding Cloud GW
addresses.
When 192.0.2.0/26 and 192.0.2.128/25 need to communicate
with each other, CPE1 and CPE10 establish a bidirectional
IPsec Tunnel, with SA5 for the traffic from CPE1 to CPE10
and SA6 for the traffic from CPE10 to CPE1. Assume the
IPsec ESP Tunnel Mode is used, a packet from 192.0.2.1 to
192.0.2.129 has the following outer header:
[gmg] same comment as above regarding the IP addresses.
[Linda] See the reply above.
Linda
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
