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

From: Gregory Mirsky <[email-masked]>
Date: Sat, 2 Mar 2013 01:25:01 +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?