Subject: [Pals] RtgDir review: draft-ietf-pals-ethernet-cw-05.txt

From: Harish Sitaraman <[email-masked]>
Date: Wed, 23 May 2018 20:09:19 +0000

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 23 May 2018 16:28:02 -0400

Harish,

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

Cheers,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 25 May 2018 15:23:58 +0100

Harish

Thank you for the review.

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

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.

> could this paragraph be removed or should it also mention the flow label position

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.

> Section 2: RFC2119 has been updated by RFC8174.
I have taken the text from RFC 8341.
> Section 5: LSP entropy labels specified 'in' [RFC6790]
done
>                       Similarly for RFC6790 references.
I have made everything the same style as RFC8341 (the most recent RFC 
published)
>                          Might be better to expand ELI too.
Done.

Thanks

Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 27 May 2018 07:23:33 +0000

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: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

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

Harish

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

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

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

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.

done
Done.

Thanks

Stewart

___________________________________________________________________________

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.
___________________________________________________________________________