Re: [bess] Signaling Control Word in EVPN

"Andrew G. Malis" <> Tue, 09 October 2018 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77FE2130EE9 for <>; Tue, 9 Oct 2018 07:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=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 9Hd5yf0sm1ht for <>; Tue, 9 Oct 2018 07:16:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F333130FCF for <>; Tue, 9 Oct 2018 07:16:18 -0700 (PDT)
Received: by with SMTP id e22-v6so1745853qto.6 for <>; Tue, 09 Oct 2018 07:16:18 -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; bh=Aa6BHSh1I9TNprHTLnnEg8V1WPTCJLIoqxNe+9oPBco=; b=OVyg8rejx2Kg04z4+aDkWMnBEyIHMiJZPuWSa+JyNUnMJZoiPSjwaklxfI1McTvM5J lol3NqpN8XEcrIzKELOFRn0dVH4mhkc5gv4jAT++2k3I1U8ipIev6yFns730wm1iNH51 LLha0leSro38+a7WociC8Ah1rT/9BsN10JV9Iirdu02l4stppaO0ZdvV+e9MpzWFWxlY sDVeF1LVr4S9hsQ26IBXVzjCB4lFi3b8nSO/gCYwVrMqJESYjpPTTbD4EqOTNnmFT+16 XN9IV41w9TVw0Cec/UaSt3560+T8GLwwF5EJpuH0VuM7RqmQStTpRmBVrWoqonbmtrlq EDZQ==
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; bh=Aa6BHSh1I9TNprHTLnnEg8V1WPTCJLIoqxNe+9oPBco=; b=M6fD61rBmaH6v+Bjpuu6YLahW6iFUPrsv7+EnFqUiguqzhaVi51E6FmHkTKHucHDZM Jiobzl0Jviy5nXeH8OP2iHHPHB2jiYbCND3DFz/jBjVg4tdTFbIzdQZX+laEMS0UKxZW DGANB7Z67BAJ8v3wzoMlYZoF7136kIrLXElEB8huOIaX02lUsSf68TsA4CJ5WXMYuF9F KA1mbCJn7bRLVsbfNuY0xs54R89/FK41gjAqQLR93pxWNszC8IAqjBnsvLyD/K2mtcvz kyghTxqWvmqbceM28IdY5TvB55QH6g2/xgB/VmcWtwPeQVZYdZDT1swsbdaaX+7MdZ8p ngHA==
X-Gm-Message-State: ABuFfohQS9A8WNF4nvEAdh6+zMyBrVZPLxvSBkEP57r9CiVdrtkSQAAy Q3MnJNifR7rBz9BroR4oKapExQt81h+rOcIVsQo=
X-Google-Smtp-Source: ACcGV61LjllRqGUFVsg2JuOgN5woMTY0Dx/tr+bvPX/D1rf33JIq/lDHEiOUOdSs3reipH0cUcMR8q1Iutqs1YblhyE=
X-Received: by 2002:a0c:bd1e:: with SMTP id m30-v6mr23224525qvg.234.1539094577142; Tue, 09 Oct 2018 07:16:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: "Andrew G. Malis" <>
Date: Tue, 09 Oct 2018 10:16:06 -0400
Message-ID: <>
Cc: Alexander Vainshtein <>,,,,,,,,
Content-Type: multipart/alternative; boundary="0000000000008be16f0577cc61c6"
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 14:16:22 -0000


It's much harder to mandate use of EL than the CW for several reasons:
- CW implementation is much more common than EL implementation
- PWs and/or EVPN are rarely the only traffic in an MPLS traffic tunnel,
rather, they will be multiplexed with other MPLS-based applications that
are using the traffic tunnel to reach a common destination. Thus, by using
the CW, you can disable ECMP only for those MPLS packets that cannot
tolerate reordering.

That said, I'm also concerned that because of the existing text in 7432,
implementations may not be using the CW even for P2P EVPN.

And we still don't have a good answer for Muthu's original question. :-)


On Tue, Oct 9, 2018 at 8:49 AM James Bensley <> wrote:

> 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"
> reordering.
> Cheers,
> James.