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

[Stewart Bryant <[e-mail]>]

Harish

Thank you for the review.


On 23/05/2018 21:09, Harish Sitaraman 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.
Unreliable inference when the T-PEs are sending Ethernet over PW and not 
using the optional  CW.
> 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.

There are two cases we had to deal with:

The main one where a PW without the CW was being deployed, in which case 
LSR's on the
path were doing five tuple based ECMP (and making mistakes).

The other case that came to light was LSRs that noting the presence of 
the PW
by noting that the first nibble after the label stack was zero, and then 
(sometimes)
falsely concluding that what followed the label stack was

CW, Ethernet Header, IP packet

and using the five tuple in the assumed IP packet to do ECMP, sometimes 
getting it wrong.

Thus the point of this section was to explain how to correctly do ECMP 
on a PW.

> 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?

An OAM packet does not have the five tuple, so cannot follow the same 
path as a
five tuple packet by definition. The situation is improved if one of the 
non-five tuple
methods are used and the same ECMP hints are included in both data and 
OAM packets
since LSRs would select the same next hop in both cases.

> 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?

This text was added as a result of a WG LC comment where a reviewer 
wanted clarification
of the ordering of these LSEs.

I am not sure why anyone would want to use both EL and FAT on the same 
packet.

FAT is always after the PW label and thus always BoS.

The question the arose where would the EL go if that was used instead. 
The agreement was
reached that since the EL was associated with the LSP, rather than the 
PW, and there where
there is no FAT label the PW label is always BoS, it made sense for the 
EL to be somewhere in
the LSP part of the label stack. However we also decided that it was 
none of our business
specifying where in the label stack it belonged, other than not at the 
bottom.

Hopefully that explanation addresses your concern.

I have not changed any of the text.

> Major Issues:
> No major issues found.
>
> Minor Issues:
> Section 2: RFC2119 has been updated by RFC8174.
I have taken the text from RFC 8341.
>
> Nits:
> Section 5: LSP entropy labels specified 'in' [RFC6790]
done
>
> 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.
I have made everything the same style as RFC8341 (the most recent RFC 
published)
>    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.
Done.

Thanks

Stewart
>
> --
> Harish
>