Dear authors, I would appreciate a response from this last-call review prior to moving the document forward to the next step.
Thanks! Jim From: Greg Mirsky <gregimir...@gmail.com> Date: Friday, May 3, 2024 at 12:03 PM To: mpls <m...@ietf.org>, MPLS Working Group <mpls-cha...@ietf.org>, draft-ietf-mpls-spring-inter-domain-...@ietf.org <draft-ietf-mpls-spring-inter-domain-...@ietf.org>, James Guichard <james.n.guich...@futurewei.com>, spring <spring@ietf.org>, Last Call <last-c...@ietf.org> Subject: Re: Follow-up comments on draft-ietf-mpls-spring-inter-domain-oam Dear All, I've shared my comments about the draft-ietf-mpls-spring-inter-domain-oam-12. It seems like the latest version 13 does not address my questions. Please consider these comments as part of IETF LC. Regards, Greg On Tue, Apr 23, 2024 at 5:06 AM Greg Mirsky <gregimir...@gmail.com<mailto:gregimir...@gmail.com>> wrote: Dear, Authors, WG Chairs, et al., I've shared my notes on this work earlier and recently was asked by the AD to re-read the current version of the document. I greatly appreciate the work of the Authors in improving the document. I have several questions of a general nature and some nits that may be addressed before the next step. I welcome your thoughts and comments on the following: * AFAICS, the document defines three new optional sub-TLVs that may be used in the Type 21 Reply Path TLV. As indicated in the IANA Considerations section, these new sub-TLVs must be added to IANA's Sub-TLVs for TLV Types 1, 16, and 21<https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xml#sub-tlv-1-16-21> registry. But the draft defines the handling of the new sub-TLVs in combination with Type 21 TLV only, although the registry is shared by TLVs of Type 1 (Target FEC Stack TLV) and Type 16 (Reverse-path Target FEC Stack TLV). Hence my question, Could the new sub-TLVs be used with Types 1 and 16 TLV? If "yes", what are the rules for handling the new sub-TLVs? * My other question is about the relationship between the number of defined new elements (sub-TLVs and fields that those contain) and the level of reporting possible inconsistencies in sub-TLVs using the Return Code field in the echo reply packet. Could there be more validation failures that must be reported to the sender of the echo request packet? Nits and knots: * There seems to be a contradiction between the statement in the first sentence and what is conveyed in the second one: It is not possible to carry out LSP ping and traceroute functionality on these paths to verify basic connectivity and fault isolation using existing LSP ping and traceroute mechanism([RFC8287] and [RFC8029]). That is because there might not always be IP connectivity from a responding node back to the source address of the ping packet when the responding node is in a different AS from the source of the ping. If the case is as described in the second sentence, i.e., IP connectivity from egress to ingress is optional, then "it is not possible" might be tuned into "It is not always possible" or something similar. WDYT? * TBD vs. TBA acronyms referring to values assigned by IANA * Perhaps replace "wants" with normative language? * SID field in Figures 4 and 5 do not include label, TC, S and TTL mentioned in the respective definitions in Section 4.2 and 4.3. You may consider a separate figure that displays the format of the SID field or expose its inner structure in respective figures. * Unused bits are not marked in Figure 6. Also, is there a special reason assigning the A flag position of Bit 1, not Bit 0? Regards, Greg
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
