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

[Greg Mirsky <[e-mail]>]

Hi Erik,
thank you for raising the question of which address to use. Please find my
notes below tagged GIM>>.

Regards,
Greg

On Mon, Feb 19, 2024 at 11:04 PM Erik Kline via Datatracker <
[e-mail]> wrote:

> Erik Kline 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:
> ----------------------------------------------------------------------
>
> # Internet AD comments for draft-ietf-mpls-lspping-norao-07
> CC @ekline
>
> * comment syntax:
>   - https://github.com/mnot/ietf-comments/blob/main/format.md
>
> * "Handling Ballot Positions":
>   -
> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>
> ## Discuss
>
> ### S4
>
> * It does not seem great to me to have ::1 leaking out in packets that can
>   traverse a non-logical-loopback link (i.e. actually be sent on the wire).
>
>   Raising this DISCUSS to see if it might be better to recommend use of
>   any number of addresses from the 100::/64 Discard-Only Address Block
>   (RFC 6666) which should have similar properties but also allow operators
>   to maybe construct configurations where leaked packets might be captured?
>

GIM>> Thank you for pointing me to RFC 6666, very interresting scenario. It
seems to me that the use of a loopback address in LSP ping, discussed
in Section
2.1 of RFC 8029 <https://www.rfc-editor.org/rfc/rfc8029#section-2.1> is
different from how the Discard-Only Prefix is used for the remote triggered
black hole filtering and routing. As stated in the second requirement on
p.9 of RFC 8029:
   2.  If an LSP is broken in such a way that it prematurely terminates,
       the diagnostic packet MUST NOT be IP forwarded.
As I understand it, there could valid cases when a packet with an IPv6
address from the Discard-Only range will be forwarded based on that
address. If that is correct, then the IP/UDP encapsulated MPLS echo request
may be forwarded to the IP network if the LSP is broken on that node. Our
document aims to correct the misinterpretation of how the 127/8 IPv4 range
embedded in the IPv4-mapped IPv6 address range is handled.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Internet AD comments for draft-ietf-mpls-lspping-norao-07
> CC @ekline
>
> * comment syntax:
>   - https://github.com/mnot/ietf-comments/blob/main/format.md
>
> * "Handling Ballot Positions":
>   -
> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>
> ## Comments
>
> ### S4.
>
> * "entropy other than the IP destination address SHOULD be used"
>
>   Do you want to explicitly mention the IPv6 Flow Label here (RFC 6438)?
>
GIM>>  Thank you for your suggestion. Added references to MPLS Entropy
Label and IPv6 Flow Label as follows:
   *  To exercise all paths in an ECMP environment, the 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.