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> 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 https://www.ietf.org/mailman/listinfo/spring
