Re: Review of draft-ietf-teas-gmpls-resource-sharing-proc-07

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

Thank you Dale for the thorough review of the document. Please see the attached diff file with the changes.

Please see inline for the replies <RG> ..

On 2017-01-23, 4:09 PM, "Dale Worley" <[e-mail]> wrote:

    Reviewer: Dale Worley
    Review result: Ready with Nits
    
    I am the assigned Gen-ART reviewer for this draft.  The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed by
    the IESG for the IETF Chair.  Please wait for direction from your
    document shepherd or AD before posting a new version of the draft.
    
    For more information, please see the FAQ at
    <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
    
    Document:  draft-ietf-teas-gmpls-resource-sharing-proc-07
    Reviewer:  Dale R. Worley
    Review Date:  23 Jan 2017
    IETF LC End Date:  17 Jan 2017
    IESG Telechat date:  2 Feb 2017
    
    Summary:
    
           This draft is basically ready for publication, but has nits
           that should be fixed before publication.
    
    There remain a few editorial items:
    
    2. Conventions Used in This Document	
    		
        The reader is assumed to be familiar with the terminology in	
        [RFC3209], [RFC3473], [RFC4872], [RFC4873] and [RFC4427].	
    		
    That is a significant help to the reader, but it's also rather
    intimidating!  Is there a way to point out that 4427 is specific to
    recovery?

<RG> Yes, added.    


    3.1.1.  1+R Restoration
    
       Unlike a protecting LSP which is set up before the failure, a
       restoration LSP is set up per need basis, after the failure.
    
    Probably better to change "per need basis" to "when needed".

<RG> Yes, edited.

    
    3.2. Resource Sharing By Restoration LSP	
    			
    "By" generally should not be capitalized in titles, as it is a
    preposition.

<RG> Edited.
    
                                   +-----+      +-----+
                                   |  F  +------+  G  +--------+
                                   +--+--+      +-----+        |
                                      |                        |
                                      |                        |
            +-----+    +-----+     +--+--+      +-----+     +--+--+
            |  A  +----+  B  +-----+  C  +--X---+  D  +-----+  E  |
            +-----+    +-----+     +-----+      +-----+     +-----+
    
              Figure 3: Resource Sharing in 1+R Recovery Scheme
    
    
       [...]  Nodes A and B
       reconfigure the resources to set up the restoration LSP by sending
       cross-connection command to the data plane.
    
       In the recovery scheme employing revertive behavior, after the
       failure is repaired, the resources on nodes A and B need to be
       reconfigured to set up the working LSP.  The traffic is then
    reverted
       back to the original working LSP.  
    
    It's not clear to me why nodes A and B are reconfigured and/or do the
    reconfiguring.  Any "global" reconfiguring would be driven by the
    head-end A alone, I think.  Any "local" reconfiguring would be done
    by
    C and possibly E.  Though perhaps there is reconfiguring that must be
    done along the entire path, but that would be attributed to A, B, C,
    F, G, and E together.  I suspect there is a trivial editorial error
    here...
    
<RG> Corrected the text. I made an error in the last update when addressing your comment.

Thanks,
Rakesh (for authors and contributors)



    [END]