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

[Gregory Mirsky <[e-mail]>]

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