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

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

Harish,

Thanks, your review is greatly appreciated! Stewart, Ignas, and I will
discuss your comments and get back to you.

Cheers,
Andy


On Wed, May 23, 2018 at 4:09 PM, Harish Sitaraman <[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. 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
>
>