Early Review of draft-ietf-mpls-lsp-ping-lag-multipath-03

Request Review of draft-ietf-mpls-lsp-ping-lag-multipath-03
Requested rev. 03 (document currently at 08)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2018-03-31
Requested 2018-03-12
Requested by Loa Andersson
Authors Nobo Akiya, George Swallow, Stephane Litkowski, Bruno Decraene, John Drake, Mach Chen
Draft last updated 2018-05-22
Completed reviews Rtgdir Early review of -03 by Jonathan Hardwick (diff)
Secdir Last Call review of -05 by Linda Dunbar (diff)
Genart Last Call review of -05 by Christer Holmberg (diff)
Tsvart Last Call review of -05 by Joerg Ott (diff)
Opsdir Last Call review of -05 by Zitao Wang (diff)
Secdir Telechat review of -06 by Linda Dunbar (diff)
Assignment Reviewer Jonathan Hardwick
State Completed
Review review-ietf-mpls-lsp-ping-lag-multipath-03-rtgdir-early-hardwick-2018-05-22
Reviewed rev. 03 (document currently at 08)
Review result Has Issues
Review completed: 2018-05-22



I have been selected to do a routing directorate “early” review of this draft.


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.  As this document is close to working group last call, my focus for the review was to determine whether the document is ready to be published.  Please consider my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Best regards


Document: draft-ietf-mpls-lsp-ping-lag-multipath-03.txt

Reviewer: Jonathan Hardwick

Review Date: 21 May 2018

Intended Status: Standards Track


This document looks ready for working group last call.  I have a few minor issues that I am sure can be resolved during the last call.

Section 2
First paragraph: the reference to section 3.3 of [RFC8029] looks wrong.  Should it be a reference to section 4?

Section 3
“When the responder LSR receives an MPLS echo reply message” <- you mean “MPLS echo request message”.

Section 5.1
This is fine, but I found it a bit cumbersome to read.  How about this rewording?
  If the downstream LSR does not return Remote Interface Index sub-TLVs in
  the DDMAP, then the initiator LSR validates LAG member link traversal by
  traversing all available LAG member links and then using the procedure described
  below.  This section provides the mechanism for the
initiator LSR to obtain additional information from the downstream
LSRs and describes the additional logic in the initiator LSR to
validate the L2 ECMP traversal.

Section 5.1.3
For my interest, why are you using “entropy” here?  It sounds like you mean “probability”, but I might have misunderstood your meaning.

Top of page 13:
   The initiator LSR sends two MPLS echo request messages to traverse
   the two LAG members at TTL=1:
“TTL=1” should be “TTL=n”.

Section 6
Typo “in the in the”

Section 8 and 9
This draft only discusses using the new Local & Remote Interface Index Sub-TLVs in the context of a DDMAP for a LAG interface, so I was surprised to read that it is permissible to set M=0 in these TLVs.  You should describe how the TLV is used in that case, if you are going to allow it.
Does the M flag need to be set consistently in all Local & Remote Interface Index Sub-TLVs  in a given DDMAP TLV?
In fact, isn’t the M flag redundant, given that the enclosing DDMAP has the "LAG Description Indicator flag"?

Section 10
Why do you need the Sub-TLV length field?  It can be inferred from the TLV length and the address type.
Section 10.1.1 – if the LSR received no labels (e.g. PHP case) then should it omit this sub-TLV, or include an empty sub-TLV?

Other nits
Throughout, English grammar needs to be fine-tuned e.g. there are definite and indefinite articles missing.  However, I found the document perfectly readable, so perhaps this can be left for the RFC editor.