Adrian, Thanks again. Here are the resolutions to the remaining comments marked by [Linda3]
Linda From: Adrian Farrel <[email protected]> Sent: Wednesday, February 21, 2024 2:52 AM To: Linda Dunbar <[email protected]>; 'Yingzhen Qu' <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: RE: [RTG-DIR] Rtgdir early review of draft-dmk-rtgwg-multisegment-sdwan-05 Hi again, Thanks for continuing to engage in this discussion. This email is me getting out of the way of further progress of this draft. Cheers, Adrian [snip] [snip] [snip] [Linda] add the following: C-bit needs to be set, so that receiving node can drop the packet if it does not recognize the option [RFC8926]. [AF2] OK. This has not shown up in -06, so presumably still in your edit buffer. I don't know whether you are supposed to write "Type 1 with the C-bit set" or "Type 129" [AF2] Note that 8926 calls it the 'C' bit and the high-order bit. [AF2] You haven't answered the point about the new registry [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. [Linda3] Will chat with you during IETF119 on this subject. You seem to have crashed the use of "TBD1" etc which were for Transit node ID types (section 4.5) but you have reused those flags in section 11 for the Multi-seg-SDWAN_subTypes [Linda2] Good catch. Change in v-8 And you'll have to give IANA a clue about selecting from the range 128-255 to make sure the C-bit is set. Note that in the body text you have two cases of subType3 --- 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. You may also have to worry about the option length in the GENEVE header especially in the case of IPv6. [Linda] I meant to say that they may not want internal IP address exposed. Node ID or Region ID are all okay. Add the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Include-Transit| length |Transit_Type |I|Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transit node ID | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 Include-Transit Sub-TLV 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. Transit_type: TBD1: when Transit node ID is represented as a numeric number, such as a Cloud Availability Region or Zone numeric identifier. TBD2: when Transit node ID is represented as string, such as a Cloud Availability Region or Zone name. TBD3: when Transit node ID is represented as an IP address. 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? [Linda2] No [AF3] <snigger> "Is it an apple or an orange," he asked. "No," she replied. [Linda3] Meant to say it is Not Ordered list. Sorry for the confusion. [AF2] * How is the string encoded? [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. [snip]
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
