[mpls] Re: [iesg] Re: Éric Vyncke's Discuss on draft-ietf-mpls-mna-nrp-selector-04: (with DISCUSS and COMMENT)

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

Hello Tony,

Thanks for your patience but my $dayjob in May was hectic especially combined with European bank holidays in May 😉 So, thanks to Adrian for the gentle nudge.

I have read the -06 and it addresses most of my DISCUSS/COMMENT issues.

The remaining ones are the ones that you commented on below. See below for my replies prefixed by EV> and I would appreciate (i.e., not require) an action there. Anyway, I am clearing my DISCUSS.

The INT-DIR review was the basis of one of my DISCUSS point, may I suggest a reply to this review ? I.e., writing that -06 has addressed the issue.

Regards,

-éric

From: Tony Li <[e-mail]> on behalf of Tony Li <[e-mail]>
Date: Friday, 1 May 2026 at 16:38
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: The IESG <[e-mail]>; Adrian Farrel <[e-mail]>; [e-mail] <[e-mail]>; Jen Linkova <[e-mail]>; mpls-chairs <[e-mail]>; mpls <[e-mail]>
Subject: [iesg] Re: Éric Vyncke's Discuss on draft-ietf-mpls-mna-nrp-selector-04: (with DISCUSS and COMMENT)


Hi Eric,

> ### Deployment (Section 3)
>
> Please be clear whether all devices must have this feature enabled (e.g., if
> not the case, then traffic is still flowing but without isolation/QoS/...).


This comment should be directed to the TEAS NRP architecture.  MPLS will happily transport the NRPS over nodes that do not support it, if requested.  This is the whole point of the U bit in the ISD LSE Formats.

EV> up to you whether you think that the last 2 sentences above should appear in section 3

> ### Section 5
>
> Please add some privacy considerations as the NRP itself may leak some
> information about the packet content (even if transport/application crypto is
> used). It is also unclear whether the NRP values are opaque.


The forwarding plane is insecure. There is no privacy. The NRPS is opaque to MPLS in that it’s just a value, without any semantics at the MPLS level.

EV> thanks, strongly suggest adding the last sentence to the section and adding "therefore no information about the data is leaked".


> I will let the SEC ADs to comment further, but I find the security
> considerations section rather light.


MPLS is insecure. It operates in a ‘limited domain’. This is not news.


> ### Link with TEAS RFC 9543 ?
>
> While this document has an informative reference to RFC 9543 for some
> definitions, it does not explain the relationship (noting that RFC 9543 was
> published in 2024). I would have expected some use cases when this I-D could be
> used within RFC 9543 framework.


Those would belong in draft-ietf-teas-ns-ip-mpls.


> ### Use of SVG graphics
>
> To make a much nicer HTML rendering, suggest using the aasvg tool to generate
> SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
> format ;-)


Clarity and ubiquiti for formats is much more important than pretty pictures.

Regards,
Tony