Last Call Review of draft-ietf-mpls-mna-fwk-12
review-ietf-mpls-mna-fwk-12-tsvart-lc-ott-2024-11-12-00
Request | Review of | draft-ietf-mpls-mna-fwk |
---|---|---|
Requested revision | No specific revision (document currently at 14) | |
Type | Last Call Review | |
Team | Transport Area Review Team (tsvart) | |
Deadline | 2024-11-11 | |
Requested | 2024-10-21 | |
Authors | Loa Andersson , Stewart Bryant , Matthew Bocci , Tony Li | |
I-D last updated | 2024-11-12 | |
Completed reviews |
Rtgdir Early review of -06
by Toerless Eckert
(diff)
Rtgdir Last Call review of -11 by Donald E. Eastlake 3rd (diff) Secdir Last Call review of -11 by Catherine Meadows (diff) Genart Last Call review of -12 by Jouni Korhonen (diff) Secdir Last Call review of -12 by Catherine Meadows (diff) Tsvart Last Call review of -12 by Joerg Ott (diff) |
|
Assignment | Reviewer | Joerg Ott |
State | Completed | |
Request | Last Call review on draft-ietf-mpls-mna-fwk by Transport Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/tsv-art/F8h7J3RPQUAa5R6_315YOnCGrPI | |
Reviewed revision | 12 (document currently at 14) | |
Result | Ready w/nits | |
Completed | 2024-11-12 |
review-ietf-mpls-mna-fwk-12-tsvart-lc-ott-2024-11-12-00
This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This document define a rough framework on how to signal "network actions" and their parameters in an MPLS label stack, documenting how they could be encoded and identified. There are no obvious transport layer implications of this framework as the packets are carried anyway. The only consideration that comes to mind is that growing MPLS label stacks describing sophisticated actions with many parameters could affect the residual MTU size of the IP packet preceded by the MPLS label. My nits are essentially two questions, unrelated to transport specifics: 1. The document shall be informational in nature, but uses normative language when it comes to expressing what individual definitions of network actions shall include. But it seems that this normative style is not fully carried through, so that I would advise the authors to do one more pass to validate that all occurrences of must/may/... vs. MUST/MAY/... are correct. 2. The document describes many choice of how a given solution for a certain network action may realise, e.g., parameter encoding. I value the freedom put forward here but should the framework document provide more guidance in places? It does so in some places, e.g., by suggesting that a solution needs to justify their choice under certain circumstances. (This reads a bit odd -- to whom would somebody justify and who is to judge?) I am just curious how much openness is needed or desirable or necessary as opposed to limiting the design space. Such deliberate choice could be made explicit in the beginning. As a concrete example, a solution will have to specify how to skip unknown data. Given the many different options how to encode what, will it is obvious how to achieve this? How about the reuse of elements across solutions? Could interoperability of different design choices be achieved?