Hi Shraddha, thank you for your kind consideration of my comments and thoughtful updates addressing them. All updates look good to me.
Regards, Greg On Mon, May 20, 2024 at 8:18 AM Shraddha Hegde <shrad...@juniper.net> wrote: > 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 <gregimir...@gmail.com> > Sent: Thursday, May 16, 2024 9:42 PM > To: Shraddha Hegde <shrad...@juniper.net> > Cc: James Guichard <james.n.guich...@futurewei.com>; mpls <m...@ietf.org>; > MPLS Working Group <mpls-cha...@ietf.org>; > draft-ietf-mpls-spring-inter-domain-...@ietf.org; spring <spring@ietf.org>; > Last Call <last-c...@ietf.org> > 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 <shrad...@juniper.net> > 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.guich...@futurewei.com> > > *Sent:* Friday, May 10, 2024 9:59 PM > > *To:* Greg Mirsky <gregimir...@gmail.com>; mpls <m...@ietf.org>; MPLS > > Working Group <mpls-cha...@ietf.org>; > > draft-ietf-mpls-spring-inter-domain-...@ietf.org; spring > > <spring@ietf.org>; Last Call <last-c...@ietf.org> > > *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 <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> > 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 >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
