[mpls] AD review for draft-ietf-mpls-mna-requirements-12

[James Guichard <[e-mail]>]

Dear Authors,

Thank you for an easy to read and well-structured document. I have a few comments – note review shows line numbers from idnits of the v-12 document:


78      termed MPLS Network Actions, for enhanced forwarding or other



Jim> I note that MNA is used throughout the document, and it looks like the above is the first use. Can you update to say ‘MPLS Network Actions (MNA)’ above.



Jim> What does ‘enhanced forwarding’ mean? I think it would be worth expanding a little on this to make it clear how enhanced forwarding differs from regular MPLS forwarding. Same comment for ‘other processing of MPLS packets’ - an example of such ‘other processing’ would be clearer.



81      that can be used across these use cases in order to minimise



Jim> typo replace ‘minimise’ with ‘minimize’.



83      extensibility.  This mechanism needs to conform to the existing MPLS



Jim> The above implies that there is a single mechanism which may or may not be true. I would suggest replacing ‘This mechanism’ with ‘These protocol extensions…’ or something along those lines.



84      architecture as specified by, among other documents, [RFC3031],

85      [RFC3032], and [RFC6790].



Jim> Okay no doubt someone is going to ask what these ‘other documents’ are. I would suggest removing the text ‘among other documents’ and only list RFCs that are specific to the MPLS architecture.



114   1.1.  Terminology



116     *  Network Action: An operation to be performed on a packet or as a

117         consequence of a packet being processed by a router.  A network

118         action may affect router state, packet forwarding, or it may

119         affect the packet in some other way.



Jim> Isn’t all this specific to MPLS packets and if so, ‘MPLS’ should be inserted in front of all occurrences of ‘packet’ in the above paragraph (and elsewhere in the document).



121     *  Network Action Indicator (NAI): An indication in the packet that a

122         certain network action is to be performed.



Jim> Same comment as above - insert MPLS in front of ‘packet’.



220     12.  The design of any network action solution MUST NOT expose

221           information that is not already exposed by the LER to the LSRs.



Jim> This requirement has me scratching my head. Does it mean that a network action can only be performed using information that is already carried in existing MPLS packets thereby prohibiting adding addition information that could be useful to the network action?



239     17. Special Purpose Labels (SPLs) are a mechanism of last resort, and

240         therefore an MNA solution that uses them MUST minimise the number



Jim> Typo ‘minimize’ change to ‘minimize’.



243   3.3.  Requirements on Network Actions



245     18. Is it RECOMENDED that an MNA specification support network

246         actions for private use [RFC8126].



Jim> Typo ‘RECOMENDED’ change to ‘RECOMMENDED’ and ‘Is it’ change to ‘It is’ above. Also, please update the reference to point to Section 4.1 of [RFC8126] as at first glance it was unclear why you used [RFC8126] as a reference.



286     28.  An MNA solution SHOULD support NAIs for both P2P and P2MP paths,



Jim> Please expand P2P and P2MP on first use as neither are well-known abbreviations listed here https://www.rfc-editor.org/materials/abbrev.expansion.txt.



352     46.  Any MNA solution specification MUST describe whether it can

353           coexist with existing post-stack data mechanisms (e.g., control

354           words and G-ACH), and if so how this coexistence operates.



Jim> Please expand G-ACH on first use.

Thanks!

Jim