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

Sandy Breeze <> Thu, 22 March 2018 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94D801200FC for <>; Thu, 22 Mar 2018 09:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] 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 UUrrWndY3_Ov for <>; Thu, 22 Mar 2018 09:02:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3E8E124B18 for <>; Thu, 22 Mar 2018 09:02:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VNvxXSmMojBxU12rWNe4xWwZEuG2H/ASyGyBUlbLk6A=; b=war3fz2FPaxluK/n58OANFt3N6KTqRs29MMvC6EN8G3R7zNutDGJMeoDbDuBpAPXcuf3wbt6cmpe4UuKUZ9XsgbTddwosKFZYVWMyPHzZmIZDlIxVC8f6jacCRLiJP0AP0ircu8lI/eFvYEP7XBbnHS2mH2m6p/NpEuwi5iyWs0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.10; Thu, 22 Mar 2018 16:02:03 +0000
Received: from ([fe80::b549:3438:e0b2:5497]) by ([fe80::b549:3438:e0b2:5497%8]) with mapi id 15.20.0609.010; Thu, 22 Mar 2018 16:02:03 +0000
From: Sandy Breeze <>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <>, Eric C Rosen <>, "" <>
Thread-Topic: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description
Thread-Index: AQHTwTLSpKI1nWgbp0ukIa0wdFUT3aPcSQuAgAAhzICAAAD9gA==
Date: Thu, 22 Mar 2018 16:02:03 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.c.0.180318
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:67c:370:128:71b9:88db:7074:d546]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0202MB2561; 7:gYxkTYF51KZD5dAvv38uZccbSNER4wVLP6v+bhxZSQ7PDAvjln8lV3744dKld20URpf6qSFYq1YIO+CSfng1RlaSeGS35hqUtBV8NE7JWxvB72Jo4oSsEFsYlzZb3AzyTAh3d1pFx/wsHgHJ5uOHFcPV3i/IuEgUEHV2VsEit01mymelbV1yqBGKaf04z5HNKUfPsz/Uq4akY2FwV1TA3ZpwRtfeyfNh6Q5qnvq4Uyh5G8dO1BW1tMuoCGkNFqnS
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 59f04dc8-78db-42d4-7e9a-08d5900e40c7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM5PR0202MB2561;
x-ms-traffictypediagnostic: AM5PR0202MB2561:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(138986009662008)(82608151540597)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:AM5PR0202MB2561; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0202MB2561;
x-forefront-prvs: 0619D53754
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(39380400002)(366004)(189003)(199004)(6246003)(105586002)(53936002)(1941001)(25786009)(82746002)(229853002)(54896002)(6512007)(46003)(68736007)(5660300001)(6306002)(102836004)(106356001)(6486002)(6436002)(76176011)(7736002)(3660700001)(81156014)(446003)(59450400001)(8676002)(3280700002)(99286004)(53546011)(6506007)(83716003)(110136005)(236005)(5250100002)(2501003)(2906002)(58126008)(478600001)(8656006)(33656002)(8936002)(86362001)(5890100001)(316002)(97736004)(81166006)(186003)(2900100001)(8666007)(6116002)(14454004)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0202MB2561;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: yc4XNDGJeePsMr/TWL1epvmcmgiRjcEacvnWC/jmeKuL6HuLk0mO7pk/QN/hnaoNBo5q/QfdkWENWRU75JveMEyUFjwReTq8+RfmLAw58QbRKQjuITxMy9y5pl2bZpOcC0tfXLoySWjYZEhhNf4rCOUB+CGZwN7r4GmXEZyaVW46v/HAN+NVp9A5WPrVq36UZyKkQ8F/2UhEiRGX3dUo57SbWdXyISIk1vwiwFSPZ1xSjQoeOivnVSmxPS81fXnleG6Lrn7xXO+iheM1u1AFup5OSy0vCaklK4y3oyRTr+rsd7HTe/57+FCovP1L9vhU64RzlkuPpwH2LA6OIp7Fwg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CF347B48FC954C68A86713D7264436AAeuclaranet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 59f04dc8-78db-42d4-7e9a-08d5900e40c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2018 16:02:03.2520 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f87a7640-3b94-4bbd-b5fa-b4c15947cf56
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0202MB2561
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 16:02:14 -0000

