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. 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-ethernet-cw-05.txt Reviewer: Harish Sitaraman Review Date: 23 May 2018 IETF LC End Date: 29 May 2018 Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: This document is well written. The context is specified: RAC has been issuing more Ethernet addresses starting with 0x4 or 0x6 and existing ECMP implementations may examine the first nibble after the MPLS label stack to determine whether the labeled packet is IP or not. This can cause unreliable inference of the payload type at transit routers that may have been inspecting the first nibble. For my understanding, it would be useful to know how section 5 relates (or offers more clarity) to the recommendation that CW MUST be used - the solutions in section 5 are known for better ECMP and applicable regardless of whether the packet has the CW. With the statement "However in both cases the situation is improved compared...based on the five tuple of the IP payload.", is the point that hashing would be "improved" (for some definition) since incorrect identification of payload is corrected but yet we cannot precisely steer the OAM packet along the specific ECMP path that the data packet may have taken? What is the intent behind the final paragraph in section 5 considering it mentions the existing stacking order of labels between PW, LSP and EL/ELI - could this paragraph be removed or should it also mention the flow label position from Fat PW? Major Issues: No major issues found. Minor Issues: Section 2: RFC2119 has been updated by RFC8174. Nits: Section 5: LSP entropy labels specified 'in' [RFC6790] Check if style consistency for references might be useful: Section 4: RFC6391 [RFC6391] vs. [RFC6391] vs. RFC6391 - all are used in the document. Similarly for RFC6790 references. Section 4/5: EL - expanded first in section 5, 3rd para "entropy label (EL)" but used earliest in section 4. Might be better to expand ELI too. -- Harish