Early Review of draft-akiya-mpls-lsp-ping-reply-mode-simple-03
review-akiya-mpls-lsp-ping-reply-mode-simple-03-rtgdir-early-berger-2014-09-08-00
| Request | Review of | draft-akiya-mpls-lsp-ping-reply-mode-simple |
|---|---|---|
| Requested revision | 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 revision | 03 | |
| Result | Has Nits | |
| Completed | 2014-09-08 |
review-akiya-mpls-lsp-ping-reply-mode-simple-03-rtgdir-early-berger-2014-09-08-00
Hello,
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
document.
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,
Lou