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

James Bensley <jwbensley@gmail.com> Mon, 29 October 2018 13:34 UTC

Return-Path: <jwbensley@gmail.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0833130F23; Mon, 29 Oct 2018 06:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cX2WuhC54XX; Mon, 29 Oct 2018 06:34:22 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F498130F1E; Mon, 29 Oct 2018 06:34:22 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id t22-v6so7789307lji.7; Mon, 29 Oct 2018 06:34:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=4hL8pwD6M599bavXmMrVm/y/CbQAfBVlAl2ERif0tZ8=; b=YWplwI+kBTYWLJ+D+ZHYQI+O/Y4a65Mfhg6zbZKFqmUPcbsUs6hSPrIJajM2CWOzp5 QJRcSpVdqokvV+Wl+sifZ5V5NxUNeNUeB1QkzdBGETnFOKmj7vyx5m0yqJmIYArXcCvz bl3IeFqlGiEns1k6zhf380H6T5Y5G2jgvxkl1X8mnCkYLDNUKflghLAR49rTYe4OKH53 RuHpux6KCWds+FG1u7Pmji3ZdTpiJZnRN/7y3rgF5CN5+2Aqebb3wlhpudOQPjAWV6P9 8lZNDJRKv7IMxbakqH9z6Rz/AzBHPEyXQDuMQnjXRxPEznNKgQvUtIAIb+q2xhNvRbsw deHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=4hL8pwD6M599bavXmMrVm/y/CbQAfBVlAl2ERif0tZ8=; b=j7bfadiBpBHAyO4mcUDMKadn1iOnlhETGA3Z/mxGu6Jyc9U+Bl5v5GliTbbu8zO/K0 T9fj5xC79uaInAWivccawSAoQOih7NvH1LBw1PIYbxg0XCLdq6lHBeAEQ/5Ns46d7+i6 R2L1vWzYfnua3FgKJz4fDbGtKso1ur0viO5vQ7qCNWDZ0tvs11NiphdQbRsB1O5y5Wai R4ir2GE6cVLB+rleQjvTsjaWQs94vi2a4S3cTl5j4i8L1SGjf0cxGIHL/2MtIP9p5r6X j24rkMEukEHIM4IE0phviix8aTfpT4mc8KsPTJzXxKm/q2AFu0RTjI8U9068lj+1yiT3 C7fQ==
X-Gm-Message-State: AGRZ1gKmFLvxQZs+D8RNoeIINoql0G8ufW8QuB/Zh3t85f7yZb1NjIg2 HWWQrwV00p/QoZYXAdXQFaEJUchaIA0GoInFQPO/ACAV6Ng=
X-Google-Smtp-Source: AJdET5dZjtQvWUUZI2h/m6ZwaJJQNk7CFtfrZDuX4Wp/1SdNcTMtTaUsAkye6rkf0mufXDLd3eOkXDoB1DiBpkqRvmY=
X-Received: by 2002:a2e:4299:: with SMTP id h25-v6mr8040508ljf.5.1540820059501; Mon, 29 Oct 2018 06:34:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAKz0y8yFQdX5w_38rpyvd_sTJsTLxNEXYxxD=ttBzJi=VKxhjg@mail.gmail.com> <DB5PR0301MB1909F64D86F4B720BFCCE9679DE50@DB5PR0301MB1909.eurprd03.prod.outlook.com> <DB5PR0301MB190988CFD00F53B3BDB95B859DE60@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CAA=duU0uBTUSVt3=B5koGmV=hbt0tjVef9uzRRvgqGpQudkwTg@mail.gmail.com> <DB5PR0301MB19096B84734126EA9452D5F69DE70@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CAAWx_pU3SBvJtcpQRmHyRaS8WHbFmEjRhd3KC4NsghAHV7Qz9Q@mail.gmail.com> <CAA=duU12cYHTeYgaMXr9U2jUwaYayuWrBgH+5SHb=NQqk4=TCQ@mail.gmail.com> <35FF0D51C8DAB54B95B0426331F984FF52065486@lhreml523-mbx.china.huawei.com> <DB5PR0301MB1909F2EA0C73A89DF50DC1DC9DE00@DB5PR0301MB1909.eurprd03.prod.outlook.com> <CAAWx_pUB6e6nGb=57eGSSSmwovnO15on8YFG9K7RREeaU_zUnA@mail.gmail.com> <DB5PR0301MB1909133544D1A86F8C67D56D9DF50@DB5PR0301MB1909.eurprd03.prod.outlook.com>
In-Reply-To: <DB5PR0301MB1909133544D1A86F8C67D56D9DF50@DB5PR0301MB1909.eurprd03.prod.outlook.com>
From: James Bensley <jwbensley@gmail.com>
Date: Mon, 29 Oct 2018 13:33:52 +0000
Message-ID: <CAAWx_pXd+YXB4W27kh+Bm0GHi0sU-XfHOFuWVFBH2GZPtAzxUA@mail.gmail.com>
To: bess@ietf.org, pals@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/9dqHD1zDY4W9KvL-ReezB8p1sbY>
Subject: Re: [Pals] [bess] CW in EVPN: Was Signaling Control Word in EVPN
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2018 13:34:24 -0000

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

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?

Cheers,
James.