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

[Mach Chen <[e-mail]>]

Hi Rakesh,

Looks good me!

Best regards,
Mach

> -----Original Message-----
> From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]]
> Sent: Monday, May 15, 2017 8:27 PM
> 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,
> 
> Thanks for the suggestions.
> 
> Updated the draft accordingly and can be found at:
> 
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-teas-gmpls-lsp-
> fastreroute-09.txt
> Htmlized:   https://tools.ietf.org/html/draft-ietf-teas-gmpls-lsp-fastreroute-
> 09
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-gmpls-lsp-
> fastreroute-09
> 
> Thanks,
> Rakesh
> 
> 
> On 2017-05-14, 10:16 PM, "Mach Chen" <[e-mail]> wrote:
> 
>     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
>     >
>     >
>     >
> 
>