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 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 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 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. 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 ? 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 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 ? 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 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.