FYI From: Linda Dunbar Sent: Tuesday, July 1, 2025 3:33 PM To: Adrian Farrel <[email protected]>; Yingzhen Qu <[email protected]>; [email protected]; [email protected] Subject: RE: [RTG-DIR] Rtgdir early review of draft-dmk-rtgwg-multisegment-sdwan-05
Adrian, When I recently asked about starting WGLC, the RTGWG chair kindly reminded me that this email had not yet been addressed. I had thought I'd followed up earlier. While we did discuss your comments during IETF 119, I now realize they weren't captured on the RTGWG mailing list. As we prepare for WGLC, the chairs asked me to confirm that you're satisfied with the resolutions to the issues you raised. Please see below for the detailed responses, marked under [Linda 4] in blue. The updated document: https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/ Let me know if anything still needs clarification. Thank you very much, Linda From: Adrian Farrel <[email protected]<mailto:[email protected]>> Sent: Saturday, February 24, 2024 9:44 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>>; 'Yingzhen Qu' <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [RTG-DIR] Rtgdir early review of draft-dmk-rtgwg-multisegment-sdwan-05 OK, there are some fun discussion points here. CHAIRS: Note well, we have moved well beyond the original points in my RTG-DIR review In line and trying to focus... [Linda2] Yes, need IANA registry. Reflected in -7 [AF3] OK. I see the registry. I think you still have work to do on it related to the 'C' bit. You don't have to do that now, but you will need to do it. My main point is ... And you'll have to give IANA a clue about selecting from the range 128-255 to make sure the C-bit is set. [Linda4] IANA already assigned 0x163 for the Multi Segment SD-WAN (which is within the range of 128-255). Is it still necessary to add a sentence like: "To ensure the C-bit is set in the Geneve Option header as required, the Type values associated with the Multi-Segment SD-WAN Option Class (0x0163) MUST be selected from the 128-255 range, per [RFC8926]." [snip] --- > 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: * 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. [AF2] * 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. [Linda2] strictly between the enterprise <-> Cloud Provider. [AF3] So, is it a byte string or a character string? Is it printable? Is internationalization supported? How does an implementation at the enterprise manage to interwork with an implementation at the cloud provider? [Linda3] it is character string, like a region name, provided by the Cloud Provider. I suggest you go and talk with an expert in internationalization (that is not me!) to make sure you have enough detail in this section. [Linda4] only numeric numbers is used in the data plane. Cheers, Adrian
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
