Re: [RTG-DIR] RtgDir review: draft-ietf-teas-gmpls-lsp-fastreroute-07.txt

[Mach Chen <[e-mail]>]

Hi Rahesh,

Thanks for considering my comments and the quick updates!

Please see my reply inline...

> -----Original Message-----
> From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]]
> Sent: Saturday, May 13, 2017 5:47 AM
> To: Mach Chen <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: RtgDir review: draft-ietf-teas-gmpls-lsp-fastreroute-07.txt
> 
> Hi Mach, WG,
> 
> Updated document that addresses the comments can be found at:
> 
> https://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-08
> 
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-gmpls-lsp-fastreroute-
> 08
> 
> 
> thanks,
> Rakesh
> 
> 
> On 2017-05-12, 7:42 AM, "Rakesh Gandhi (rgandhi)" <[e-mail]>
> wrote:
> 
>     Hi Mach,
> 
>     Many thanks for the detailed review of the document and your comments.
> Please see inline for replies with <RG>…
> 
> 
>     On 2017-05-12, 4:33 AM, "Mach Chen" <[e-mail]> wrote:
> 
>         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?
> 
>     <RG> Ok, we should remove the second bullet (copied below) to make it
> consistent for both cases.
> 
>     o  The upstream PLR R4 starts sending the Resv messages and traffic
>           flow of the protected LSP over the restored link towards
>           downstream PLR R3 and forwarding the Path messages towards PRR R5
>           and stops sending them over the bypass tunnel.

To make it consistent, the upstream PLR should freely re-direct the traffic over the restored link, but the Resv message will depends on the Path message.
So, instead of removing the whole bullet, I'd suggest the following changes:

OLD:
 o  The upstream PLR R4 starts sending the Resv messages and traffic
          flow of the protected LSP over the restored link towards
          downstream PLR R3 and forwarding the Path messages towards PRR R5
          and stops sending them over the bypass tunnel.

NEW:
o  The upstream PLR R4 starts sending the traffic
           flow of the protected LSP over the restored link towards
           downstream PLR R3 and forwarding the Path messages towards PRR R5
           and stops sending them over the bypass tunnel.

This also applies to Section 5.1.2

OLD:
o  The upstream PLR R4 starts sending the Resv messages and traffic
      flow of the protected LSP over the restored link and stops sending
      them over the bypass tunnel.

NEW:
o  The upstream PLR R4 starts sending the traffic
      flow of the protected LSP over the restored link and stops sending
      them over the bypass tunnel.


Other updates look good to me

Best regards,
Mach
> 
> 
>         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...
> 
>     <RG> Agree to update this.
> 
> 
>         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?
> 
>     <RG> Revised text suggested as following:
> 
>            As described in
>            Section 7 of this document, this subobject is not carried in the RSVP
>            Resv message and is ignored by sending the Notify message for FRR
> Bypass Assignment Error (with Subcode: Bypass Assignment Cannot Be Used)
> defined in this document.
>            Nodes not supporting the Notify message defined in this document will
> ignore it but forward it without modification.
> 
> 
>         Nits:
>         Section 5.1.1.
>         s/bypass tunnels T3/ bypass tunnel T3/
> 
>     <RG> Agree.
> 
>     Thanks,
>     Rakesh (for authors and contributors)
> 
> 
> 
> 
> 
>         Best regards,
>         Mach
> 
> 
>