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

[Loa Andersson <[e-mail]>]

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]