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

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

Hi Gregory,

Thank you for your review comments.

Can u please elaborate how does segment protection using ASSOCIATION
object solve the highlighted issue ?  I am thinking such mechanisms would
apply to FRR as well.

Thanks,
Rakesh


On 2014-12-25 2:51 AM, "Gregory Mirsky" <[e-mail]>
wrote:

>Dear All,
>I think that node protection mode for bidirectional co-routed LSP FRR is
>cumbersome and, at best, likely cause out-of-order delivery and more
>service disruption (switching reverse direction on R5 from R4 onto R3
>triggered by tunneled RSVP Path message). I believe that extension of RFC
>4090 for bidirectional co-routed LSP FRR is viable only for link
>protection mode and node protection must be referred to segment
>protection and use of RSVP ASSOCIATION object (RFC 4872 and RFC 6689).
>Without such change in the scope of the draft I cannot support its
>adoption by the WG.
>
>	Regards,
>		Greg
>
>-----Original Message-----
>From: Teas [mailto:[e-mail]] On Behalf Of Loa Andersson
>Sent: Wednesday, December 24, 2014 8:50 PM
>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo);
>[e-mail]
>Cc: TEAS WG
>Subject: Re: [Teas] Mail regarding
>draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>
>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]
>
>_______________________________________________
>Teas mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/teas