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

"Satya Mohanty (satyamoh)" <> Mon, 26 March 2018 19:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B63E127867 for <>; Mon, 26 Mar 2018 12:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -12.522
X-Spam-Status: No, score=-12.522 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, 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 AGoj_cAfAczC for <>; Mon, 26 Mar 2018 12:23:01 -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 08ADD127337 for <>; Mon, 26 Mar 2018 12:23:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=19738; q=dns/txt; s=iport; t=1522092181; x=1523301781; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=T0RbP+5LcE1zjqnwxnekxdxlEgc+bVGcX0fyVfXJaks=; b=dkI9BBFHCwZGRwV4cxFcro+YGwdlUwLQY4hHk1G/fZGww5AkTXvhG7xv SmerzkoQOYTp4wXuBFjRrHc/4wE1ZuVx4ECh97+4ODkbRR/2Y41C5EMHD rY02Tay/ktxBzp93GYul9E8S0ZxS03Pm4uvSy9BsvKkmLAGyDJoAzSA6R Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.48,365,1517875200"; d="scan'208,217";a="375744719"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Mar 2018 19:23:00 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2QJMxc1024529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 26 Mar 2018 19:22:59 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 26 Mar 2018 15:22:59 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 26 Mar 2018 15:22:58 -0400
From: "Satya Mohanty (satyamoh)" <>
To: John E Drake <>, Sandy Breeze <>, "Rabadan, Jorge (Nokia - US/Mountain View)" <>, Eric Rosen <>, "" <>
Thread-Topic: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description
Thread-Index: AQHTweW4pKI1nWgbp0ukIa0wdFUT3aPcm6uAgAG0fQCAAS0CgIAAC7gAgAAnSICAAxP/AP//9XMA
Date: Mon, 26 Mar 2018 19:22:58 +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_D0D407D6C24645E8A7E39F945606F95Bciscocom_"
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: Mon, 26 Mar 2018 19:23:03 -0000

Hi John,

We will take your feedback into account.


From: "<>" <<>>
Date: Monday, March 26, 2018 at 6:00 AM
To: satyamoh <<>>, Sandy Breeze <<>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <<>>, Eric Rosen <<>>, "<>" <<>>
Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description


Comment inline.

Yours Irrespectively,


[John] Wouldn’t it be better to have this draft define a bit in the Multicast Flags extended community (<>) indicating that that the originating PE is neither DF nor backup DF for this broadcast domain on any ES to which it is attached?  This allows us to always advertise the IMET route and makes the situation explicit.  I think the consensus is that this situation is rare so the number of IMET route updates shouldn’t be excessive and we could also say that this bit is only set by EVPN DC GWs.
[Sandy] We discussed the use of extended community to signal NDF, this is indeed a viable alternative approach and one we’re not against.  We didn’t choose it over not sending IMET because we don’t have a good reason why not sending IMET at an NDF is actually a bad idea, for our use case.  That said, if the consensus of this list is to use an extended community then a flag in EVPN extended community sub-types registry is a possible fit
[Satya] Just to make clear, the Multicast Flags extended community is only sent with the IMET when IGMP proxy is supported. If the BD does not support IGMP/MLD, then this won’t work as Jorge pointed out earlier (BUM with IR only). Perhaps, if there  were available flag fields in the PMSI Tunnel attr, one could have used it. Also, creation of a new extended community for the purpose of this optimization looks to me to be adding extra complexity to the CP. So we did not prefer doing that. Setting the label to 0 would have worked, but the value 0 now has the semantics that Sandy points out below.

[JD]  I don’t think this is correct.  The IGMP Proxy draft defines the Multicast Flags extended community, which means that your draft would need to have a normative reference to that draft.  However, your draft would be free to define a new bit in the extended community and indicate that support for the that bit is not contingent upon support for the IGMP Proxy draft.