Hi Greg, Snipping to open comments... Version -16 will have the changes. > GIM>> I looked through RFC 8029 and RFC 7110 to see which error code(s) could be considered appropriate in this scenario. RFC 7110 states, "Any new sub-type added to TLV Type 1 MUST apply to the TLV Type 21 as well." I believe this requirement holds in reverse, i.e., any new sub-type added to the TLV 21 MUST apply to the TLV 1 (and 16). If correct, the document is expected to specify how the conforming implementation reacts to Segment sub-TLV presence in Target FEC Stack (Type 1) or Reverse-path Target FEC Stack TLV (Type 16). Furthermore, it seems that to improve the ease of operating heterogeneous (regarding this specification) MPLS domain, more text that describes interworking with a system that does not support this draft would be helpful. For example, Section 5.4 of RFC 7110 defines the potential behavior of the sender of the echo request message when receiving the echo reply with the particular error code. <SH> Added text below " If the ingress node does not support return code "Use Reply Path TLV in the echo reply for building the next echo request" (defined in this document), log should be generated indicating the return code and the operator may choose to specify the return path explicitly or use other mechanisms to verify The SR policy. If the return code is TBA2 ,"Local policy does not allow dynamic Return Path building" , it indicates that the intermediate node does not support building dynamic return path. Log should be generated on the ingress receiving this return code and the operator may choose to specify the return path explicitly or use other mechanisms to verify the SR Policy." > > - 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? > > <SH> I think the “malformed echo request received” return code would be > sufficient . Added below text > > “If the echo request message contains > > malformed Segment Sub-TLV, an echo reply with return code set to > > "Malformed echo request received" and the > > Subcode set to zero must be sent back to the ingress LSR.” > > GIM>> Thank you for clarifying and updating Section 6.2 of the draft. I think it would be very helpful if the document further clarified what constitutes the malformity of the Segment TLV. <SH> updated as below " If the echo request message contains a malformed segment sub-TLV, such as incorrect length field, an echo reply with return code set to..." Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Greg Mirsky <gregimirsky@xxxxxxxxx> Sent: Thursday, May 16, 2024 9:42 PM To: Shraddha Hegde <shraddha@xxxxxxxxxxx> Cc: James Guichard <james.n.guichard@xxxxxxxxxxxxx>; mpls <mpls@xxxxxxxx>; MPLS Working Group <mpls-chairs@xxxxxxxx>; draft-ietf-mpls-spring-inter-domain-oam@xxxxxxxx; spring <spring@xxxxxxxx>; Last Call <last-call@xxxxxxxx> Subject: Re: Follow-up comments on draft-ietf-mpls-spring-inter-domain-oam [External Email. Be cautious of content] Hi Shraddha, thank you for your consideration of my comments. I've reviewed the new version of the draft and have some follow-up questions and notes. Please find them below tagged GIM>>. Regards, Greg On Wed, May 15, 2024 at 8:18 AM Shraddha Hegde <shraddha@xxxxxxxxxxx> wrote: > Greg, > > > > Thans again for the careful review and comments. > > Pls see inline <SH> for replies. > > Version -14 will address your comments. > > > > Rgds > > Shraddha > > > > Juniper Business Use Only > > *From:* James Guichard <james.n.guichard@xxxxxxxxxxxxx> > *Sent:* Friday, May 10, 2024 9:59 PM > *To:* Greg Mirsky <gregimirsky@xxxxxxxxx>; mpls <mpls@xxxxxxxx>; MPLS > Working Group <mpls-chairs@xxxxxxxx>; > draft-ietf-mpls-spring-inter-domain-oam@xxxxxxxx; spring > <spring@xxxxxxxx>; Last Call <last-call@xxxxxxxx> > *Subject:* Re: Follow-up comments on > draft-ietf-mpls-spring-inter-domain-oam > > > > *[External Email. Be cautious of content]* > > > > 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 <gregimirsky@xxxxxxxxx> > *Date: *Friday, May 3, 2024 at 12:03 PM > *To: *mpls <mpls@xxxxxxxx>, MPLS Working Group <mpls-chairs@xxxxxxxx>, > draft-ietf-mpls-spring-inter-domain-oam@xxxxxxxx < > draft-ietf-mpls-spring-inter-domain-oam@xxxxxxxx>, James Guichard < > james.n.guichard@xxxxxxxxxxxxx>, spring <spring@xxxxxxxx>, Last Call < > last-call@xxxxxxxx> > *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 <gregimirsky@xxxxxxxxx> 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
