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

[Alexander Vainshtein <[e-mail]>]

Stewart, Harish and all,
Just wanted to confirm that the situation when "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" indeed occurs in some modern off-the-shelf packet processors. The implications of this conclusions are disastrous for PW types that really care about reordering, especially TDM PWs.

The (AFAIK only) solution in these cases is disabling the ECMP mode that inspects the payload of labeled packets and using  what Stewart calls "non-five-tuple" methods instead.

My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

-----Original Message-----
From: rtg-dir [mailto:[e-mail]] On Behalf Of Stewart Bryant
Sent: Friday, May 25, 2018 5:24 PM
To: Harish Sitaraman <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-pals-ethernet-cw-05.txt

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
>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________