Re: [Pals] Review of draft-ietf-pals-endpoint-fast-protection-04

[Yimin Shen <[e-mail]>]

Hi Dave,

Thanks very much for your review and valuable comments. Please see my answers inline.

Thanks,

-- Yimin


On Mon, Dec 5, 2016 at 7:30 PM, IETF Secretariat <[e-mail]<mailto:[e-mail]>> wrote:
Reviewer: David Black
Review result: Ready with Issues
-- TSV-ART review comments:

I found a couple of minor transport-related issues, both of which
should be resolvable with modest amounts of additional explanation:

* ECMP: The ECMP discussion in Section 4.1 on Applicability takes a
conservative approach to avoiding packet reordering by recommending
(SHOULD) that the entire ECMP set be rerouted as part of local repair.
 It's not clear what sort of ECMP is involved, as that acronym is used
without a reference (or even expansion), so I'd suggest citing a
reference.   If the ECMP used is flow-aware so that reordering across
ECMP branches within an ECMP set does not cause reordering within any
of the flows involved, then it ought to be safe from a reordering
perspective to reroute an ECMP branch or set of branches that are less
than the full ECMP set, although such partial rerouting could cause
potentially undesirable forwarding latency differences within the ECMP
set.  This ought to be discussed, as situations in which rerouting the
entire ECMP bundle is overly conservative seem likely to arise in
practice.

[yshen] We will spell out ECMP and clarify that the ECMP in this document is at transport tunnel level where each PW packet goes through a certain hashing mechanism and then gets forwarded over a particular branch of the ECMP set. The actual reason that all ECMP branches need to be rerouted together is because the egress router is Down, and this failure is going to impact on ALL branches without an exception. The above text only highlights one benefit of doing this -- in the case where the router treats a link failure as an egress node, this can also avoid “possible” packet reordering. Yes, as you mentioned, some PW flows may use FAT or entropy labels, but the router (i.e. PLR) doesn’t have the knowledge or visibility it. We will revise the text to improve the clarity.

* Traffic Engineering: Considering the intended speed of local repair,
"order of tens of milliseconds" in the abstract, the bandwidth used by
the repair paths has to be provisioned in advance of any failure that
causes repair path usage - traffic engineering is a likely means of
provisioning that bandwidth.  I see "TE domain," "TE metric" and "TE
path," which I assume refer to Traffic Engineering, but that TE
acronym is not expanded, and I did not find text requiring traffic
engineering and/or advance (bandwidth) provisioning of repair paths.
I assume that this advance bandwidth provisioning of repair paths is
intended as part of local repair, as not doing that invites immediate
repair path failure due to lack of forwarding resources, which is
definitely not desired.  A sentence or two ought to be added to point
this bandwidth provisioning requirement out, possibly in Section 4.1
(Applicability).  Adding that text would also reinforce the conclusion
in the Security Considerations section that local repair reroutes are
not a security threat, as the new text would add the rationale that
local repair reroutes are anticipated and planned for by the network
operator's traffic engineering.

[yshen] We will add text to clarify TE and bandwidth provisioning which may be necessary and feasible in some cases, e.g. RSVP.  Great comment on this reinforcing the security consideration!

--  Other comments:

* Having found two acronyms that were not expanded, I'd suggest a
general look for such acronyms.   OTOH, this is an area of network
technology where many acronyms are in common use, and hence expansion
of every acronym on first use may be excessive - among the ways of
avoiding this could be citation of a reference at the start of Section
3 where commonly used PW terms and acronyms are defined.

[yshen] We will scan the document to spell out all acronyms that are missed out.