Skip to main content

Early Review of draft-ietf-mpls-1stnibble-02
review-ietf-mpls-1stnibble-02-rtgdir-early-halpern-2023-12-27-00

Request Review of draft-ietf-mpls-1stnibble-02
Requested revision 02 (document currently at 12)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2024-01-09
Requested 2023-12-18
Requested by Adrian Farrel
Authors Kireeti Kompella , Stewart Bryant , Matthew Bocci , Greg Mirsky , Loa Andersson , Jie Dong
I-D last updated 2023-12-27
Completed reviews Rtgdir Early review of -02 by Joel M. Halpern (diff)
Secdir Last Call review of -11 by Daniel Migault (diff)
Opsdir Last Call review of -10 by Qin Wu (diff)
Genart Last Call review of -10 by Joel M. Halpern (diff)
Comments
In preparation for WG last call, we would like a Routing Directorate review to determine whether this document i appropriate and in a good enough state to proceed.

Ideally a reviewer will have MPLS knowledge and an understanding of how IANA works. Pseudowire and BIER understanding would help.
Assignment Reviewer Joel M. Halpern
State Completed
Request Early review on draft-ietf-mpls-1stnibble by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/2nAIn1oJd2WF2wuVOjhaQHmnSqs
Reviewed revision 02 (document currently at 12)
Result Not ready
Completed 2023-12-27
review-ietf-mpls-1stnibble-02-rtgdir-early-halpern-2023-12-27-00
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.