[mpls] Looking at draft-sxg-mpls-mna-deterministic-latency

[Adrian Farrel <[e-mail]>]

Thanks for this draft. I see it has bounced around a bit, but I 
believe you have now settled on the right positioning:
- It's an MPLS WG topic
- It is targeted for MNA

It is good to have a proposed solution for one of the MNA use cases.

I found the term "deterministic latency" hard to resolve without reading
the whole document. "Bounded latency" is explained in section 1 with a
brief definition and a pointer to RFC 9320. That's great, but can you 
also add a definition of deterministic latency near the top of the
Introduction? And perhaps a more detailed definition in section 3.2.

You might add [I-D.ietf-mpls-mna-fwk] and 
[I-D.ietf-mpls-mna-requirements] to section 2.2

In Figure 1 (like Figure 1 of RFC 8964) it is really important that you
mark "top of stack" and "bottom of stack" because the picture is 
non-intuitively "upside down". It is correct that you follow the format
of 8964, but you need to highlight this. In particular, Figure 2 reverts
to the "normal" way of displaying LSE ordering.

In section 2, I see that you are assuming that the DLNA will always be
carried by a Type C LSE. I think we have to consider the case where the
DLNA is the only MNA in the packet. In this case, are you assuming that
a Type B LSE will be included with opcode=2? You just need to add a few
words for this.

draft-ietf-mpl-mna-hdr has been a moving target! You need to do a little
work in Figure 2 to catch up with the latest LSE formats.

Can you give any advice for the setting of the U-bit and IHS for the 
DNSL case?

Quite a bit more work will be needed to explain what ancillary data is
carried and how it is encoded. Part of this will be explaining why you 
leave some of the bits in the Type C LSE as reserved.

For section 6, please consider that the MPLS header is not normally
protected. What would happen if an attacker changed the values in the
ancillary data? How can this be protected (