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

[Greg Mirsky <[e-mail]>]

Hi Eric,
I uploaded the new version of the draft:

Name:     draft-ietf-mpls-lspping-norao
Revision: 08
Title:    Deprecating the Use of Router Alert in LSP Ping
Date:     2024-03-01
Group:    mpls
Pages:    10
URL:
https://www.ietf.org/archive/id/draft-ietf-mpls-lspping-norao-08.txt
Status:   https://datatracker.ietf.org/doc/draft-ietf-mpls-lspping-norao/
HTML:
https://www.ietf.org/archive/id/draft-ietf-mpls-lspping-norao-08.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-lspping-norao
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-lspping-norao-08

Thank you for your help in improving the quality of the document. Please
let me know if you have any concerns with the current document.

Regards,
Greg

On Fri, Mar 1, 2024 at 6:53 AM Greg Mirsky <[e-mail]> wrote:

> Yes, that makes sense.
> Added the text as follows:
>
> 1.  RFC Editor Note
>
>    Per IESG decision, this document MUST be processed only after the
>    status of RFC 7506 is changed to Historical.  This note must be
>    removed before the publication.
>
> Regards,
> Greg
>
> On Fri, Mar 1, 2024 at 6:49 AM Eric Vyncke (evyncke) <[e-mail]>
> wrote:
>
>> Hi Greg,
>>
>>
>>
>> I would rather create a section in the I-D “Note for the RFC editor” and
>> be sure to s/not/note/
>>
>>
>>
>> Regards
>>
>>
>>
>> -éric
>>
>>
>>
>> *From: *Greg Mirsky <[e-mail]>
>> *Date: *Friday, 1 March 2024 at 15:46
>> *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 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 ;-)
>>
>>