Eric, Jorge,

[Sandy] Comments inline;

On 22/03/2018, 14:58, "Rabadan, Jorge (Nokia - US/Mountain View)" <<>> wrote:


The way the draft is described makes me think there are no IRB interfaces and this is limited to Ingress Replication. But should be clarified.

Also my interpretation of RFC7432 is that IMET routes are mandatory to enable the handling of multi-destination traffic in a BD. But in a non-DF PE for a given ES and with no other ACs in the BD, assuming Ingress Replication, there is no such multi-destination traffic (Tx or Rx). So one could interpret that RFC7432 is ok with withdrawing the IMET route in that case.

Assuming the above, my reasoning is that advertising/withdrawing an IMET route does not change any procedures or modifies any routes.

[Sandy] Yes, your interpretation is correct

Other than that, I fully agree with you this is a corner case scenario. And if this goes one, it must explain clearly what the use-case is.

Thank you.

From: Eric C Rosen <>
Date: Thursday, March 22, 2018 at 1:57 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <>, Sandy Breeze <>, "" <>
Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description

On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote:

This scenario definitively helps understand the use-case better. Still a bit specific but I think you should add this scenario to the draft, and again, make it Informational since there is no control plane change for this.

If I understand correctly, the draft does make a control plane change, since it describes situations in which IMET routes should not be originated.  This contradicts RFC 7432, and so would have to be considered a update to that, and hence a standards track document.

Since I wasn't at the BESS meeting (but did watch the video), it's possible I missed some of the discussion, but from my reading of the draft, I have the following concerns.

I'm not sure the draft properly describes the situations in which one may omit the IMET route.  It describes the situation in which a PE doesn't need to propagate, on any of its ACs, BUM traffic that it receives from the backbone.  However, if the PE has IRB interfaces, doesn't it need to receive some of the BUM traffic in order to process that traffic itself?  For example, if a PE is configured to be  a PIM router attached to two Broadcast Domains, BD1 and BD2, won't it need to receive PIM Hellos from BD1, even if it doesn't actually propagate those out the local AC attaching it to BD1?

[Sandy] - It was not the intention to include IRB and the use case is limited to Ingress Replication only.  We will call this out in -01

At the meeting a DF election scheme was proposed in which, for a given <ES,BD> pair, there could be a different DF for each(S,G)  multicast flow.  I don't think the draft takes this into account.  I wonder how many other scenarios there are which the draft fails to consider.

[Sandy] The -00 draft doesn’t mention it, but the authors have discussed consequences on each DF type, not just (S,G) and (*,G), and the consensus is this has no impact.  Evidence of that will appear in -01.

Many EVPN drafts have been written on the presumption that IMET routes will always be originated.  Some of the drafts add flags or communities to the IMET routes to advertise capabilities of one sort or another.  Every one of those drafts would need to be checked to see if it still works when some nodes do not originate IMET routes.

[Sandy] The following drafts were read and considered to be non-impacting

  *   Df-framework
  *   Fast-df-recovery
  *   Per-mcast-flow
  *   Igmp-mld-proxy
  *   Irb-mcast – Though we assume no irb in our scenario

As future EVPN drafts are written, the authors (and reviewers) will now have to remember that they cannot presume that all the PEs attached to a given BD are originating IMET routes for that BD.   This creates more complexity, more corner cases, and ultimately, more specification bugs.

[Sandy] Isn’t that the same situation with increments to all standards?

Still, one might consider adopting this complication if it were a big win.  But it only seems to apply to one specific (and not very common) scenario, and from the discussion at the microphone it wasn't clear to me that the co-authors are even on the same page about just what that scenario is (recall the discussion about whether the diagram in the draft does or does not depict the intended use case).

[Sandy] In the -00 draft and during bess session, we positioned the use case from a very general perspective.  This caused confusion, and the specific problem statement has been explained in this thread and made clear in -01.
Use case may be specific, yes, if perhaps you consider DCI / EVPN GW’s specific at the edge of an MPLS network.  Common, perhaps not yet, but multiple vendors have shipping code which permit this scenario, so one would suspect it to become more common as adoption becomes more widespread.