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

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 24 Dec 2014 22:45:54 +0000

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

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 24 Dec 2014 23:25:56 +0000

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!

1) Section 4.4.1 - The rules for the BYPASS_ASSIGNMENT subobject may be easier to understand if “list” is used.

[OLD]

[NEW]

   object:

[OLD]

[NEW]

[snip]

[snip]

For example:

    +---------+

   /       +-+ \

  /       /   \ \

/       /     v v

A ----- B ----- C

         ^     /

          \   /

           +-+

Another example:

    +---------+

   /       +-+ \

  /       /   \ \

/       /     v v

A ----- B ----- C

^              /

  \            /

   +----------+

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.

[snip]

[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]

        reverse direction.

[snip]

    if (bypass tunnel found) {      // “If found” is this line

        if (not already rerouted) { // “If not” is this line

             active FRR reroute

        }

    }

Thanks!

-Nobo

---

From: Loa Andersson <[email-masked]>
Date: Thu, 25 Dec 2014 12:50:19 +0800

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:
> From: "Nobo Akiya (nobo)" <[email-masked] <mailto:[email-masked]>>
> To: "[email-masked]
> <mailto:[email-masked]>"
> <[email-masked]
> <mailto:[email-masked]>>
> Cc: TEAS WG <[email-masked] <mailto:[email-masked]>>
> 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]>>
> 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.
>
> 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]
>
> 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:
>
> 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.
>
> _______________________________________________
> 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

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 25 Dec 2014 07:51:37 +0000

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:
> <mailto:[email-masked]>
> >
> <mailto:[email-masked]>>, "Lizhong com>" 
> <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>, "=SMTP:mtaillon@cisco. com"
> 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]
>
> difficult to read/understand. Perhaps adding some commas and 
> quotations may improve its readability.
>
> [OLD]
>
> 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 
> If I'm off track, then I apologize for the noise. If above is indeed a 
> more procedures. I'll leave the decision and further investigation to 
> the authors.
>

--