Skip to main content

Early Review of draft-ietf-mpls-lsp-ping-lag-multipath-03
review-ietf-mpls-lsp-ping-lag-multipath-03-rtgdir-early-hardwick-2018-05-22-00

Request Review of draft-ietf-mpls-lsp-ping-lag-multipath-03
Requested revision 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 revision 03 (document currently at 08)
Result Has Issues
Completed 2018-05-22
review-ietf-mpls-lsp-ping-lag-multipath-03-rtgdir-early-hardwick-2018-05-22-00
Hello

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

https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-lag-multipath/

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

Jon

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

Reviewer: Jonathan Hardwick

Review Date: 21 May 2018

Intended Status: Standards Track

Summary

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? NEW
  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.
END

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.