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

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 7 Jan 2015 01:25:45 +0000

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" <[email-masked]>
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:[email-masked]] On Behalf Of Loa Andersson
>Sent: Wednesday, December 24, 2014 8:50 PM
>To: Rakesh Gandhi (rgandhi); Nobo Akiya (nobo);
>[email-masked]
>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)" <[email-masked] <mailto:[email-masked]>>
>> Date: Wednesday, 24 December, 2014 5:45 PM
>> To: "[email-masked]
>> <mailto:[email-masked]>"
>> <[email-masked]
>> <mailto:[email-masked]>
>> >
>> Cc: TEAS WG <[email-masked] <mailto:[email-masked]>>
>> Subject: Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute
>> Resent-From: <[email-masked]
>> <mailto:[email-masked]>>
>> Resent-To: "[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>, "Lizhong com>"
>> <[email-masked] <mailto:[email-masked]>>,
>> <[email-masked] <mailto:[email-masked]>>,
>>"=SMTP:mtaillon@cisco. com"
>> <[email-masked] <mailto:[email-masked]>>, Rakesh Gandhi
>> <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>> <mailto:[email-masked]>>, Zafar Ali <[email-masked]
>> <mailto:[email-masked]>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/teas
>>
>
>-- 
>
>
>Loa Andersson                        email: [email-masked]
>Senior MPLS Expert                          [email-masked]
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>
>_______________________________________________
>Teas mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/teas

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 7 Jan 2015 02:18:43 +0000

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:[email-masked]] 
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; [email-masked]
Subject: Re: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute

Hi Gregory,

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" <[email-masked]>
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 
>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
>
>> <mailto:[email-masked]
>> >
>> >
>> Subject: Mail regarding 
>>     subobject, whose bypass tunnel and the node-ID subobject when 
>> used as
>>
>> 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 
>> It  might make the texts easier to read/understand if you can 
>> rephrase it a bit?
>>
>> Thanks!
>>
>> -Nobo
>>
>>
>>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 7 Jan 2015 02:45:20 +0000

Hi Gregory,

Thank you for the context. Good stuff.

May be we could state in the draft something along the line of:
"PSC (RFC6378) is applicable to FRR (RFC4090) for local protection
switchover in both directions in order to minimize traffic disruptions. In
the absence of such mechanism, control plane restoration proposed is
required in order to avoid soft state time out".

Would that work?

thanks,
Rakesh

On 2015-01-06 9:18 PM, "Gregory Mirsky" <[email-masked]>
wrote:

>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
>
>Cc: TEAS WG; Tarek Saad (tsaad); Lizhong com>; Mike Taillon (mtaillon);
>Zafar Ali (zali); Manav Bhatia; [email-masked]

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 9 Jan 2015 21:47:21 +0000

Hi Rakesh,
apologies for the delay.
In place of "protection switchover in both directions" perhaps "protection of bi-directional co-routed LSPs" may be used.
And couple other questions:
*       section Behavior Post Link Failure To Re-coroute describes actions at R5 as
      finds ...
      if (found) ...
         ...
      But there's no discussion of what happens if "the bypass tunnel in the reverse direction that terminates on the Downstream PLR R3" cannot be found. Would such tunnel be signaled then?
*       revertive actions are not discussed in the document. I think they should be discussed as support of revertive and non-revertive behaviors is required for MPLS-TP networks.

        Regards,
                Greg

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

Hi Gregory,

May be we could state in the draft something along the line of:
"PSC (RFC6378) is applicable to FRR (RFC4090) for local protection switchover in both directions in order to minimize traffic disruptions. In the absence of such mechanism, control plane restoration proposed is required in order to avoid soft state time out".

Would that work?

thanks,
Rakesh

On 2015-01-06 9:18 PM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>>
wrote:

>WGs, left question of RSVP FRR applicability undocumented. Perhaps we
>can find mailing list discussions where some of us agreed that local
>Zafar Ali (zali); Manav Bhatia; [email-masked]<mailto:[email-masked]>
>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" <[email-masked]<mailto:[email-masked]>>
>wrote:
>
>>Dear All,
>>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
>>[email-masked]<mailto:[email-masked]>
>>Cc: TEAS WG
>>> From: "Nobo Akiya (nobo)" <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>
>>> Cc: TEAS WG <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>
>>> Subject: Mail regarding
>>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>,
>>><[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>,
>>> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>, Rakesh Gandhi
>>><[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>, <[email-masked]
>>>     subobject whose bypass tunnel and the node-ID subobject when
>>> used as
>>>
>>>     not assign a bypass tunnel in the reverse direction.  This
>>> allows the
>>>
>>> The result of above is that, in the reverse direction, there will
>>> not be any protection between nodes B and A.
>>>
>>> Another example:
>>>
>>> The result of above is that, in the reverse direction, there will
>>> not be any protection between nodes B and A.
>>>
>>> procedures described in Section 6.2, then it will not find a
>>> matching bypass tunnel.
>>>
>>> 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.
>>>
>>>     not assign a bypass tunnel in the reverse direction.  This
>>> allows the
>>>
>>> 5) Section 6.2 - "If" and "If not" in below text do not correspond
>>> to each other (thus a bit confusing).
>>>
>>> [snip]
>>>
>>> [email-masked]<mailto:[email-masked]>
>>Loa Andersson                        email: [email-masked]<mailto:[email-masked]>
>>Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
>>[email-masked]<mailto:[email-masked]>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Jan 2015 22:01:27 +0000

Hi Gregory,

Please see inline .. <RG>..

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, 9 January, 2015 4:47 PM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG <[email-masked]<mailto:[email-masked]>>, "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, "Lizhong com>" <[email-masked]<mailto:[email-masked]>>, "=SMTP:mtaillon@cisco. com" <[email-masked]<mailto:[email-masked]>>, Zafar Ali <[email-masked]<mailto:[email-masked]>>, Manav Bhatia <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Mail regarding draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute

Hi Rakesh,
apologies for the delay.

<RG> Ack.

finds …
if (found) …
   …

<RG> Yes, in such a case, downstream MP can assign a reverse bypass tunnel and if does not exist, can create it. We can add this in the draft.

<RG> Ok, we will discuss among authors and propose it in the draft.

thanks,
Rakesh

        Regards,
                Greg

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

Hi Gregory,

Would that work?

thanks,
Rakesh

On 2015-01-06 9:18 PM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>>
wrote:

>>> To: "[email-masked]<mailto:[email-masked]>
>>> <[email-masked]<mailto:[email-masked]>
>>> Resent-From: <[email-masked]<mailto:[email-masked]>
>>> Resent-To: "[email-masked]<mailto:[email-masked]>
>>><mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
>>><[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20<mailto:[email-masked]>>>, <[email-masked]<mailto:[email-masked]>
>>><mailto:[email-masked]>>, Zafar Ali <[email-masked]<mailto:[email-masked]>
>>><mailto:[email-masked]>>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sun, 25 Jan 2015 17:50:48 +0000

Thank you Gregory for your detailed review comments.

Please see inline. <RG>..

Hi Rakesh,
apologies for the delay.

<RG> Added text in the new revision –01.

finds …
if (found) …
   …

<RG> Yes, added text in the new revision –01.

<RG> Ack, to be added in the next update.

thanks  again,
Rakesh

        Regards,
                Greg

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

Hi Gregory,

Would that work?

thanks,
Rakesh