Re: [Pals] [bess] CW in EVPN: Was Signaling Control Word in EVPN

Hi,
Some comments below.
Regards,
Tim
-----Original Message-----
From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of James Bensley
Sent: 29 October 2018 13:34
To: bess@ietf.org; pals@ietf.org
Subject: Re: [bess] CW in EVPN: Was Signaling Control Word in EVPN

On Tue, 23 Oct 2018 at 09:28, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:
>
> James,
>
> I am adding PALS WG to the list of addressees because, AFAIK, the PW CW is defined in this WG.
>
>
>
> I think that the really observed problem with incorrect ECMP behavior exists, but it is different from your description in your earlier email:
>
>
>
> Any LSR on the path between ingress and egress LER is free to look beyond the MPLS label stack and misinterpret the 0x00 0x00 at the start of a control-word as a valid MAC that starts 00:00:XX:XX:XX:XX and try to hash on Ethernet headers starting directly after the MPLS label stack.
>
>
>
> I have not seen (or heard about) such behavior in any deployed networks.
>
[Tim]: This behavior exists on some devices, but they should at least ignore 0x0 MAC.
>
> However, I am aware of some modern forwarding chipsets that (correctly) treat the ‘0000’ in the first nibble of the payload of a labeled packet (i.e., immediately following the bottom of the label stack) as the indication of a 32-bit PW control word but (incorrectly), consider this as a CW of an Ethernet PW (as if no other PWs exist!) and try to hash on the presumed MAC addresses, Ethertype etc.  Such behavior is really deadly for, say TDM PWs that, AFAIK, are still widely deployed in many places.
[Tim]: Yes, this does exist, at least ever :), but this is a behavior not compliance with RFC and should be corrected. Chipset with such capabilities is usually programmable and should have the capability to fix the limit, otherwise will be a disaster for pretending to be intelligent. 
>

Hi Sasha,

Well in either case we have both provided different examples of when the PWMCW doesn't prevent reordering when ECMP is present in the PSN.
Perhaps I need to actually step back a bit here and ask a different question, to further understand the non-technical problem first.

What is the scope/remit of the WG in this scenario? To be clear on what I mean by this, the PWMCW is a flawed method for preventing reordering when ECMP is present (see our two examples above). It also doesn't add any entropy to improve ECMP when ECMP is required. Entropy labels help to prevent reordering and help to add entropy, despite these technical benefits but they may have other non-technical disadvantages. So what is the WGs remit with recommending one technology over another?

In this specific case, is it:

Option 1. The WG's remit is to phase out or discourage flawed technologies if a superior one exists, so it should look to deprecate CWs because ELs are superior from a purely technical view?
Option 2. The WG's remit is to support as many technologies as possible, so it shouldn't look to deprecate CWs because ELs may have other non-technical draw backs?
Option 3. The WG's remit is to remain neutral on the subject of CWs vs other methods, and simply ensure that all drafts follow the correct due diligence process regardless of whether one technology is technically "better" than another?
Option 4. The WG's remit is something else?

[Tim]: My opinion is: 
Control word is proven technology for years and has been deployed a lot. I cannot find a reason we should abandon it. ELs can be better but it is also difficult to achieve.
Many of the chipsets nowadays are still not capable to implement ELs. I believe both techniques will exit for a long period of time.

Cheers,
James.

_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess