Re: [mpls] Éric Vyncke's Discuss on draft-ietf-mpls-lspping-norao-07: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Eric,
thank you for your kind consideration of this document and the guidance
through the process. Would the following note in the Abstract address the
issue:
   [RFC Editor Note: Per IESG decision, this document MUST be processed
   only after the status of RFC 7506 is changed to Historical.  This not
   must be removed before the publication.]

Regards,
Greg

On Fri, Mar 1, 2024 at 4:32 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Greg and other authors,
>
>
>
> The topic of historic status was discussed on the 29th Feb IESG telechat;
> the conclusion is that the I-D should contain a note for the RFC editor
> (and the RFC editor text for the ballot as well) requesting that this
> document is to be processed by the RFC editor **only** after RFC 7506
> status has changed to historic.
>
>
>
> Once, those 2 notes for the RFC editor are written, then I am clearing my
> discuss.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
>
>
> *From: *Eric Vyncke <[e-mail]>
> *Date: *Thursday, 29 February 2024 at 07:42
> *To: *Greg Mirsky <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-mpls-lspping-norao-07:
> (with DISCUSS and COMMENT)
>
>
>
> Hello Greg,
>
>
>
> Thanks for your prompt and detailed reply.
>
>
>
> We are indeed making big progress, please note that the
> change-status-to-historic **SHOULD** be published before this document
> can be published to ensure consistency. A topic to be discussed later today
> (already Thursday in Belgium) during the IESG formal telechat: how to
> ensure the sequence.
>
>
>
> Else, I think you have addressed all the issues, see below for EVY>
>
>
>
> Regards,
>
>
>
> -éric
>
>
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Thursday, 29 February 2024 at 04:39
> *To: *Eric Vyncke <[e-mail]>
> *Cc: *The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-mpls-lspping-norao-07:
> (with DISCUSS and COMMENT)
>
>
>
> Hi Éric,
>
> thank you for sharing your concerns and helpful suggestions to improve
> the document. Please find my notes below tagged with GIM>>. Attached,
> please find the working version of the draft that includes all the updates
> discussed below.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Feb 28, 2024 at 6:17 AM Éric Vyncke via Datatracker <
> [e-mail]> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-mpls-lspping-norao-07: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-lspping-norao/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-mpls-lspping-norao-07
>
> Thank you for the work put into this document.
>
> Please find below one blocking DISCUSS points (one easy to address and one
> requiring an AD intiative), some non-blocking COMMENT points (but replies
> would
> be appreciated even if only for my own education), and one nit.
>
> Special thanks to Adrian Farrel for the shepherd's *very* detailed write-up
> including the WG consensus *and* the justification of the intended status.
>
> Other thanks to Donald Eastlake, the Internet directorate reviewer (at my
> request), please consider this int-dir review:
>
> https://datatracker.ietf.org/doc/review-ietf-mpls-lspping-norao-07-intdir-telechat-eastlake-2024-02-23/
> (and I have yet to see authors's comment)
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # DISCUSS (blocking)
>
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion on the following topics:
>
> ## Making RFC 7506 historic
>
> Like Donald Eastlake wrote, this is not the correct way of doing it. While
> I am
> not too process-oriented, let's try to keep the process running.
>
>
> https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-designating-rfcs-as-historic-20140720/
> requires an AD-initiated procedure to make a RFC historic. And we could
> even
> argue whether this document requires making RFC 7506 historic rather than
> updating (or even obsoleting it).
>
> GIM>> I'll follow the IESG guidance and update the document accordingly.
>
>
>
> EVY> thanks
>
>
> `Furthermore, this document explains why RFC 7506 has been reclassified as
> Historic.` should be moved to the designated-as-historic (including
> section 3)
> document or *at least* not use the past tense but rather the conditional
> mode.
>
> GIM>> Updated Abstract and Introduction to more assertive statements:
>
> In Abstract
>
>    Furthermore, this document explains why RFC 7506 has been
>
>    reclassified as Historic.
>
> In Introduction:
>
>    Therefore, this document updates RFC 8029 [RFC8029] to retire the RAO
>
>    from both LSP ping message encapsulations and explains why RFC 7506
>
>    [RFC7506] has been reclassified as Historic.
>
>
>
> Do these updates make the statement more consistent?
>
>
>
> EVY> Indeed. I will keep my blocking DISCUSS ballot at least until today
> IESG telechat
>
>
> ## Missing reference RFC 3032
>
> As indicated by the id-nits tool and very easy to fix, please add the
> reference
> to RFC 3032.
>
> GIM>> Thank you for pointing this out to me. Upon further inspection, the
> reported '[RFC3032]' is the text in RFC 8029 removed by this specification:
>
>    Resulting from the removal of the Reply mode 3 "Reply via an IPv4/
>
>    IPv6 UDP packet with Router Alert" (see Section 2.2), this
>
>    specification updates Section 4.5 of [RFC8029] by removing the
>
>    following text:
>
>
>
>    If the Reply Mode in the echo request is "Reply via an IPv4 UDP
>
>    packet with Router Alert", then the IP header MUST contain the Router
>
>    Alert IP Option of value 0x0 [RFC2113] for IPv4 or 69 [RFC7506] for
>
>    IPv6.  If the reply is sent over an LSP, the topmost label MUST in
>
>    this case be the Router Alert label (1) (see [RFC3032]).
>
>
>
> Do you think that all the references in the quoted text must be changed to
> XML-wise references?
>
>
>
> EVY> no need indeed (my bad), may I suggest to enclose the removed
> paragraph by ‘REMOVED’ ... ‘END’ to make it clear in the document ?
>
>
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # COMMENTS (non-blocking)
>
> ## Abstract
>
> s/are encapsulated in IP headers/are encapsulated in IP packets whose
> headers/
>
> `The rationale for using an RAO as the exception mechanism is
> questionable.`
> unsure whether this opinion belongs to an abstract of a proposed standards.
> Suggest to use 'The RAO in real deployment was neither required not used'
> (or
> something not using 'questionable').
>
> GIM>> Updated Abstract as follows:
>
> NEW TEXT:
>
>    The MPLS echo request and MPLS echo response messages, defined in RFC
>
>    8029 "Detecting Multiprotocol Label Switched (MPLS) Data-Plane
>
>    Failures" (usually referred to as LSP ping messages), are
>
>    encapsulated in IP whose headers include a Router Alert Option (RAO).
>
>    The RAO in real deployment was neither required nor used.
>
>
>
> EVY> LGTM, thanks
>
>
>
>
> ## Section 1
>
> Same comment as for the abstract, I find weird to have `In both cases, the
> rationale for including an RAO is questionable.` in a I-D. Be more
> assertive:
> "This document explains why it was not needed'.
>
> GIM>> Thank you for the suggestion. Replaced it with:
>
>  This document explains why RAO was not needed in both cases.
>
>
>
> EVY> LGTM
>
>
> ## Section 4
>
> While I really like the idea of using ::1/128 as IPv6 destination, why not
> using a MUST in `the IPv6 loopback address ::1/128 SHOULD be used`?
>
> GIM>> That was discussed, and the MPLS WG has agreed to the following:
>
>    *  For IPv6, the IPv6 loopback address ::1/128 SHOULD be used.
>
>
>
>    *  The sender of an MPLS echo request MAY select the IPv6 destination
>
>       address from the 0:0:0:0:0:FFFF:7F00/104 range.
>
> As I understand it, that preserves the conformance status of the existing
> deployed implementations of LSP ping/traceroute.
>
> Furthermore, normally every SHOULD has some text about when the statement
> can
> be bypassed. Also, the abstract says 'recommends' (even if they are
> equivalent
> per BCP14, let's be consistent and use 'IS RECOMMENDED').
>
> GIM>> Would the following wording be acceptable:
>
>    Also, the use of an IPv6 loopback address (::1/128) as the IPv6
>
>    destination address for an MPLS echo request message is RECOMMENDED.
>
>
>
> EVY> so let it be, let’s keep the SHOULD (albeit RFC should reflect the
> IETF consensus and not a WG consensus), but please provide some text
> explaining when the SHOULD can be ignored.
>
>
>
> EVY> Good to add the statemement with RECOMMENDED
>
>
>
>
> Unsure whether `LSP Ping implementations SHOULD ignore RAO options when
> they
> arrive on incoming MPLS echo request and MPLS echo reply messages` adds any
> value (OK to keep the text though) as if the receiving node handles it then
> this is too late else if the receiving node does not honour RAO then who
> cares ?
>
>
>
> EVY> assuming then that the authors want to keep it as it is
>
>
>
> ## Section 7
>
> Indeed, thanks for the ::1/128 use in IPv6. Great idea.
>
> GIM>> Thank you. In fact, that was our discussion some time ago of RFC
> 8562  <https://datatracker.ietf.org/doc/rfc8562/>. Our intention is to
> follow with an update of the relevant BFD specifications.
>
>
>
> EVY> excellent !
>
>
> # NIT (non-blocking / cosmetic)
>
> ## Section 4
>
> In `For IPv6, the IPv6 loopback address` is redundant with the leading `The
> IPv6 destination address for an MPLS echo request message is selected as
> follows`.
>
> GIM>> Would removing "For IPv6," make it clearer?
>
>
>
> EVY> indeed ;-)
>