Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

"Satya Mohanty (satyamoh)" <> Thu, 22 March 2018 06:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1191D12D7F3 for <>; Wed, 21 Mar 2018 23:42:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 j_UOh35dFAfW for <>; Wed, 21 Mar 2018 23:42:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D49D1201F8 for <>; Wed, 21 Mar 2018 23:42:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=38358; q=dns/txt; s=iport; t=1521700950; x=1522910550; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vOmCNdvwQG3elTjZduxhDiYPITfOMRTTg7kbx45UFRI=; b=A80xQvPB0PBHAf4LG5HPSJ97g7HuOFSVOmmi3z0ci99xM16Xo2zD7fs1 XbOd+Yl0XF8bsMhVJ7GagxHmYK7+NEvkxgjnpe0Nb5rC0xC7iBBJ/ryTo WcZIKYmKbcM3ZENPlZjERC9Msy+PfhOCp2kO4Di/L2XNFRft6S6gJa1Hr o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.48,343,1517875200"; d="scan'208,217"; a="87104032"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 06:42:29 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2M6gTDT004566 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Mar 2018 06:42:29 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 22 Mar 2018 02:42:28 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 22 Mar 2018 02:42:28 -0400
From: "Satya Mohanty (satyamoh)" <>
To: John E Drake <>
CC: "Ali Sajassi (sajassi)" <>, Sandy Breeze <>, "" <>
Thread-Topic: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description
Thread-Index: AQHTwUI3pKI1nWgbp0ukIa0wdFUT3Q==
Date: Thu, 22 Mar 2018 06:42:28 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_A745ED99E80F4669BCDF0B36BDD50445ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description
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: Thu, 22 Mar 2018 06:42:33 -0000

Hi John,

That is right. I get your point.

I replied in the preceding mail the reasons for having this option.
If we all decide this is not particularly useful, we don’t have to take that into account.


From: "<>" <<>>
Date: Thursday, March 22, 2018 at 2:17 AM
To: satyamoh <<>>
Cc: "Ali Sajassi (sajassi)" <<>>, Sandy Breeze <<>>, "<>" <<>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description


If we do this, it requires that we define two different DF election types, one that uses ESI and one that doesn't.  Given that we have other DF election types that will give us the same behavior I don't agree w/ this.


Sent from my iPhone

On Mar 21, 2018, at 10:16 PM, Satya Mohanty (satyamoh) <<>> wrote:

We will take the feedback and revise the next version with the EVPN GW case as the primary use case.
Also, we will make it informational.

I need to make a mention again of what I spoke at the mic because I think it may not have been clear to everyone.
In the DF election framework draft, the weight is now a function of  the tuple(vlan, Esid, PE’s IP).
If we set the Esid to 0, then as long as each ES has the exact same set if vlans, the carving of vlans by the algorithm is the same.


From: BESS <<>> on behalf of "Ali Sajassi (sajassi)" <<>>
Date: Wednesday, March 21, 2018 at 6:27 PM
To: Sandy Breeze <<>>, "<>" <<>>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

Hi Sandy,

The key point in here is that the proposal is intended for EVPN GWs (and not PEs). By talking about PEs and NVEs at BESS yesterday, lot of people got confused. Although for EVPN GWs, this proposal makes better sense, for EVPN PEs, it doesn’t much because:

  1.  Vast majority (if not all) of TORs/PEs multi-homing are dual-homing which gives us zero benefit
  2.  Even for multi-homing with >2 PEs in the redundancy group, the chances of a PE not becoming a DF across all ES's in a BD is extremely low. We need to keep in mind that number of ES's are much larger than number of PEs !! And HRW algorithm in our df-framework draft takes into account the ES-id in its hash algorithm which means for the same BD, different PEs can become DF for different ES's !!
3) As soon as there is a stub node (e.g., a single-home CE) connected to any PE, then all bets are off and that PE needs to send IMET route and receive mcast traffic
4) As soon as there is a link/ES failure, then we will end-up with (3) above for dual-homing scenario and the PE with active link needs to send IMET route and receive mcast traffic
5) For mcast flow (*,G) or (S,G), the solution described in igmp-proxy draft  is the most optimal

So, I would suggest to do the following:

  1.  In the problem statement of the draft, capture the below use case clearly.
  2.  Change the name of the draft to “bum optimization for EVPN gateways”
  3.  Capture briefly why the proposal is not intended for EVPN PEs/NVEs because of the above reasons.


From: BESS <<>> on behalf of Sandy Breeze <<>>
Date: Wednesday, March 21, 2018 at 8:58 AM
To: "<>" <<>>
Subject: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

After some discussion, we acknowledge the problem description needs further clarification for this not to become too specific a use case.  Consider the following example of our existing live deployments;


The main points to articulate here are;

  *   PE[1..4] are at the boundary of an EVPN/MPLS domain (core side) and an EVPN/VXLAN domain (datacentre fabric side)
  *   They are responsible for L2VNI VTEP from ToR and MPLS L2VPN in core.
  *   From their point of view, 1 BD = 1 L2VNI (=1 ES).
  *   For any given DF type (modulo/HRW/etc) they distribute DF’s per-ES between them.
  *   Therefore, all nDF PE’s attract BUM for ES’s they’re not allowed to forward on and hence the waste of bandwidth in the EVPN core and cycles.

In our case, the solution we propose works very well.  We also showed this does no harm for the more typical EVPN-multihoming at the PE use case yesterday, which held up to technical scrutiny.

BESS mailing list<>