Early Review of draft-ietf-mpls-mna-requirements-05
review-ietf-mpls-mna-requirements-05-rtgdir-early-vainshtein-2023-07-05-00

Hello
I have been selected to do a routing directorate “early” review of this draft:
draft-ietf-mpls-mna-requirements-05.

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

The draft in question is a WG document, has been adopted about 1 year ago and
is not yet in the WG Last Call. It has been extensively discussed in the MPLS
Open Design Team. I have asked Loa (who is the shepherd of this draft) for the
reasons for and the purpose of this review, and he has said that the draft “is
a going into the WGLC process, we want the comments early, i.e.  before we
start the WGLC, after all it is supposed to be "early", after the WGLC is too
late in the process. Better to have the RTG Area Early comments fully available
to the WG during the WGLC ”. For more information about the Routing
Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-mpls-mna-requirements-05
Reviewer: Alexander (“Sasha”) Vainshtein
Review Date: 06-Jul-23.
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think should be resolved
before it is submitted to the IESG. Comments: The draft is well written and
easy to read. As the title clearly states, this draft presents generic
requirements that should be met by any specific MPLS Network Actions (MNA)
solutions. As a generic comment, I am not sure whether the IETF reserved terms
for indication of requirement levels can be used in an Informational document,
this is for the WG Chairs and ADs to decide. But I think that usage – or
non-usage – of these terms should be consistent in the document, and this
condition is not met in this draft. It contains: -       Requirements that use
the reserved IETF keywords (e.g., “Any MNA solutions to these requirements MUST
NOT restrict the generality of MPLS architecture”) -       Requirements that
use the non-capitalized words that, in their capitalized form, become the IETF
keywords (e.g., “An MNA solution MUST respect the principle that Special
Purpose        Labels are the mechanism of last resort and therefore must
minimize the number of new SPLs that are allocated“). Having a mix of
capitalized and non-capitalized terms in the same requirement looks problematic
to me -       Requirements that do not include any words that can be associated
with the IETF reserved keywords (e.g., “NAIs are normally inserted at LERs, but
MAY be processed at LSRs and LERs”). I have sent my early comments to the draft
authors, and they suggested that these should be submitted as the RTG-DIR
review without any private discussions. I am following this suggestion after
adopting these comments to the RTG-DIR Early review template format. MAJOR
ISSUES: None found.

MINOR ISSUES:
1.      The draft mentions RFC 3031 and RFC 3032 as the references for the MPLS
architecture, but it does not mention RFC 5331 that augments MPLS architecture
with upstream-allocated labels,  label context spaces and “context labels”.
Does this mean that MNA is expected to be incompatible with upstream-allocated
labels and/or context label spaces? If yes, it would be nice to have this
stated explicitly. 2.      Item #7 in Section 3.1 as well as items #2 and #3 in
Section 3.4 seem to imply preference to Post-stack ancillary data vs. In-stack
one. Is this really the intention? If not, please consider stating explicitly
that these requirements do not preclude usage of In-stack ancillary data. 3.   
  Section 3.9 of RFC 3031 states that “the processing is always based on the
top label, without regard for the possibility that some number of other labels
may have been "above it" in the past, or that some number of other labels may
be below it at present”.  (This principle has been tweaked when “context
labels” have been introduced in RFC 5331.)  IMHO and FWIW, it would be useful
to explain what should happen to this architectural principle with regard to
MNA. 4.      I suggest augmenting item #3 in Section 3.2 with a statement that
reuse of an already allocated SPL for MNA purposes would require its retirement
and re-allocation in accordance with the process defined in RFC 7274. (This
comment is based on the discussion of re-use of GAL for MNA in the early days
of the MPLS Open Design Team). 5.      Do items#8 and #9 in Section 3.3
consider SR-MPLS as one of the relevant control plane protocols? May I suggest
that an explicit list of such protocols be provided to avoid any possible
misunderstandings? 6.      Item #12 in Section 3.3 states that “NAIs are
normally inserted at LERs “: a.      As mentioned above,. this statement does
not carry any IETF keyword (MUST or SHOULD) to indicate the requirement level
b.      I suspect that normality, like beauty, is in the eye of the beholder. A
more suitable wording could be “LSRs SHOULD NOT insert NAI” (or something like
that) 7.      Can you please clarify whether the requirement in item#10 of
Section 3.4 can be addressed by an LER that is a head-end of an SR Policy (RFC
9256) that uses Binding SIDs in its list of segments? a.      Usage of Binding
SIDs makes control over the depth of the label stack quite problematic for the
head-end of an SR Policy b.      Another case when such control is problematic
is usage of TI-LFA or Segment Routing Micro-loop Avoidance mechanisms. NITS: 1.
     The draft refers to draft-saad-mpls-miad-usecases for the description of
new MPLS use cases (both in the Introduction and Background sections).
According to the Datatracker this draft has been replaced by the MNA Usecases
draft that is a MPLS WG document.  IMHO the reference should updated
accordingly. 2.      I did not run the ID Checker on the draft, so could have
missed other nits. Hopefully, these notes will be useful. Regards, Sasha