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

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

Thank you Loa for the review.

FYI: Have uploaded a new revision (01) to address the comments from Nobo.

Thanks again,
Rakesh



On 2014-12-24 11:50 PM, "Loa Andersson" <[e-mail]> wrote:

>Working Group,
>
>I was almost through my review of this document, saw Nobo's review
>and found that he had found everything I found and a bit more :).
>
>With that and with Rakesh's statement that the comments will be
>addressed I souppor the adoption of the document as a wg doc.
>
>/Loa
>
>On 2014-12-25 07:25, Rakesh Gandhi (rgandhi) wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>-- 
>
>
>Loa Andersson                        email: [e-mail]
>Senior MPLS Expert                          [e-mail]
>Huawei Technologies (consultant)     phone: [phone]