Last Call Review of draft-ietf-teas-assoc-corouted-bidir-frr-04
review-ietf-teas-assoc-corouted-bidir-frr-04-rtgdir-lc-ceccarelli-2018-07-29-00

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<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-teas-assoc-corouted-bidir-frr-04
Reviewer: Daniele Ceccarelli
Review Date: 27/07/2018
IETF LC End Date: date-if-known
Intended Status: Standard track

Summary:

  *   I have some minor concerns about this document that I think should be
  resolved before publication.

Comments:

  *   The document is very well written and the problem clearly stated (even if
  called overview 😊 ). The second part is a bit harder to follow but I don’t
  see how to make the procedure section easier to read. *   It is not clear to
  me why there is an “example” of Extended Association ID in the appendix. RFC
  6780 just says it “contains data that is additional information to support
  unique identification.” But doesn’t describe how it should be filled. Does
  this mean there is no standard format for it ?

Major Issues:

None

Minor Issues:

  *   Moving the terminology section before the introduction would improve
  readability, since the terms defined in the terminology section are
  frequently used in the introduction. *   When I read the title of section 3
  (overview), I thought “why an overview is needed if there is an
  introduction?”. Actually the text in that section is very useful but more
  than an overview I would call it a problem statement (or something like
  that). *   The usage of RFC 2119 (or should we reference RFC 8174 ??) is not
  congruent all over the document. E.g. section 4.1

  o  The downstream PLR node always initiates the bypass tunnel

      assignment for the forward LSP.  The upstream PLR (forward

      direction LSP MP) node simply reflects the associated bypass

      tunnel assignment for the reverse direction LSP.  The upstream PLR

      node MUST NOT initiate the bypass tunnel assignment.

Nits:

  *   Section1: “(G)Multiprotocol Label Switching (MPLS) Traffic Engineering
  (TE) Label Switched Paths (LSPs)”. This formatting doesn’t make much sense.
  In the first instance the brackets are used to say MPLS or GMPLS while in the
  other ones to define the acronyms. *   Section 3.1 there is no need to repeat
  twice that Bypass tunnel N uses path B-H-I-C and Bypass tunnel S path
  B-F-G-C. The second time the bracket can be dropped. *   Section 4.1.1. - 
  s/SHOULD trigger the procedure/ SHOULD trigger procedure

BR
Daniele