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

[Gregory Mirsky <[e-mail]>]

Hi Rakesh,
thank you for your interest in my comments.
I can note that during work on MPLS-TP we, as union of MPLS and CCAMP WGs, left question of RSVP FRR applicability undocumented. Perhaps we can find mailing list discussions where some of us agreed that local protection of uni-directional and bi-directional associated LSPs in MPLS-TP can follow RFC 4090 but question of local protection of bi-directional co-routed LSPs requires further discussion. And there already were references to use ASSOCIATION object to support segment protection if node protection desired. That would allow monitoring of both working and protecting paths and switchover coordination by using RFC 6378.
Of course, proposed mechanism is workable as control plane restoration mechanism but I'm not convinced that is what should be standardized as local protection mechanism.

	Regards,
		Greg

-----Original Message-----
From: Rakesh Gandhi (rgandhi) [mailto:[e-mail]] 
Sent: Tuesday, January 06, 2015 5:26 PM
To: Gregory Mirsky
Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon); Zafar Ali (zali); Manav Bhatia; [e-mail]
Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute

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