Skip to main content

Last Call Review of draft-ietf-teas-gmpls-lsp-fastreroute-07
review-ietf-teas-gmpls-lsp-fastreroute-07-rtgdir-lc-chen-2017-05-12-00

Request Review of draft-ietf-teas-gmpls-lsp-fastreroute
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-05-12
Requested 2017-04-26
Requested by Deborah Brungard
Authors Mike Taillon , Tarek Saad , Rakesh Gandhi , Zafar Ali , Manav Bhatia
I-D last updated 2017-05-12
Completed reviews Rtgdir Last Call review of -07 by Mach Chen (diff)
Secdir Last Call review of -09 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -09 by Francis Dupont (diff)
Comments
Prep for Last Call.
Assignment Reviewer Mach Chen
State Completed
Request Last Call review on draft-ietf-teas-gmpls-lsp-fastreroute by Routing Area Directorate Assigned
Reviewed revision 07 (document currently at 12)
Result Has issues
Completed 2017-05-12
review-ietf-teas-gmpls-lsp-fastreroute-07-rtgdir-lc-chen-2017-05-12-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. 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

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-gmpls-lsp-fastreroute-07.txt
Reviewer: Mach Chen
Review Date: 12 May 2017
Intended Status: Informational

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

Comments:
This document is clearly written and easy to understand.

Major Issues:
No major issues found.

Minor Issues:

1. Section 5.
The behavior of Path and Resv messages  process "After Link Failure" is
different from the behavior of " Revertive Behavior After Fast Reroute". For
example, for "After Link Failure" case, which link the Resv messages will send
over depends on the link over which the Path messages are received, but for "
Revertive Behavior After Fast Reroute" case, the Path and Resv messages are
sent independently. Is this the intention, or is it necessary to unify the
behavior?

2.
Section 7.1.  BYPASS_ASSIGNMENT Subobject

Two subobjects are defined in this section, the authors try to use unified text
to explain the two subobjects, but IMHO, this is not a good way to describe
multiple different subobject. Based on the current text, I think the authors
are trying to use a single Type for both subobjects, but after reading the IANA
section, obviously it's not.  So, I'd suggest to use dedicated describe test
for specific subject, and for the type, it's better to use TBA1, TBA2...

3.
Section 8
"As described in
   Section 7 of this document, this subobject is not carried in the RSVP
   Resv message.  A new Notify message for FRR Bypass Assignment Error
   is defined in this document."

What's sub-code will be sent when BYPASS_ ASSIGNMENT subobject is carried in
the RSVP message?

Nits:
Section 5.1.1.
s/bypass tunnels T3/ bypass tunnel T3/

Best regards,
Mach