Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir

This is a requested early Routing Directorate review, and as such is intended to help the Working Group and Document Editors with the subject document.

Document: draft-ietf-mpls-1stnibble-02
Reviewer: Joel Halpern
Review Date: 27-Dec-2023
IETF LC End Date: N/A
Intended Status: Proposed Standard

Summary:
    I have some minor concerns about this document that I think should be resolved.

Major:

Minor:
   The parantheticl about IP packets in the "embedded packet" definition is worded to imply that one would only put IP into MPLS for traffic engineering or VPN purposes.  This seems misleading to me, and I strongly suggest removing the parenthetical.

    Bullet 3 in section 2.1.1 on Load Balancing asserts that guessing the content type is always better than not doing so for load balancing purposes.  If one guesses wrong, that may well not be true.  I would suggest adding to the bullet a forward reference to the text below to caveat "even better".  

     Section 2.1.3 is titled "recommendation" and starts with a "SHOULD", but then has a "MUST NOT" which does not seem to be qualified by the "SHOULD"  It is unclear whether this is a flat requirement (belonging in the previous section) or is intended for when the "SHOULD" is being obeyed.

Nits:
    The reference in the introduction to the MPLS Open Design team should be edited to refer to the MPLS Working group, since there is no longer an MPLS Open Design Team.

    Should "LSE" be expanded on first use? (And included in the list of abbreviations?)

    The paragraph at the end of the introduction needs to be resolved.  I would suggest removing it.  As far as I can tell, the WG has evinced little desire to make the change described there.

    Paragraph 2 of section 2.1.3 on "recommendation" referes to "recommendation 2".  But the recommendations (and requirements) are not numbered.  So what is the referent?

    From I-D Nits

  ** The document seems to lack a Security Considerations section.

  ** The abstract seems to contain references ([RFC4928]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  == The 'Updates: ' line in the draft header should list only the _numbers_
     of the RFCs which will be updated by this document (if approved); it
     should not include the word 'RFC' in the list.