[mpls] Re: Follow-up comments on draft-ietf-mpls-spring-inter-domain-oam

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> Sent: Thursday, May 16, 2024 9:42 PM
> To: Shraddha Hegde <[e-mail]>
> Cc: James Guichard <[e-mail]>; mpls <[e-mail]>;
> MPLS Working Group <[e-mail]>;
> [e-mail]; spring <[e-mail]>;
> Last Call <[e-mail]>
> 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 <[e-mail]>
> 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 <[e-mail]>
> > *Sent:* Friday, May 10, 2024 9:59 PM
> > *To:* Greg Mirsky <[e-mail]>; mpls <[e-mail]>; MPLS
> > Working Group <[e-mail]>;
> > [e-mail]; spring
> > <[e-mail]>; Last Call <[e-mail]>
> > *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 <[e-mail]>
> > *Date: *Friday, May 3, 2024 at 12:03 PM
> > *To: *mpls <[e-mail]>, MPLS Working Group <[e-mail]>,
> > [e-mail] <
> > [e-mail]>, James Guichard <
> > [e-mail]>, spring <[e-mail]>, Last Call <
> > [e-mail]>
> > *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 <[e-mail]>
> 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
>