# Éric Vyncke, INT AD, comments for draft-ietf-mpls-mna-fwk-13
CC @evyncke

Thank you for the work put into this document. This framework is interesting as it extends to the "good old" MPLS the RFC 8986 network programming concepts.

I am balloting ABSTAIN for two reasons (see below). Nevertheless please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tarek Saad for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## ABSTAIN reasoning

### MPLS charter

Even after re-reading the MPLS WG charter, I was unable to understand how the MNA framework fits the MPLS WG charter. 

As I balloted 'No Objection' to draft-ietf-mpls-mna-usecases (also not fitting the MPLS charter) and as RFC 9613 is published, a DISCUSS ballot is no more an option.

### Who pushes MNA ?

It is unclear to me, after reading the I-D, whether it is only the source node that inserts MNA in the label stack.

If so, then why was this framework not done in SPRING WG ?

## COMMENTS (non-blocking)

### Impact on the MTU

Should the I-D discuss the MTU impact ?

### Abstract

s/This document specifies an architectural framework/This document describes an architectural framework/ as this is an informational document.

### Section 1.1

It seems that the uppercase BCP14 terms are used inconsistently in the text (I can be wrong though), i.e., only using lower case may be more suitable.

### Section 2

How can ancillary data be carried when there are no LSE in `In-Stack Data (ISD): A set of zero or more LSEs that carry ancillary data` ?

Suggest adding the payload in figure 1 as in figure 2.

### Section 2.3

`If a node does not support MNA, then the node will simply ignore any network actions in the packet` seems to contradict the list of alternatives of section 2.2.

### Section 2.4

`In particular, one packet may affect subsequent packets in the same LSP` out of curiosity, can on MNA packet affect processing in other LSP? Is it worth mentioning in the text ?

### Section 3

s/In this section, we summarize/This section summarises/ as "we" is ambiguous (authors? WG? IETF community?)

### Section 3.2.2

Will the re-use of the TC & TTL fields cause any interoperation issues with deployed devices ? I would fear that the TTL field would be acted upon by MNA-unaware nodes.

### Section 3.5

Should there be some guidance on whether a IANA registry should be created for the bits / opcodes ? Section 5 says yes, but an early indication is probably useful.

### Section 7

`on-path modification of the MNA data` is this on-path modification described earlier in the document ?

### Section 8

Adding a URI for the registry, e.g., https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types, as a reference could be helpful.

Also specify "MPLS" as the data-plane value for the new entry.

## NITS (non-blocking / cosmetic)

### SVG graphics

Suggest giving a try to the "aasvg" tool to have nicer graphic rendering in HTML.

### Section 3

A "does" is probably missing in `a solution not add unnecessary LSEs`.