Re: [Pals] RtgDir review: draft-ietf-pals-endpoint-fast-protection-00

["Andrew G. Malis" <[e-mail]>]

Mach,

Many thanks for the review!

Authors,

Please include this with other received WG last call comments, to be
addressed at the conclusion of WG LC.

Thanks,
Andy


On Fri, Aug 21, 2015 at 4:16 AM, Mach Chen <[e-mail]> wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
> Document: draft-ietf-pals-endpoint-fast-protection-00.txt
>
> Reviewer: Mach Chen
> Review Date: 20, August
> IETF LC End Date:
> Intended Status: Standards Track
>
> Summary:
> This draft defines a fast mechanism for protecting pseudowires against
> egress attachment circuit failure, egress PE failure, multi-segment PW
> terminating PE failure, and multi-segment PW switching PE failure. The
> solution works but based on a lot of assumptions that are not explicitly
> and detailed discussed in the document. Which include PLR determination,
> context identifier advertisement, PSN tunnel protocols extensions, etc. I
> personally feel that the solution proposed in the document is a bit
> complicated, it's arguable whether the use case and requirement deserve
> such complicated solution, given that there are already many protections
> mechanisms existed.
>
> Comments:
> Overall, I think the draft should at least resolve the following comments
> and questions before moving forward.
>
> Major Issues:
> Several places in the document state "it's outside the scope of this
> document", but they are critical to the solution and for interoperability
> IMHO, which should be detailed described in this document or in another
> parallel document (as a reference).
>
> Minor Issues:
>
> 1.
> Idnits tool shows that a lot of nits need to be fixed.
>
> 2.
> Abstract
>
> "This document specifies a fast mechanism for protecting pseudowires
>    against egress endpoint failures,..."
>
> Since S-PE and egress AC are also included, seems the "egress endpoint
> failures" may not be the right description.
>
> 3.
> Introduction:
> "In each direction between the PEs, PW packets are transported by a PSN
> tunnel, which is also called a transport tunnel."
>
> The "PSN tunnel" is a well-known and common used term for PW, seems no
> need to introduce a new term (transport tunnel) here.
>
> 4.
> Section 1, the last sentence of 4th paragraph, similar to comment 2:
>
> s/following egress endpoint failures/ following failures
>
> 5.
> Section 4.1
>
> s/If transport tunnels are LDP/ If transport tunnels are LDP based tunnels
>
> 6.
> Section 4.1:
> "The mechanism is also assumed to be used in conjunction with global
>    repair and control plane repair, in such a manner that the mechanism
>    temporarily repairs traffic by using a bypass tunnel, and global
>    repair and control plane repair eventually move traffic to a fully
>    functional path."
>
> Did you consider the situation where protections are also employed for the
> PSN tunnel?  E.g., the PSN tunnel is protected by some FRR mechanisms (this
> should be very typical), when there is failure between the PLR and the
> primary PE, which protection will take priority?
>
>
> 7.
> Section 4.2:
> "
> A PLR can realize its role based on configuration or the signaling of
>    transport tunnel.  For example, in the case where the transport
>    tunnel is signaled by RSVP, the penultimate hop router can realize
>    that it is the PLR for egress (T-)PE or S-PE failure based on the RRO
>    in Resv message, which should indicate that the router is one hop
>    away from the PE.  The detail of how this could be achieved on a per-
>    protocol basis is out of the scope of this document."
>
> PLR determination should be critical for this "endpoint protection"
> mechanism, I am not sure it is legitimately to state that it is out of
> scope here. Too many situations need to be considered here. E.g., How does
> an LSR know it should enable the PLR function? Is the "PLR" functions
> enabled by default or by some other means? Since a potential "PLR" (P
> router) has no information of the PW, it should not know which PSN tunnel a
> PW will bind to, how can a PLR realize its role for a PW? And when ECMP is
> employed, when topology is changed with time, PLR determination should more
> difficult (especially for LDP based tunnel), no matter through static
> configuration or some form of signaling. It needs more
> clarification/discussion here. And presumably, some extensions to the PSN
> tunnel protocols may need IMHO.
>
> 8.
> Section 4.3.2:
>
> This section talks how to advertise context identifier, but it just gives
> a high level introduction and states the detail is outside of scope.
> Separate the advertisement to another document is fine, but there should be
> valid reference. Because there are many thing that related to this context
> identifier. For example, how an ingress PE know a PW should be bound to a
> tunnel with destination of the context identifier rather than the address
> of the primary PE? And how does a PLR know that an IP address is the
> context identifier and then setup a bypass tunnel to it? How to make sure
> that the ingress PE will setup or resolve a tunnel to the primary PE rather
> than the protector? (considering the topologies and metrics of other links
> may change at any time)
>
> 9.
> Section 4.6
>
> How does a PLR know whether a MPLS or IP tunnel should be established?
>
>
> 10. Section 6.3 PW Label Distribution from Backup PE to Protector
>
> " ...This Protection FEC Element
>    MUST be identical to the Protection FEC Element TLV that the primary
>    PE advertises to the protector (Section 6.2).  The context identifier
>    SHOULD NOT be encoded in Interface_ID TLV in this message."
>
> How does the backup PE know the Protection FEC information of the primary
> PW? Configured on the backup PE? Why not just the context identifier to
> correlate the protected PWs?
>
>
> Best regards,
> Mach
>
>
>
>