Subject: Re: [CCAMP] Comments to draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-00

From: Gregory Mirsky <[email-masked]>
Date: Sat, 2 Mar 2013 01:26:05 +0000

Dear Authors, et al.,
Please kindly consider my comments and questions to the draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-00 document:
*       The title suggests extension to both methods of local protection described in RFC 4090 even though only use of bypass tunnels analyzed. Any plans to extend one-to-one backup method for local protection of bi-directional co-routed LSPs?
   *    In the Introduction stated
   "In case of mismatch and after FRR, data traffic and signaling may flow over asymmetric paths in the forward and reverse directions which may be undesirable for certain applications."
   I'll point that in GMPLS model such path mismatch between signaling and data planes is normal and should be expected. Unless only MPLS-TE networks being addressed in the document.
*       Reference network in section 3 uses unidirectional protection LSPs to protect bi-directional co-routed LSP.
*       Firstly, how these protection LSPs were signaled given that bi-directional LSP signaled according to GMPLS model?
      * Secondly, I believe that bi-directional co-routed LSP must be protected by bi-directional co-routed LSPs. Thus use of uni-directional protection LSPs is not satisfactory solution. Instead, bi-directional co-routed LSP should be used to enable local protection for bi-directional co-routed LSP.
      * Thirdly, neither RFC 4090, nor RFC 3473 do not specify how upstream PLR signals bypass LSP.
*       In section 3.2 assumed that because of data link between R3 and R4 failure R3 and R4 lost connectivity in signaling plane. Though it is the case in MPLS-TE but not in GMPLS.
   *    I think that proposed in section 3.3 solution is not protection mechanism but recovery mechanism as it requires RSVP signaling before traffic can be switched at R5.
   *    And I think that for the reference network presented in Fig.1 procedure described in sections 3.2 and 3.3 might lead to creation of two bidirectional protection bypass tunnels R2-R4 and R3-R5. Here's how that might happen:
*       R3 and R4 independently detect link R3-R4 failure and switch data and RSVP traffic to T2 and T1 respectively
      * R5 and R2, according to section 3.3, will promote themselves to PRR role and might succeed in establishing LSP to R3 and R2 respectively. As result, unnecessary resources might be used and traffic flow is not co-routed (R1-R2-R4-R5-R6 in forward direction, R6-R5-R3-R2-R1 - in reverse).
*       In third bullet of section 3.3 suggested to use RRO to ensure co-routed bypass tunnel.
   *    When "Local protection available" flag can be set by downstream PLR of bi-directional co-routed LSR?
   *    When "Local protection in use" flag can be set to indicate that local repair mechanism is in use protecting both directions of failed bi-directional co-routed LSP?

        Regards,
                Greg

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 6 Mar 2013 01:43:05 +0000

Hi Gregory:

Many thanks for your detailed review. Please see response in-line.

Thanks

Regards … Zafar and co-authors.

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 1, 2013 8:26 PM
To: "Mike Taillon (mtaillon)" <[email-masked]<mailto:[email-masked]>>, "Tarek Saad (tsaad)" <[email-masked]<mailto:[email-masked]>>, "Rakesh Gandhi (rgandhi)" <[email-masked]<mailto:[email-masked]>>, zali <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Comments to draft-tsaad-ccamp-rsvpte-bidir-lsp-fastreroute-00

Dear Authors, et al.,

Yes, in a future revision.

Actually the "main" point of the quoted text was to point that "data traffic" may follow a different route in the forward and reverse directions. Just to reiterate the context from this para is: "the upstream and downstream PLRs may independently assign different bidirectional bypass tunnels in the forward and reverse direction?"

Backup tunnels could be signaled using classic MPLS (RFC3209) and can be uni-dir. Please note that, the draft addresses both uni-directional as well as bi-dir backup  tunnels.

What you are implying is: "protection path(s) for bi-directional co-routed LSP must be bi-directional and co-routed as well". This is very restrictive. Service Providers should be able to share backups between GMPLS (co-routed) PSC bi-directional as well as MPLS Unidir tunnels. As mentioned above, the draft addresses both uni-directional as well as bi-dir backup  tunnels.

Scope of the draft is packet switch capable PSC networks. I.E., in-band signaling is assumed (as mentioned in the document).

No, FRR is already triggered upon a link failure (within O(50 msec)). Procedure in section 3.3 is a control plane based corrective mechanism if after FRR activation the protected tunnel is no longer co-routed (hence section 3.3 is titled as Behavior Post Link Failure To Re-coroute).

No, only R5 assumes the role of PRR. We can add explicit text for tie break rule between R2 and R5.

PLR of bi-directional co-routed LSP uses same rules as in rfc4090 for these purposes.

        Regards,
                Greg