Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute

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

Thank you Nobo for your detailed review comments.

We will address these in the next revision.

Happy holidays.

Thanks,
Rakesh


From: "Nobo Akiya (nobo)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 24 December, 2014 5:45 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: TEAS WG <[e-mail]<mailto:[e-mail]>>
Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Lizhong com>" <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, "=SMTP:mtaillon@cisco. com" <[e-mail]<mailto:[e-mail]>>, Rakesh Gandhi <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Zafar Ali <[e-mail]<mailto:[e-mail]>>
Resent-Date: Wednesday, 24 December, 2014 5:46 PM


Hi Authors,



Happy Holidays!



I read draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-05 (as part of its WG adoption poll), and had some questions/comments. Please find them below.





1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may be easier to understand if “list” is used.



[OLD]

   The BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE object

   prior to adding the node's IP address in the node-ID subobject.  A

   node MUST NOT add a BYPASS_ASSIGNMENT subobject without also adding a

   Node-ID subobject.  A node MUST NOT add a BYPASS_ASSIGNMENT subobject

   without also adding an IPv4 or IPv6 subobject.



[NEW]

   When the BYPASS_ASSIGNMENT subobject is added in the RECORD_ROUTE

   object:



   o  The BYPASS_ASSIGNMENT subobject MUST be added prior to the node-ID

      subobject describing the node's IP address.



   o  The Node-ID subobject MUST also be added.



   o  The IPv4 or IPv6 subobject MUST also be added.





2) Section 4.4.1 - First sentence of the third paragraph was quite difficult to read/understand. Perhaps adding some commas and quotations may improve its readability.



[OLD]

   The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject whose bypass tunnel and the node-ID subobject when used as

   a bypass tunnel source terminates locally assigns the matching

   bidirectional bypass tunnel in the reverse direction, and forwards

   the RSVP Path message downstream.



[NEW]

   The upstream PLR (downstream MP) that detects a BYPASS_ASSIGNMENT

   subobject, whose bypass tunnel and the node-ID subobject when used as

   a "bypass tunnel source" terminates locally, assigns the matching

   bidirectional bypass tunnel in the reverse direction, and forwards

   the RSVP Path message downstream.





3) Section 4.4.1 - I have a slight concern regarding below statement.



[snip]

   In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does

   not assign a bypass tunnel in the reverse direction.  This allows the

   downstream PLR to always initiate the bypass assignment and upstream

   PLR to simply reflect the bypass assignment.



   In the case of upstream PLR receiving multiple BYPASS_ASSIGNMENT

   subobjects from multiple downstream PLRs, the decision of selecting a

   bypass tunnel in the reverse direction can be based on local policy,

   for example, prefer link protection versus node protection bypass

   tunnel, or prefer the most upstream versus least upstream node

   protection bypass tunnel.

[snip]



When LSRs within a bidirectional LSP employ different policies, as described above, then we can result in pockets where there are no protections.



For example:



Node A uses node protection.

Node B and C use link protection.



    +---------+

   /       +-+ \

  /       /   \ \

/       /     v v

A ----- B ----- C

         ^     /

          \   /

           +-+



The result of above is that, in the reverse direction, there will not be any protection between nodes B and A.



Another example:



Node A and C use node protection.

Node B use link protection.



    +---------+

   /       +-+ \

  /       /   \ \

/       /     v v

A ----- B ----- C

^              /

  \            /

   +----------+



The result of above is that, in the reverse direction, there will not be any protection between nodes B and A.



In both cases, if there is a breakage of the link connecting nodes A and B, then node C receives the RSVP PATH message. If node C follows procedures described in Section 6.2, then it will not find a matching bypass tunnel.



If I’m off track, then I apologize for the noise. If above is indeed a problem, then this limitation should at least be described in the document, followed by a recommendation of all LSRs within a bidirectional tunnel employing the same policy.



It may be possible to (be brave and) address this but it will require more procedures. I’ll leave the decision and further investigation to the authors.





4) Section 4.4.1 - Should there be SHOULD or MUST in this paragraph?



[snip]

   In the absence of BYPASS_ASSIGNMENT subobject, the upstream PLR does

   not assign a bypass tunnel in the reverse direction.  This allows the

   downstream PLR to always initiate the bypass assignment and upstream

   PLR to simply reflect the bypass assignment.

[snip]



I’m guessing that there should be a SHOULD …





5) Section 6.2 - “If” and “If not” in below text do not correspond to each other (thus a bit confusing).



[snip]

      - If found, checks whether the primary LSP traffic and signaling

        are already rerouted over the found bypass tunnel.  If not, PRR

        R5 activates FRR reroute procedures to direct traffic and

        RSVP Resv over the found bypass tunnel T2 in the

        reverse direction.

[snip]



If we write above with a psuedocode, then it will be:



    if (bypass tunnel found) {      // “If found” is this line

        check if already rerouted

        if (not already rerouted) { // “If not” is this line

             active FRR reroute

        }

    }



It  might make the texts easier to read/understand if you can rephrase it a bit?





Thanks!



-Nobo