Re: [bess] Signaling Control Word in EVPN

James Bensley <> Tue, 09 October 2018 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DE2F131314 for <>; Tue, 9 Oct 2018 05:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JdM4VS9t2v10 for <>; Tue, 9 Oct 2018 05:49:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17616131313 for <>; Tue, 9 Oct 2018 05:49:24 -0700 (PDT)
Received: by with SMTP id p34-v6so1112610lfg.10 for <>; Tue, 09 Oct 2018 05:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s/dJbwNxm+uzLlGDPGpqHkbBTOzSS69f+9Um6QbqdKI=; b=NaPg2Lxm2wdFJsoQqRVwqHDTlyN+R8M17RSNtZYhZnFXGfSpn4t0a0zZ7BNGZi2W0I 4g1uk5m0nsyqGcpxTfcNdGsr8EIr9vCruzfhQFt8UA9QcX/MtpznIaWFplxkoM4gIU2q QIPLqmmLS01c+289un0nEgfvQ2F2clGDPi94VLA6dMlf+OZvwAuZyT3QTqyH80ad/KoL xX/uVbfi7N9mT3RdHsN9FedfuuvSB3jf90exGj3gYaTGH0OZeIzP2IPa2sWAJAsud8Sb 834E2VgY1fYflU6NPUYlD6FPOETUW46UPrlR8BX1nVkp8+mR5AjGxe20cOyPhMad0XlR aSjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s/dJbwNxm+uzLlGDPGpqHkbBTOzSS69f+9Um6QbqdKI=; b=QAs7Rjwzj0dxMpaDtke4StdczS7HGhrCjTN9bC8ehP7o4l3goiwrGQjw8lU3h4YrpT x7qRVd0AJ+H6fNSLGa+O+Wzp/raBf4sZRvYPgeEa5JuPM+ZHivNodOb4W0VJqJ5op1bk /ev5T8ciYfV/Dnewh5ETO+nuVVgkv5oMHObOFRcB2ii/JlBB1NIcolGeAlTfXvJWHH8V cEgXy3mbG03rS9uKjezGvzU6fOnzw6JaNkqAlHc+Vs+xgBolTyziZWoFbZuKqPfvN03/ PGFb0m6W/jUEO+B5+WGzntkav1ZtZ86y2ZI0usHBRchNoDSMMAiEUeu2j0O0e/R7HRrx MB1g==
X-Gm-Message-State: ABuFfohlnKwVjCNa2ruycr8RKucJ0pxWt/92slsYpTA/Q21dNzmtqBey dRMEgsiG/D4pC2yAsKEi4DbqewCQT+rH+wySVPM=
X-Google-Smtp-Source: ACcGV63qfRWLOj2wnhuOJ44cvG2Km6juANmIkjnb5KmNudXI095SzdnbKHn9PWcdrS/29TZ6P6x0Cjd1SQUct2gTJdg=
X-Received: by 2002:a19:8f57:: with SMTP id r84-v6mr14819832lfd.131.1539089362086; Tue, 09 Oct 2018 05:49:22 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: James Bensley <>
Date: Tue, 09 Oct 2018 13:48:55 +0100
Message-ID: <>
To: Alexander Vainshtein <>
Cc: "Andrew G. Malis" <>,,,,,,,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Approved-At: Tue, 09 Oct 2018 07:17:13 -0700
Subject: Re: [bess] Signaling Control Word in EVPN
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Oct 2018 12:49:27 -0000

On Tue, 9 Oct 2018 at 11:29, Alexander Vainshtein
<> wrote:
> I fully agree that reordering due to lack of the CW happens, and that usage of the CW is the right way to eliminate that.

Hi Sasha,

If I may rudely interject here. You have to be careful with your
wording. The PWMCW doesn't eliminate reordering.

4.  Recommendation

   The ambiguity between an MPLS payload that is an Ethernet PW and one
   that is an IP packet is resolved when the Ethernet PW control word is
   used.  This document updates [RFC4448] to state that where both the
   ingress PE and the egress PE support the Ethernet pseudowire control
   word, then the CW MUST be used.

The CW doesn't fix the problem in every case, but it does fix it in most cases.

The only way to truly fix this problem is to use entropy labels. The
problem with the CW draft is that it only recommends entropy labels or
FAT labels when ECMP is required, not when it isn't require *but*
exists anyway within the packet switched core:

   Where the application of ECMP to an Ethernet PW traffic is required,
   and where both the ingress and the egress PEs support [RFC6790]
   (Entropy Label Indicator/Entropy Label (ELI/EL)) or both the ingress
   and the egress PEs support [RFC6391] (FAT PW), then either method may
   be used.

For this reason my personal opinion is that only EL should be
recommended by the EVPN draft. I don't think a solution that doesn't
completely fix the problem (PWMCW) should be recommend when we have
one that does fully fix the problem (El/ELI or ELC/RLD in SR).

> Or should we agree that consistent usage of the CW in the EVPN encapsulation has to be delegated to some network-wide management mechanism/LSO? For the reference, the latest (expired) version of the EVPN YANG data model does not include any attributes that indicate usage or non-usage of the CW in the encapsulation...

This is perhaps the more difficult question ^ what to recommend in the
case that EL isn't supported? You could recommend that all devices
should be configured to *not* hash on the VPN payload and only the
label stack, then there can be no mistaking what the VPN contents are
(Ethernet/IPv4/IPv6/other) but, some devices might not support that.
Alternatively, you could recommend that the CW is used only when EL
isn't available but, some devices might not support that. I'll leave
this up to you guys as you're the experts here, I just wanted to point
out the wording issue above regarding CW and EL and "fixing"