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

[Erik Kline <[e-mail]>]

On Wed, Feb 21, 2024 at 3:25 PM Greg Mirsky <[e-mail]> wrote:
>
> 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 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.

Understood; thank you.  Others have contacted me unicast to transmit
more clue in my direction as well.  :D

Changing ballot to NoObj.

>> ----------------------------------------------------------------------
>> 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.

thx