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

["Rakesh Gandhi (rgandhi)" <[e-mail]>]

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.
    
        
        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