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

["Eric Vyncke (evyncke)" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>>
Date: Thursday, 29 February 2024 at 07:42
To: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Date: Thursday, 29 February 2024 at 04:39
To: Eric Vyncke <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[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 ;-)