Subject: [Teas] RtgDir review: draft-ietf-teas-gmpls-lsp-fastreroute-07.txt

From: Mach Chen <[email-masked]>
Date: Fri, 12 May 2017 08:33:49 +0000

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 12 May 2017 11:42:41 +0000

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" <[email-masked]> wrote:

    Hello,

    
    
    Summary: 
    
    Comments: 
    
    Major Issues: 
    No major issues found.
    
    Minor Issues: 
    
    1. Section 5.

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

<RG> Agree to update this.

    3.
    Section 8
    "As described in

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

Thanks,
Rakesh (for authors and contributors)

    Best regards,
    Mach

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 12 May 2017 21:46:54 +0000

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)" <[email-masked]> wrote:

    Hi Mach,

    
        Hello,

        
        
        Summary: 
        
        Comments: 
        
        Major Issues: 
        No major issues found.
        
        Minor Issues: 
        
        1. Section 5.

        2.

        3.
        Section 8
        "As described in

    
           As described in

        Nits: 
        Section 5.1.1.
        
    <RG> Agree.
    
    Thanks,

        Best regards,
        Mach

---

From: Mach Chen <[email-masked]>
Date: Mon, 15 May 2017 02:16:23 +0000

Hi Rahesh,

Thanks for considering my comments and the quick updates!

Please see my reply inline...

> -----Original Message-----
> From: Rakesh Gandhi (rgandhi) [mailto:[email-masked]]
> Sent: Saturday, May 13, 2017 5:47 AM
> To: Mach Chen <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: RtgDir review: draft-ietf-teas-gmpls-lsp-fastreroute-07.txt
> 
> Hi Mach, WG,
> 
>         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.
> 
>         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?
> 

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:

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 15 May 2017 12:26:49 +0000

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" <[email-masked]> wrote:

    Hi Rahesh,

    

    OLD:
    
    NEW:

    OLD:
    
    NEW:

    Best regards,
    Mach

---

From: Mach Chen <[email-masked]>
Date: Tue, 16 May 2017 01:17:49 +0000

Hi Rakesh,

Looks good me!

Best regards,
Mach

> Sent: Monday, May 15, 2017 8:27 PM
>     > https://datatracker.ietf.org/doc/html/draft-ietf-teas-gmpls-lsp-
> fastreroute-
>     > 08
>     >
>     >
>     > thanks,
>     > Rakesh
>     >
>     >
>     >     Many thanks for the detailed review of the document and your
> comments.
>     > Please see inline for replies with <RG>…
>     >
>     >
>     >         I have some minor concerns about this document that I think should
> be
>     > resolved before publication.
>     >
>     >         Comments:
>     >     <RG> Ok, we should remove the second bullet (copied below) to make
> it
>     > consistent for both cases.
>     >
>     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.
>     >         What's sub-code will be sent when BYPASS_ ASSIGNMENT subobject
> is
>     > carried in the RSVP message?
>     >

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Tue, 16 May 2017 01:20:45 +0000

Thank you Mach.

On 2017-05-15, 9:17 PM, "Mach Chen" <[email-masked]> wrote:

    Hi Rakesh,
    
    Looks good me!
    
    Best regards,
    Mach