Early Review of draft-akiya-mpls-lsp-ping-reply-mode-simple-03

Request Review of draft-akiya-mpls-lsp-ping-reply-mode-simple
Requested rev. no specific revision (document currently at 03)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2014-09-08
Requested 2014-08-21
Authors Nobo Akiya, George Swallow, Carlos Pignataro, Loa Andersson, Mach Chen
Draft last updated 2014-09-08
Completed reviews Rtgdir Early review of -03 by Lou Berger
Assignment Reviewer Lou Berger 
State Completed
Review review-akiya-mpls-lsp-ping-reply-mode-simple-03-rtgdir-early-berger-2014-09-08
Reviewed rev. 03
Review result Has Nits
Review completed: 2014-09-08


    I've been asked to do a QA review of this draft. Overall it looks
like a solid,  well written document,  and more than reasonable -00 WG

I have some technical nits/comments/questions that I think can be
addressed as part of normal WG process:

Section 3.1
- "Reverse LSP is in relation to the last FEC  specified in the Target
FEC Stack TLV."
I think I understand this statement for the egress, but what about at
transit nodes?  Perhaps just drop the sentence?

- Missing "in the range of" in the last sentence of the section.

Section 3.2
- The phrasing of 4 is a bit stricter than I think you mean with respect
to use of Reply Mode field.  One could read it as saying that a value
carried in the field can't be used even when it is in the Order TLV, as
well as precluding its use described in the subsequent requirement (5). 
Perhaps just rephrase to say that it is only used after any mode
included in the ordered TLV is excluded/invalid/unavailable.

-I think the document should be explicit about ordering relationship of
the reply modes listed in the Order TLV and to the order of paths
included in other TLVs, e.g., sub-TLVs/FECs in the Reply Path TLV.  (Yes
it should obvious, but it is a potential interop issue)

- Section 4.1.1
 o The Reply Path TLV carrying {FEC X, FEC Y}
Wouldn't it be cleaner, particularly when considering non-draft
supporting implementations, to use multiple Reply Path TLVs (one per
possible reply path)?

That's it,