Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

"Dikshit, Saumya" <saumya.dikshit@hpe.com> Thu, 19 August 2021 14:56 UTC

Return-Path: <prvs=0865e43083=saumya.dikshit@hpe.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E543A1DF0; Thu, 19 Aug 2021 07:56:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level:
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hpe.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMZerwKLDwFw; Thu, 19 Aug 2021 07:56:52 -0700 (PDT)
Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com [148.163.143.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A72F3A1DEF; Thu, 19 Aug 2021 07:56:51 -0700 (PDT)
Received: from pps.filterd (m0134425.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 17JEnKLS003809; Thu, 19 Aug 2021 14:56:50 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pps0720; bh=XzJ/V1tMnJuKin3ax3YzNuR1H/GfxWnwR+b/QpOY9+g=; b=ZTRcBx1r9hmXUbZQ650cAJ1NUTpWuO5PuN2kqd7cvBvMi7/letzNR5U6QJ5+svw6ge2z 0JFzx29cUX4LyduhnhhT4Bq7n+l68I/C3YdLU16BI2IeN3IvSQaOhvGzYc1soJlPvghX m6dYNsG1fr7hIL57FEDaOJoMKlu8HepYSzkg6cv46I9TYXYuBIy8Nag12NN92GZjNM44 hL8ypmcOdF32iax9iJX5+xa6uWnhi/U9AO1pbAIQeBkyn/2o6ryE3cyRDRRIsgVjxDgU WqzOYduOBejpJl6wmSrqAJuknXxzeo6keRNZotIUfarSvtAYs0fciBDS/ZqiP3390ucG tw==
Received: from g4t3426.houston.hpe.com (g4t3426.houston.hpe.com [15.241.140.75]) by mx0b-002e3701.pphosted.com with ESMTP id 3ahfe0vus7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 14:56:50 +0000
Received: from G4W9121.americas.hpqcorp.net (exchangepmrr1.us.hpecorp.net [16.210.21.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g4t3426.houston.hpe.com (Postfix) with ESMTPS id B77AF4E; Thu, 19 Aug 2021 14:56:49 +0000 (UTC)
Received: from G1W8108.americas.hpqcorp.net (2002:10c1:483c::10c1:483c) by G4W9121.americas.hpqcorp.net (2002:10d2:1510::10d2:1510) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 19 Aug 2021 14:56:49 +0000
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (15.241.52.11) by G1W8108.americas.hpqcorp.net (16.193.72.60) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Thu, 19 Aug 2021 14:56:49 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AW5PcsKbUOLJXnMzR1lP9GPbQhi7K/0yuI5BPK2c5qPNe5Ht3btdASSxLoEsmekpDLyxO/AK1JsXnlxNMI9NkBeevDeaLpcmbyt/7it/BApmCpFAV6sa6nU3v61CMGC/YPnqTnPa/e2auYP/3qb4O1jE6HNBXz091J0L0DhzpjhQ1/fBKx+4BXkvNxbLXZkK4a4vs+7fR+mwbOZU/zrDn1TRN89//f/GxaeJtGImHEQk0/+BoOw0Yq9T6tmTWQDaJrlph81s/8e1DQhR7gUvuwIP7KgApSfF/4GuoF8VTv2E+VjARe6BbpyRIKUw9ktk8n7zgSk0NhKBQPh5Mv5HKA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ocIoQtBNbz3yV/9fMHiHnFqSqv+eCkxqAGWKW+w0s9c=; b=PWkodcmv5Nb17eWVP4AJpN6q7XVOQtB3jI09qVGa6Uz7Z54JNYaQ7nHp2UUvMoAdWA/3GXM+71QWW5mtVS/uD1S+iYwWo4E2M9+qulzsNFDRq+bZK2k4et9GfDlq4WD5/xBceS5F9WRuayYHw5JJycuCwvnLjEXphTFHTZLapzl4eOBIQ9JHrpfL60+SAWXlxmnsaXKLVuQNSTLEIIQZ5SPw3EL1FuNXZExOao5FMoz8Qm5dI/v30gL7qhAzdUWe3zxiISpzRKNiV0s0v3GszYgOIhPxhnRD0Wfe1ZdK1iGfP0+hIJjACpt70uudKkt6eE9+voWMCd8YAlJbT65j7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none
Received: from CS1PR8401MB1237.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:7514::15) by CS1PR8401MB0648.NAMPRD84.PROD.OUTLOOK.COM (2a01:111:e400:750b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.18; Thu, 19 Aug 2021 14:56:47 +0000
Received: from CS1PR8401MB1237.NAMPRD84.PROD.OUTLOOK.COM ([fe80::413a:e95e:bc8b:db7c]) by CS1PR8401MB1237.NAMPRD84.PROD.OUTLOOK.COM ([fe80::413a:e95e:bc8b:db7c%10]) with mapi id 15.20.4436.019; Thu, 19 Aug 2021 14:56:47 +0000
From: "Dikshit, Saumya" <saumya.dikshit@hpe.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, "draft-ietf-bess-evpn-fast-df-recovery@ietf.org" <draft-ietf-bess-evpn-fast-df-recovery@ietf.org>, "draft-ietf-bess-evpn-df-election-framework@ietf.org" <draft-ietf-bess-evpn-df-election-framework@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
Thread-Index: AdeUsUIzDqdWM3jCQ+GSnr3hpDVnWwAUYe7OAAGB9SA=
Date: Thu, 19 Aug 2021 14:56:47 +0000
Message-ID: <CS1PR8401MB123794D686B4006BDC54679A94C09@CS1PR8401MB1237.NAMPRD84.PROD.OUTLOOK.COM>
References: <TU4PR8401MB124868977A69278FC870513F94C09@TU4PR8401MB1248.NAMPRD84.PROD.OUTLOOK.COM> <BY3PR08MB706044C8A3572A624DFD1E51F7C09@BY3PR08MB7060.namprd08.prod.outlook.com>
In-Reply-To: <BY3PR08MB706044C8A3572A624DFD1E51F7C09@BY3PR08MB7060.namprd08.prod.outlook.com>
Accept-Language: en-IN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=hpe.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 55fea43b-3378-408e-edf8-08d9632191b3
x-ms-traffictypediagnostic: CS1PR8401MB0648:
x-microsoft-antispam-prvs: <CS1PR8401MB0648768052F9F864374366C294C09@CS1PR8401MB0648.NAMPRD84.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Ajy6iUPiEUuAXY3pMt9y43DrUyISIFtccezePU9TBhmYNDCC9BS+OgaL0Ai1Hx5MGB0IIjsw5iP/F12pQ7YK9/eTa3GdZseOaD+snL2OG1M5dovpuc0sCZkQkbLoWTlt8jodWWR+qMyyABRDbNtwQkv6Hvbf2YsjdAjPVnMdw26slrJR+em/rMReFG2N60LPISYxsQcohs9t+lpihc+huTRxls9yPF5pWww4V7dVmTRbDsUCeqogaojdG7LtfIKaX360d4GMr8tu4fVylV5aljxZIR6cl12yBDhJyHLKF10qfldksEql7An1Sa9YUX9DZtMAer80bGBwsMm+Alf3Y7wl/PBB8K70beNrgWslzuYGHh2VLEN8cp3mvuu2s3CsLuaIfqt0+uUy6gKB1WJlBI63frLJLg+UBt7lTpd3KAEvdEI4/y2DdrFLWGLwrPEo+CJF4BAs1U8LL8WKasrF80/2bUTIzayEte8pNhnG1Suf+I8h76adexIpcA1V6gmgcyN1KG857NNyFRJvhxO4p3iO6xEsNw14SwudB63/XbXOWRV28BJZ5GTEb/bFYIi+W6m7/Kw2pN/Ss+3QH33qXSwXFcqa+BnhAfo7j3o4KyeamFz8ig/407JZOcgcJmN0IuDKfQ5AhY9Gw7DVqso9zF8bMLFslNIK4nY9qYp2QNL+HzFkYPkZrROlvr7mJ9fhFP5V88wE642HMIKBaGe6XovattPQggrTPfUHSjMWHiaOWU1tKmEDDHqfxFEzmhJbyDkLf3IXDpkDxwoYSYbwzCjJ80yrhe9/YV1d6Ewu4xnL60v/fib3crkdGcygdLtyQy4fxE7/55D4uraRtHu7hg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CS1PR8401MB1237.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(136003)(396003)(366004)(346002)(376002)(66946007)(76116006)(5660300002)(316002)(2906002)(9686003)(55016002)(66476007)(4326008)(38070700005)(66446008)(64756008)(66556008)(166002)(83380400001)(8676002)(8936002)(52536014)(478600001)(66574015)(53546011)(33656002)(186003)(26005)(86362001)(55236004)(6506007)(296002)(7696005)(966005)(38100700002)(110136005)(122000001)(71200400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: Aw3+amh1b9UwfQlSn2vMJ1/E8ktQJ0VtV1vWajWQxWxhO9l7mZFG/WoA5vYSta9jmlQ+pAhvru9ANiTllHg1NZPJ+Y19aTUyXHq4ABfoDOk/WjL1m5A/ge0+VqMUfmlRtfZg6Ajr4lPV41gMctwlT/sSDNZFnvIlhz6ejVdku/jcFONbu0939ytu/R4I1mBE/7DzupvqIenL7XjnIf5yrJzRkdduhLg6u1oOK82lA/Nn7mCltNrfM+xuGN9e3YW492kMW43yZ8/aMuVOnORqfA0TDtqvo99hHYztvZBPFG5YXw09Vv56ieaDIcts6Pp2f+OckS45UmVkPHv1tozPuDN2cMPs8jD7pQy+NskUdenQp5il867dq8FAQl3Kc6KXBwvxZNm0j2fsG78BcpoKxiU3YDCpxJaWzlgkOiWV3xJTZx8Erpdp7UWnkzeMWmJHfffmstYbgiNafFPcW8RZFtfjpUXC4kFmrKELSc51mwrcr3g9D8a4kHMwEf+tWSkf+nDeV1R7RP5BgHhRBmQ5zvKa+s3uvbTydIEqVoWiqZYACvQHZDSL/hUtLCubV5e2STridCjmb/CmIJYoNhls6gH9d6bfzHQEdQOdaaM2Q0mHkhAkCknFxG3oQHKme/eLDnAxvZYNmwGE0OAaiilXZPT4DfMexkl2Evcc6iFbxVfCo8MvPeaAlGBwGsAZuLefBZFjcs2uuTbIENpeK5M9JWeq3u0SG1ay7AcZoEWqoOD4elM6eHAtO7gW1I8daTnTNwC8OOhfC81saOU6v+SIpDv45jm14i7j+p3mlbeuyvqBI9M7uGyubyWEwyPXi2F4bOLPLW7TNOirqxlYsVfGQ63F+qvqxPhEWjJZ/ggYQUkcSu85qe0o+Lt5ZTfgJZAUJJpawGu7CgsNurWJrdc43toA51crp4ymdbKsZYmFV8zYh9ua1HfJs2pWgzkUuk8N6ddVnhoSG6yAx39oRJuCAi9c62d2qsgrsp/crO8K1zqrhbQTdIe7SwmybkxFlxiXJsGqgDnh7ekJvnj1VfWoHVSr68TpKrLf40NrQzgtEdw3K16vGLsfFMzHo8svZd+lvKlOMMdqLiNB0sJJVOudXRA8/LHH/6+G/tXXPjB5SefY49LT/WJYO4t46tBpHZtJ4cdfeS24RqAddylaq+l5RDMFXZ5fMDeqCrcEbr/aN2mfSun9e+jOxNHFaDE9KWLsS3jutz2poHYHm2NBB1vpAqL/wBSeJ2xHuAqVY5U2UPGzya8OBy6deLJeFyoT7WGSY49zh8+11aMvJ4/EnSQJ93VVXmEY8BXJhEwuwlYxXjcWgIYxNvupypktd0iL8og2
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CS1PR8401MB123794D686B4006BDC54679A94C09CS1PR8401MB1237_"
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CS1PR8401MB1237.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 55fea43b-3378-408e-edf8-08d9632191b3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2021 14:56:47.8045 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OTMGJo6webOC4uiyNgB23uCfKLCGkMybF1iDk/aF6VDWDkavmZqWdxmzkaI5macqIkuJYzNgw+FOUOAQ5KPFIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0648
X-OriginatorOrg: hpe.com
X-Proofpoint-ORIG-GUID: wWsIrvrSGeTUfCWpDuUGxrFtQg57ll0b
X-Proofpoint-GUID: wWsIrvrSGeTUfCWpDuUGxrFtQg57ll0b
X-Proofpoint-UnRewURL: 14 URL's were un-rewritten
MIME-Version: 1.0
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-19_05:2021-08-17, 2021-08-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 lowpriorityscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 clxscore=1011 impostorscore=0 bulkscore=0 priorityscore=1501 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2108190084
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/-93KiGzrfdj-Fxu9lZ7HrBgALKQ>
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Aug 2021 14:56:59 -0000

Thanks a lot for a prompt reply Jorge.

Well I missed drawing the Host(s) behind the remote Vtep (PE) assuming that it will not make any difference (except aliasing as you mentioned).

>>>> FW1 and FW2 can be attached to the same all-active ES
How to handle the broadcast packets like ARP request for the firewaill credentials ? ARP request (MAC_F) should to sent to the local vtep, which should act as a DF.
The hairpinning of ARP request to remote DF (over WAN), should be avoided. That's the reason it would be good to have two DFs for the {ESI, Bridge-domain} in this scenario.

>>>> In the implementations that I know, the local static MAC will be preferred over the EVPN MAC/IP route with the static bit, hence again you will have the behavior you want
The static-mac approach has an issue, when the local firewall goes down, there is no organic way to prefer/plumb the MAC_F published by remote vtep.

Thanks
Saumya.

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.rabadan@nokia.com]
Sent: Thursday, August 19, 2021 7:47 PM
To: Dikshit, Saumya <saumya.dikshit@hpe.com>; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc

Hi Saumya,

To be clear, your query has nothing to do with the two documents you refer to. In fact I don't see any issue related to multihoming.
Given that in your example host-1 and FW-1 are directly connected to the same leaf, and host-2 and FW-2 are connected to the same leaf too, I can see your use-case resolved in two ways:

a) FW1 and FW2 can be attached to the same all-active ES, I assume local-bias behavior as in RFC8365 (seems you are using VXLAN as data plane). Host-1 will send unicast and BUM to FW-1. Host-2 will send unicast and BUM to FW-2. In case of failure, the behavior will be as per your description. Note that a third leaf with a local host will do aliasing to both, but since it seems you only have directly connected leaf nodes, you are fine.

b) instead of attaching FW-1 and FW-2 to the same ES, EVPN allows 'static' MACs that are advertised with the sticky bit set. You can configure MAC F as static in the two leaf nodes. There is no mobility procedures for static MACs, hence forwarding comes down to the local selection on each node. In the implementations that I know, the local static MAC will be preferred over the EVPN MAC/IP route with the static bit, hence again you will have the behavior you want.. and again, only in your example with two directly connected leaf nodes.

My 2 cents.
Thx
Jorge


From: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>
Date: Thursday, August 19, 2021 at 4:51 AM
To: draft-ietf-bess-evpn-fast-df-recovery@ietf.org<mailto:draft-ietf-bess-evpn-fast-df-recovery@ietf.org> <draft-ietf-bess-evpn-fast-df-recovery@ietf.org<mailto:draft-ietf-bess-evpn-fast-df-recovery@ietf.org>>, draft-ietf-bess-evpn-df-election-framework@ietf.org<mailto:draft-ietf-bess-evpn-df-election-framework@ietf.org> <draft-ietf-bess-evpn-df-election-framework@ietf.org<mailto:draft-ietf-bess-evpn-df-election-framework@ietf.org>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Subject: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and rfc
Hello Authors of https://datatracker.ietf.org/doc/rfc8584/<https://datatracker.ietf.org/doc/rfc8584/> and https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery>

I have a query regarding the following use-case which I could not find supported with existing DF-election procedures.

Scenario:
All PE (Vtep1 and Vtep2 in below example) routers attached to same ES and both act as DF.

This is a typical case of distributed firewall (active/active) across fabrics (sites),
Where in, the preferred firewall is the one local to the site, whereas, upon failure,
packets need to be redirected (over WAN, via DCI/VPN) towards the remote site firewall.
The firewall-device is connected to it's first-hop vtep over the same bridge-domain and same ESI.
All in all, it's an emulated multi-homing scenario.

This is scenario of distributed firewall devices host same MAC credentials.

Simplistic example :
There are two sites, SITE-1 and SITE-2 in the below diagram.
Traffic (including BUM) generated by Host1 (in SITE-1) (for a bridge-domain)
 should run through site-local firewall instance (firewall_1) preferably.
Only in case of local-outage, the traffic should be send across over WAN to the remote firewall (firewall_2).
Same should apply to traffic generated by Host2 (in SITE-2), wherein,
it should preferably run through the local firewall (firewall_2) and over a failure should go over the WAN towards firewall_1.

Vtep1/2 learn the firewall MAC (MAC_F) as local learning and also from the remote Vtep2/1.
But since both the learnings are over the same ESI, it should not lead to MAC move.
Cometh the local firewall failure, Vteps (1 or 2) should start redirecting the traffic to remote SITE.

Any ARP request (BUM traffic) for firewall credentials landing at either Vtep1 or Vtep2 should be flooded to network towards the local firewall.

    SITE-1                 |                         SITE-2
------------------------------------------------------
      Host1               |                        Host2
         |                     |                          |
     Vtep1  == ==WAN======  Vtep2
       |                       |                           |
Firewall _1           |                   Firewall_2
  (MAC_F)                                  (MAC_F)

Please let me know if there is a way out (with out) using existing standards.

Thanks
Saumya.

-----Original Message-----
From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: Tuesday, July 6, 2021 8:31 PM
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: [bess] I-D Action: draft-ietf-bess-evpn-fast-df-recovery-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

        Title           : Fast Recovery for EVPN DF Election
        Authors         : Patrice Brissette
                          Ali Sajassi
                          Luc Andre Burdet
                          John Drake
                          Jorge Rabadan
        Filename        : draft-ietf-bess-evpn-fast-df-recovery-02.txt
        Pages           : 11
        Date            : 2021-07-06

Abstract:
   Ethernet Virtual Private Network (EVPN) solution provides Designated
   Forwarder election procedures for multi-homing Ethernet Segments.
   These procedures have been enhanced further by applying Highest
   Random Weight (HRW) Algorithm for Designated Forwarded election in
   order to avoid unnecessary DF status changes upon a failure.  This
   draft improves these procedures by providing a fast Designated
   Forwarder (DF) election upon recovery of the failed link or node
   associated with the multi-homing Ethernet Segment.  The solution is
   independent of number of EVIs associated with that Ethernet Segment
   and it is performed via a simple signaling between the recovered PE
   and each PEs in the multi-homing group.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/<https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-fast-df-recovery/>

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-02<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-fast-df-recovery-02>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-02<https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-fast-df-recovery-02>


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>


_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://www.ietf.org/mailman/listinfo/bess>