Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08

"Ali Sajassi (sajassi)" <> Wed, 06 December 2017 11:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 27D77126B7E; Wed, 6 Dec 2017 03:52:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BFESb-VCvPh4; Wed, 6 Dec 2017 03:52:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 353791242F5; Wed, 6 Dec 2017 03:52:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3372; q=dns/txt; s=iport; t=1512561163; x=1513770763; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8FXOmbIZ7T3yeQXzHrSKQKYbLs98JxxvhPbgfVy/ZJw=; b=il7PtnSoi1eDM9F6V4dFmO3NQltR16I8/ntlT6zXIMe26LbctFLVu4kL pm3s1x4P6qyge6QYR03yJDMz2um0vw6Jkb3J/1QJlrGaJXWc5T3GcATXY yt/0Hy+L0+YySnrJ/4XpHZ4lkjRFT+XX3Lk1bM0WfcZwisX8Oa2MRdcH7 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.45,367,1508803200"; d="scan'208";a="40993154"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 11:52:42 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vB6Bqg14013844 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 11:52:42 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 06:52:41 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 6 Dec 2017 06:52:41 -0500
From: "Ali Sajassi (sajassi)" <>
To: "" <>, Martin Vigoureux <>, Alvaro Retana <>, "" <>
CC: "" <>
Thread-Topic: [bess] AD Review of draft-ietf-bess-evpn-overlay-08
Thread-Index: AQHTbUnIE1F0wt2PNkWhZhKoHul01KM04mOAgABAs4CAAOF7AA==
Date: Wed, 06 Dec 2017 11:52:41 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.28.0.171108
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-overlay-08
X-Mailman-Version: 2.1.22
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: Wed, 06 Dec 2017 11:52:45 -0000

Hi Thomas,

Please see my reply inline.

On 12/5/17, 6:25 AM, "BESS on behalf of" < on behalf of> wrote:

    Martin Vigoureux, 2017-12-05 11:34:
    Perhaps draft-ietf-bess-evpn-overlay could hint on such a Geneve
    work for EVPN; something like: "Adapting the EVPN control plane to the
    Geneve encapsulation is out of the scope of this document, and is
    expected to be covered in a separate document based on the same
    architectural principles" 
I will add the following sentence to the abstract.
“This specification is also applicable to other NVO encapsulations such as GENEVE, GPE, and GUE; however, these encapsulations may require additional incremental work and thus will be specified in  separate document(s).”
    (Related to this sentence, but not related to your question:)
    I recently realized that I'm unclear on this point: the way the MPLS
    label fields are decoded is not the same for a VXLAN or NVGRE encap
    (where the whole 3 bytes are used) than for an MPLS encap (where only
    the topmost 20 bits of the 3 bytes are used). This means that, although
    the encoding is unambiguous when one encap is used (or when VXLAN and
    NVGRE would be used at the same time), it becomes ambiguous when a mix
    is used, for instance MPLS and VXLAN, unless the dataplane MPLS label
    to use is equal to the VNI after a 4-bit left shifting.
    If I'm not wrong "...routes MAY be advertised with multiple
  encapsulation types" needs to be restricted to the cases that work.
I added the following paragraph to section 6 for clarification:
“When a PE advertises multiple supported encapsulations, it MUST advertise encapsulations that use the same EVPN procedures including procedures associated with split-horizon filtering described in section 8.3.1. For example, VxLAN and NvGRE (or MPLS and MPLS over GRE) encapsulations use the same EVPN procedures and thus a PE can advertise both of them and can support either of them or both of them simultaneously. However, a PE MUST NOT advertise VxLAN and MPLS encapsulations together because a) MPLS field of EVPN routes is set to either a MPLS label for a VNI but not both and b) some of EVPN procedures (such as split-horizon filtering) are different for VxLAN/NvGRE and MPLS encapsulations.”