Re: [mpls] John Scudder's No Objection on draft-ietf-mpls-lspping-norao-07: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi John,
thank you for your kind words about our work; much appreciated. Your
comments are helpful. Please find my notes below tagged by GIM>>.

Regards,
Greg

On Tue, Feb 20, 2024 at 12:54 PM John Scudder via Datatracker <
[e-mail]> wrote:

> John Scudder has entered the following ballot position for
> draft-ietf-mpls-lspping-norao-07: No Objection
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thanks for this document. I have just a few comments, below.
>
> Your NEW text includes, “To exercise all paths in an ECMP environment, the
> entropy other than the IP destination address SHOULD be used.”
>
> First, and least important, this isn’t quite grammatical. I suppose you
> mean
> something like “a source of entropy other than...”.
>
GIM>> Thank you for your suggestion. Updated, including the change
addressing a comment from Erik Kline:
   *  To exercise all paths in an ECMP environment, the source of
      entropy other than the IP destination address SHOULD be used.  For
      example, MPLS Entropy Label [RFC6790] or IPv6 Flow Label [RFC6438]
      can be used as the source of entropy.

>
> Second, under what circumstances is it OK for the IP destination address
> to be
> varied as a source of entropy? (SHOULD implies there are valid cases when
> an
> implementer MAY disregard the guideline.)
>
GIM>> That may be used if the destination address is one from
the 0:0:0:0:0:FFFF:7F00/104 range. Then, to conform to one of the
requirements stated in Section 2.1 of RFC 802
<https://datatracker.ietf.org/doc/html/rfc8029#section-2.1>9:
   3.  A means of varying the diagnostic packets such that they exercise
       all ECMP paths is thus REQUIRED.
 "The 127/8 range for IPv4 and that same range embedded in an IPv4-mapped
IPv6 address for IPv6 was chosen", according to RFC 8029.

>
> The answer to the above may well also answer my next question, which is to
> ask
> why you continue to permit the use of any IPv4-mapped IPv6 address from
> 127/8
> as the destination address, instead of making the exclusive use of the IPv6
> loopback address a MUST, which seems like the obvious thing to do.
>
GIM>> I agree with you that that is logical and the safest step. But what
would happen to implementations and deployments that support RFC8029-style
solutions for the IPv6 destination address?

>
> For that matter, I’m struggling to see why any of the SHOULD in your new
> text
> can’t be MUST, other than the “SHOULD NOT” in the definition of
> “deprecated“
> (even that one is debatable).
>
GIM>> Since the use of 0:0:0:0:0:FFFF:7F00/104 range seems to have only a
potential for leaking MPLS Echo Request packets out of a broken LSP (no one
has reported that from the field), it seems like a recommendation rather
than a requirement is sufficient. And, as I understand it, the WG has
agreed with this PoV.