Adria and Joel, Many thanks to Joel for the Zoom call, which helped clarify the source of confusion. Based on the discussion, we have revised the Abstract and Introduction to clearly state that the method is for interconnecting geographically separated SD-WAN segments via a Cloud Backbone.
We have also removed the section on the Include-Sub-TLV, as enforcing such a policy is beyond the IETF’s scope. Please find the revised draft: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/ . We welcome any further comments or suggestions. Thank you very much, Linda From: Adrian Farrel <adr...@olddog.co.uk> Sent: Friday, August 1, 2025 12:25 AM To: 'Joel Halpern' <j...@joelhalpern.com>; 'Kausik Majumdar' <kausik.majumdar=40oracle....@dmarc.ietf.org>; 'Kausik Majumdar' <kausik.majum...@oracle.com>; Linda Dunbar <linda.dun...@futurewei.com>; 'Yingzhen Qu' <yingzhen.i...@gmail.com>; draft-ietf-rtgwg-multisegment-sd...@ietf.org; rtg-...@ietf.org Subject: RE: [RTG-DIR]Re: [External] : RE: Rtgdir early review of draft-dmk-rtgwg-multisegment-sdwan-05 Hi Linda, I appreciate the effort to have a call to resolve the open issues. However… :-) I’m on vacation at the moment, so I can’t make your planned call. It would be a good idea to go ahead with the call anyway and close off what you can. In line (we have reached [AF6]) Adrian From: Joel Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> Sent: 01 August 2025 02:12 To: Kausik Majumdar <kausik.majumdar=40oracle....@dmarc.ietf.org<mailto:kausik.majumdar=40oracle....@dmarc.ietf.org>>; Kausik Majumdar <kausik.majum...@oracle.com<mailto:kausik.majum...@oracle.com>>; Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Yingzhen Qu' <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; draft-ietf-rtgwg-multisegment-sd...@ietf.org<mailto:draft-ietf-rtgwg-multisegment-sd...@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Subject: Re: [RTG-DIR]Re: [External] : RE: Rtgdir early review of draft-dmk-rtgwg-multisegment-sdwan-05 Happy to hear from anyone who can clarify this. Thank you, Joel On 7/31/2025 7:36 PM, Kausik Majumdar wrote: Also, if possible, please include Ashok as well in the meeting. I hope we both can join and answer some of the questions from the Cloud backbone side. From: Kausik Majumdar <kausik.majum...@oracle.com><mailto:kausik.majum...@oracle.com> Sent: Thursday, July 31, 2025 4:30 PM To: Linda Dunbar <linda.dun...@futurewei.com><mailto:linda.dun...@futurewei.com>; adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Yingzhen Qu' <yingzhen.i...@gmail.com><mailto:yingzhen.i...@gmail.com>; draft-ietf-rtgwg-multisegment-sd...@ietf.org<mailto:draft-ietf-rtgwg-multisegment-sd...@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Subject: RE: [External] : RE: [RTG-DIR] Rtgdir early review of draft-dmk-rtgwg-multisegment-sdwan-05 Hi Linda, If possible, please forward me the invite as well. If I have no conflicts, I will try to join. I didn’t get a chance to follow up with all the discussions in the thread. Hopefully, I would be able to answer questions regarding the Cloud backbone and the routing decision between the Cloud GWs that are deployed across the Regions. Thanks, Kausik From: Linda Dunbar <linda.dun...@futurewei.com<mailto:linda.dun...@futurewei.com>> Sent: Thursday, July 31, 2025 4:24 PM To: adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>; 'Yingzhen Qu' <yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>>; draft-ietf-rtgwg-multisegment-sd...@ietf.org<mailto:draft-ietf-rtgwg-multisegment-sd...@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org> Subject: [External] : RE: [RTG-DIR] Rtgdir early review of draft-dmk-rtgwg-multisegment-sdwan-05 Adrian, Thanks for the additional comments. Please see below resolutions under [Linda6]. The most contentious issue seems to be about traversing the nodes or regions listed in the Include Sub-TLV. I have scheduled a Zoom call with Joel Halpern to work through the details. I’ll forward you the invite—hope you can join as well.. Thank you very much. Linda > 4.6 and 4.7 > > Obviously, you are going to have to specify these TLVs in a future > version. For the include case, you are going to have to say whether this > is an ordered list, whether the inclusion is mandatory, and whether the > list is strict or loose. Multiple Include-Transit Sub-TLVs can be included in one GENEVE header to represent multiple nodes or regions to be included when the packet is steered through the Cloud Backbone. I-bit: When set to 0: it indicates it needs best effort to steer through the transit node ID. When set to 1, it indicates that the Transit Node ID must be included through the Cloud Backbone. If the Transit Node ID cannot be traversed, an alert or alarm must be generated to the enterprise via an out-of-band channel. It is out of the scope of this document to specify those alerts or alarms. [AF2] That is making progress. Thanks. I think you are still missing: 1. Is this an ordered list or just a set? [Linda3] Meant to say it is Not Ordered list. Sorry for the confusion. [Linda 4] The draft now clearly states: “Multiple Include-Transit Sub-TLVs can be included within a single GENEVE header to indicate multiple required transit nodes or regions. However, these Sub-TLVs form an unordered set, meaning there is no enforced sequence in which the specified regions must be traversed.” OK, take a look at what RSVP-TE did for inclusion (RFC 3209) and exclusion (RFC 4874). While it is fine for exclusion to be an unordered list, making inclusion unordered can lead to some interesting trombone/hairpin paths. Do you *really* want to force transit through GW1, GW2, and GW3 if the packet has already arrived at GW2 and can see a simple, short path to the destination? [Linda4] While ordered transit enforcement is common in RSVP-TE [RFC3209], this document adopts an unordered inclusion model to allow for flexible, policy-driven steering based on region or zone availability. This approach avoids over-constraining the path and is more compatible with the dynamic nature of cloud backbones. Implementations MAY optimize the forwarding path if earlier listed regions have already been traversed. [AF4] OK. The you quote above text is clear, and if that is what you want to achieve, then it is good. [AF2] 1. How is the string encoded? [Linda4] If Transit_type = 1, the Transit Node ID is a 32-bit numeric identifier (e.g., region or zone ID assigned by the cloud provider). Named regions (e.g., "us-west-2") are not used directly in the data plane encoding and must be mapped to numeric IDs through out-of-band mechanisms. How about adding the following paragraph at the end of Section 4.5: Unlike RSVP-TE [RFC3209], this document defines Include-Transit as an unordered set to allow flexible path selection in dynamic cloud environments. Implementations MAY skip already-traversed nodes to avoid inefficient paths. For Transit_type = 1, the Transit Node ID is a 32-bit numeric identifier (e.g., region or zone ID). Named regions (e.g., "us-west-2") MUST be mapped to numeric IDs via out-of-band methods. [AF4] I don’t think you need to make any mention of RSVP-TE. And you already have the statement about an unordered list as stated above. [AF5] You chose not to address this? [Linda6] is it okay just to remove the phrase “Unlike RSVP-TE [RFC3209]”? [AF6] Yes, that’s better. The second sentence is “interesting”. Since the list is unordered, once the node is “already-traversed” the requirement to traverse it is already satisfied, so there is no question of “MAY skip”. [AF5] This issue is slightly larger, but you also chose to not address it? [Linda6] During the process of addressing Joel Halpern’s comment, the text “… MAY skip already-traversed nodes..” is removed. Instead, the first paragraph of Section 4.5 is changed to the following: “Some SD-WAN deployments require specific transit segments to be included in the end-to-end path for regulatory compliance, or traversing specific service functions, rather than for path optimization. The Include-Transit Sub-TLV, an optional field, is used to signal such preference. It allows the senders to explicitly indicate a list of Cloud Availability Regions or Zones that a packet should traverse when forwarded through the Cloud Backbone. However, this indication reflects preference only and does not imply any guarantee of traversal. Enforcement of the include list is outside the scope of this document and must be realized, if needed, through mutual agreement and provider-specific mechanisms.” [AF6] You have “Some SD-WAN deployments *require*” and you have “a packet should” and “preference only”. This is a cascaded weakening of objectives! Note, however, that if the I-bit is set and the path is just one step from the destination, but not all of the nodes in the set have been reached, the path may have to do some tromboning to pick up all of the required nodes. That feels a bit odd. [Linda6] Yes, I-bit setting to 1 might cause unoptimized traversing within the Cloud Backbone. Here is the revised description of I-Bit: I-bit setting 1: The listed region reflects a strong intent for traversal. If the Cloud Backbone determines the region cannot be included, it is recommended to generate an alert or notification to the enterprise. [AF6] While this definitely helps, I see two issues: * s/recommended/RECOMMENDED/ ?? * The difference between setting the bit and not setting the bit is now: “strong intent” versus “best effort”. Do you really need the bit at all? [AF5] On reflection, this tromboning issue exists even if the I-bit is clear because “the Cloud Backbone will make a best-effort attempt to route traffic through it.” Perhaps the big question here is whether the routing choice is made once at the start of the path (with the traffic then steered on a planned path), or is made incrementally through the network. The more I think about this, the more I think it is somehow broken. [Linda6] It is more like Service Function Chain. Within the Cloud Backbone, different destination addresses might be used for the packets to traverse through the regions on the Include-List. [AF6] I am not getting this. Service Function Chain is an explicit path: the packet traverses the service functions in the order they are listed. It is not “you must pick up these functions in any order you like.” So, I think the text (when describing the purpose of the extensions, and when describing how to interpret the bits and bytes) needs to be very clear. There is a list of regions. Is the intent is that the packet shall traverse all of the regions? Is the intent that the traversal shall be in the order listed? Make those statements clear, and then return to your objectives: Are you meeting the objectives you have stated? Do the stated objectives provide any useful function? The second paragraph answers my question. I don’t think you need “MUST be mapped.” It would be enough to write “are mapped” [AF5] You didn’t make a change here. [Linda6] changed to “are mapped” in version -5. [AF6] Thanks
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
