[mpls] Re: Éric Vyncke's Discuss on draft-ietf-mpls-mna-hdr-20: (with DISCUSS)

[Adrian Farrel <[e-mail]>]

Hi Eric, All,

Thanks for the progress with this.

Speaking as a participant, I agree with you that:
- the reference to [I-D.liu-lsr-mpls-inspection-msd] is a bad idea
- "signaling" is a limited term to use and other methods are available.

I think that the existing reference to RFC 9789 for the definition of RLD is good.
I note that 9789 section 2.3.1 has:
   A node that pushes a NAS onto the label stack is responsible for
   ensuring that all nodes that are expected to process the NAS will
   have the entire NAS within their RLD.  A node SHOULD use signaling
   (e.g., the signaling described in [RFC9088] and [RFC9089]) to
   determine this.  An exception might be, for example, when the node
   has out-of-band knowledge that all nodes along the path do not have
   RLD limitations and thus could avoid the unnecessary overhead of
   using signaling.
I also note that 9789 provides a mechanism to use an IGP to distribute the MLD capabilities of a node.

So, I would trim as Eric suggests and leave the reader to look it up in 9789.

Cheers,
Adrian
-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]> 
Sent: 20 February 2026 12:41
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [mpls] Éric Vyncke's Discuss on draft-ietf-mpls-mna-hdr-20: (with DISCUSS)

Éric Vyncke has entered the following ballot position for
draft-ietf-mpls-mna-hdr-20: 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-mna-hdr/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document and its revised -20. This work
looks very similar to the IPv6 extensions headers and to SRv6 Network
Programming. So, as INT AD and working with IPv6 extension headers for 15+
years, I am afraid that I have some real concerns about this document. And, as
usual, I will be happy to stand corrected.

Thanks for addressing all other blocking DISCUSS and non-blocking COMMENT point
(see https://mailarchive.ietf.org/arch/msg/mpls/U303kD5kcFD0DOwboBWIHOpxtPQ/)

The -20 is in much better shape and more readable (especially section 3).

BUT here is still one remaining blocking DISCUSS point (see below).

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

### Section 7 (and now content of section 8)

`If the NAS is to be processed by a downstream MNA-capable node, then the
entire NAS MUST be placed so that it is within RLD by the time the packet
reaches the downstream MNA-capable node` is missing a normative reference on
how a node knows about the RLD of the downstream node.

The section 8 in -20 has a new paragraph:

`The encapsulating node MAY learn about RLD of the nodes in the path via
signalling. The work in-progress document [I-D.liu-lsr-mpls-inspection-msd]
defines the mechanism to signal MPLS RLD.`

The MAY here is the issue. Why not "The encapsulating node MUST learn about RLD
of the nodes in the path." ? Again, my IPv6 experience leads me to consider the
proposed system as really fragile.

I also fear that the informative reference [I-D.liu-lsr-mpls-inspection-msd] is
an individual draft expired since March 2024...





_______________________________________________
mpls mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]