[RTG-DIR] RtgDir review: draft-ietf-pals-ethernet-cw-05.txt

[Harish Sitaraman <[e-mail]>]

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