Subject: [Pals] draft-ietf-pals-ethernet-cw and enhanced heuristics

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Oct 2017 12:07:42 +0100

The following has just been drawn to my attention:

https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html

The writer contacted the authors, but not the list, and stated that this 
heuristic results in similar behaviour to that which we are trying to 
address in this draft, but that the draft as written does not address 
this problem.

I have asked the writer to post to the PALS list or let me do it for them.

In such implementations, even requiring the CW does not address the 
issue that is being reported to us.

Looking at RFC4385 it says:

   If a PW is sensitive to packet misordering and is being carried over
    an MPLS PSN that uses the contents of the MPLS payload to select the
    ECMP path, it MUST employ a mechanism that prevents packet
    misordering.  A suitable mechanism is the PWMCW described in Section
    3 for data, and the PWACH described in Section 5 for channel-
    associated traffic.

PWMCW is a reference to the use of the CW  starting with 0000.

I think that the implication in RFC4385 is that implementations should 
not proceed past the CW. That was certainly my intention when I wrote 
the text in 2005. I must say that whilst I knew of implementations that 
tried to perform ECMP on IP payloads, I was not aware of implementations 
that would attempt to glean that the PW was Ethernet and that its 
payload was IP and then perform five-tuple ECMP on the Ethernet payload.

I am wondering if we need to address this, and if so how to proceed.

One way would be to add text quoting RFC4385 and noting the use of the 
control word only prevents incorrect ECMP in implementations that cease 
further packet analysis on encountering a CW. Implementations that do 
packet analysis beyond the CW should expect unpredictable results, and 
therefore as noted in RFC4385 MUST employ an alternate mechanism to 
prevent packet misordering.

We could leave it there or we could suggest that using RFC6391 or 
RFC6790 with no further heuristics is a safe way to achieve ECMP.

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 25 Oct 2017 12:50:22 -0400

Stewart,

I agree that this should be addressed, as the behavior as described in the
online documentation would prevent guaranteed in-order delivery, which is
what we are trying to address.

I also agree that we should include the quote from 4385 and your suggestion
in your second-to-last paragraph.

I also think that we should include the following, as you suggest in your
last paragraph: “RFC 6391 is RECOMMENDED as the safe and proper way to
achieve ECMP for Ethernet PWs if that indeed is desired." I don’t think we
need to also reference 6790, but that could be just me. :-)

Cheers,
Andy

On Wed, Oct 25, 2017 at 7:07 AM, Stewart Bryant <[email-masked]>
wrote:

> https://www.juniper.net/documentation/en_US/junos/topics/
> concept/mpls-encapsulated-payload-load-balancing-overview.html
>
> address in this draft, but that the draft as written does not address this
> problem.
>
> In such implementations, even requiring the CW does not address the issue
> that is being reported to us.
>
> I think that the implication in RFC4385 is that implementations should not
> proceed past the CW. That was certainly my intention when I wrote the text
> in 2005. I must say that whilst I knew of implementations that tried to
> perform ECMP on IP payloads, I was not aware of implementations that would
> attempt to glean that the PW was Ethernet and that its payload was IP and
> then perform five-tuple ECMP on the Ethernet payload.
>
> therefore as noted in RFC4385 MUST employ an alternate mechanism to prevent
> packet misordering.
>
> We could leave it there or we could suggest that using RFC6391 or RFC6790
> with no further heuristics is a safe way to achieve ECMP.
>
> - Stewart
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Oct 2017 19:08:39 +0100

RFC6790 ought to be another way to address the problem, but as we noted 
a while ago in the SFL work it stops short of mandating DPI type LB.

I think I therefore agree that we out to just use 6391, after all with 
that negotiated by both ends it would be rather silly to then do the DPI.

Not sure if I will get the text done by Monday, but this thread should 
give everyone a heads-up, I will put it on the slides for discussion and 
if I don't get the draft out I will put it in some other accessible place.

- Stewart

On 25/10/2017 17:50, Andrew G. Malis wrote:
> Stewart,
>
> I agree that this should be addressed, as the behavior as described in 
> the online documentation would prevent guaranteed in-order delivery, 
> which is what we are trying to address.
>
> I also agree that we should include the quote from 4385 and your 
> suggestion in your second-to-last paragraph.
>
> I also think that we should include the following, as you suggest in 
> your last paragraph: “RFC 6391 is RECOMMENDED as the safe and proper 
> way to achieve ECMP for Ethernet PWs if that indeed is desired." I 
> don’t think we need to also reference 6790, but that could be just me. :-)
>
> Cheers,
> Andy
>
>
> On Wed, Oct 25, 2017 at 7:07 AM, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     <https://www.juniper.net/documentation/en_US/junos/topics/concept/mpls-encapsulated-payload-load-balancing-overview.html>
>
>     The writer contacted the authors, but not the list, and stated
>     that this heuristic results in similar behaviour to that which we
>     are trying to address in this draft, but that the draft as written
>     does not address this problem.
>
>     In such implementations, even requiring the CW does not address
>     the issue that is being reported to us.
>
>     I think that the implication in RFC4385 is that implementations
>     should not proceed past the CW. That was certainly my intention
>     when I wrote the text in 2005. I must say that whilst I knew of
>     implementations that tried to perform ECMP on IP payloads, I was
>     not aware of implementations that would attempt to glean that the
>     PW was Ethernet and that its payload was IP and then perform
>     five-tuple ECMP on the Ethernet payload.
>
>     One way would be to add text quoting RFC4385 and noting the use of
>     the control word only prevents incorrect ECMP in implementations
>     that cease further packet analysis on encountering a CW.
>     Implementations that do packet analysis beyond the CW should
>     expect unpredictable results, and therefore as noted in RFC4385
>     MUST employ an alternate mechanism to prevent packet misordering.
>