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 ​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-mpls-entropy-lsp-ping-03
Reviewer: Acee Lindem
Review Date: 08/03/2016
IETF LC End Date: Not started
Intended Status: Standards Track

Summary:
    This document is basically ready for publication, but has some minor
issues and nits that should be resolved prior to publication.


Comments:
    
This document defines encodings and procedures to allow LSRs supporting
LSP Ping [RFC4379, RFC 6424] and MPLS Entropy Label Forwarding [RFC6790]
to 
steer traffic on all the ECMP paths for the target LSP. The specifications
cover both the initiating LSR and the responding LSR. The document contains
very precise specifications. However, detailed understanding of the
updated 
documents is required.

Major Issues:

    I have no major issues with the document.

Minor Issues:


    1. In many cases, the text is missing articles (i.e., “the, “a”, “an).
       Andy Malis has agreed to take a pass at adding these where they are
       needed. 

    2. It seems the order of this document is wrong. I would have expected
       the encodings in sections 7, 8, and 9 to precede the procedures in
       sections 5 and 6.

    3. Similarly, section 10 could be summarized in section 1.3 and,
perhaps,
       the details could be moved to an appendix.

   [RFC4379], [RFC6424] and this document will support IP-based
   Load Balancers and Label-based Load Balancers which limit their hash
   to the first (top-most) or only Entropy Label in the label stack. Other
   use cases (refer to section 10) are out of scope.
     
    4. RFC 6424 should be a normative reference based on section 1.3 and
the
       fact that it is updated by this document.

    5. For Associated Label Multipath Information, provide a reference for
       how the 24-bit labels are encoded. Is it the same as {9}?

    6. For Associated Label Multipath Information, don’t the labels
       correspond to the same order as the IP addresses or labels in the
       previous sections? The example is confusing since it alludes to
       the “lowest IP address” which could imply that the associated label
       mapping is based on the value of the address.

    7. In section 6.4, the last bullet on page 12 is confusing to me. Can
       you explain why the '“Label Multipath Information” sections MUST
NOT 
       be used’? I seem to be missing something here as I would have
guessed
       that it would be returned.


Nits: 

    1. In the terminology section, add a reference for [RFC6391] where the
       Flow Label is first referenced.

    2. In section 7, refer to IANA value TBD1. Also, it would improve the
       text if RFC6790 were referenced in the discussion of ELI and EL.
 
    3. In the IANA section, why is the Entropy Label FEC not first as it is
       in the document?

    4. In section 9, indicate lengths should be 0 when a section is
omitted. 

    5. In section 2, indicate where in RFC 4379, {x, y, and z} are
defined. 

    6. Please use “e.g., “ and “i.e., “ consistently instead of variants
       such as “ex:”.

    7. In the last paragraph of section 2, “Label Based Load Balancer” is
       listed twice.

    8. In section 6.2, replace “is it not there” with “it is not there”.


Thanks,
Acee