From nobody Thu Jan 20 21:04:24 2022 Return-Path: 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 54DB53A1A88 for ; Thu, 20 Jan 2022 21:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 OBCtRioeBARc for ; Thu, 20 Jan 2022 21:04:17 -0800 (PST) Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) (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 A38213A1A86 for ; Thu, 20 Jan 2022 21:04:17 -0800 (PST) Received: from pps.filterd (m0134422.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20L2C9Gt026374 for ; Fri, 21 Jan 2022 05:04:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com; h=from : to : subject : date : message-id : content-type : mime-version; s=pps0720; bh=0C0fRKidzQ0VbHxJd4gkhPlu0eIuThT5RLTxtIB1mi8=; b=XXaA84Sbk+YkE0mA8IonS3NbPOV8FSVtBcOdQDUqIRwVBPHI5balCpIbySlKtLFJlsG7 IZGrqHt43WObJpPxdqwtcaay9sFSYEXpMxw4JbAi/mnk5SWkaNt/elQoWLyk87vWzkmJ nUGvBKSk8z4GLN+JEy1JUF2ZatQctpBwrg0tGWRl+qeMmuyblA2VyaP5cTbuA76QdUyq 6OovtCFfE/qmVyKZFcQlu8UXAaPCQWnfHweh41TCzPXOOE4eUikC5+oAKIFfEjpGY2Qx srw+Ua9OeadfMjnQ/kY9qYG/4fMhHwB1nfa4uCmXqvW3clhYYc04Dork+CdsIDwWsVYi 4Q== Received: from g4t3426.houston.hpe.com (g4t3426.houston.hpe.com [15.241.140.75]) by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 3dqhxk9jw0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 21 Jan 2022 05:04:16 +0000 Received: from G4W9121.americas.hpqcorp.net (g4w9121.houston.hp.com [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 5937254 for ; Fri, 21 Jan 2022 05:04:15 +0000 (UTC) Received: from G1W8107.americas.hpqcorp.net (2002:10c1:483b::10c1:483b) by G4W9121.americas.hpqcorp.net (2002:10d2:1510::10d2:1510) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 21 Jan 2022 05:04:14 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (15.241.52.11) by G1W8107.americas.hpqcorp.net (16.193.72.59) with Microsoft SMTP Server (TLS) id 15.0.1497.23 via Frontend Transport; Fri, 21 Jan 2022 05:04:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RN0MpYI4N53iOJUSCxxptfDdzVbAp8prc8gLMIsXN/5P2QJb+ZbYckNDclN6kBzrb6M5+AJWfk0MXuypvUSiB2t0s7Ux5Kd9sdR897qi/dyyceVlfoOa/Kn/K7tN9w8gnNqcq5Zw5tKrNUy+8E13Q+PvXkskrJZQ3IvXd/MWjve0OKUOBB4fsf2vcMQXJ2+J5y65mGFCsPDtb+ktlehErHgllaP9arxVLsAasIEiDPfLwFY6wUeyiGlENWZTU2XyYNkbsaVxvxO6tSz/mu11xY9m0xood1KvRbKjajzQdRP5xlC3h87qG2sGIZB841jn1WuLGbNBb+CXhhWERj30Fg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TEjOxhx6sUyKYdquK3Qrx57BlyqRU+7+GYuS8O0q8XQ=; b=GjOYdKuwE8OZMLVoNEhtxa9uyMerkwDxD82BARNwYNunI+QSlOzULAX0T40bA28ewrfqrdG/omjnzTDejnz5EZt8a8Qg1YXq4ZGhZveLAYT536nIPzLptajZ746Uby2bi3FvROf/xct8QGcEx3tPRUAv2tc4Sg6a02Hf1p82dAsxc9z+D75v3Qi2zsRJnryuMZj5Sy9PV4ZK13Nx5MQJSo4JaT+WVfoCKGoE24MJr7QOI4UMt6hWX4zmHFD9IOBgK6y2vJsT0T1wT6oGrV3H/MK90BRamK0Jng64LnBZRopd5YuBHIJVJCk5Y+BOmUGD+gzys3jO9+kew5w6eAc46A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from SJ0PR84MB1992.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:a03:436::20) by PH7PR84MB1766.NAMPRD84.PROD.OUTLOOK.COM (2603:10b6:510:154::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.9; Fri, 21 Jan 2022 05:04:12 +0000 Received: from SJ0PR84MB1992.NAMPRD84.PROD.OUTLOOK.COM ([fe80::7806:9016:a477:5cb8]) by SJ0PR84MB1992.NAMPRD84.PROD.OUTLOOK.COM ([fe80::7806:9016:a477:5cb8%6]) with mapi id 15.20.4909.010; Fri, 21 Jan 2022 05:04:12 +0000 From: "Dikshit, Saumya" To: "bess@ietf.org" Thread-Topic: draft-saumvinayak-bess-all-df-bum : All PEs as DF: Distributed firewall-gateways across Overlay fabrics Thread-Index: AdgOhCJnvr6fcYmQToaoYw1C+8sFDQ== Date: Fri, 21 Jan 2022 05:04:12 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1da79977-f04c-4374-ef5c-08d9dc9b76ea x-ms-traffictypediagnostic: PH7PR84MB1766:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eEax57k42X/knu8nVac7cZsJ37q3RRu0Lpun0VUGIfWymBoAlyZ8yJZCkZZZ5ppNNMM5KnRFVcI2nO0jgqyqSBvL9zwarAefzYuM9fi40T/fCsk55E6scV5b/fDk0k4n+kDW+7o3ltUpaWlsNoaZ5gI6XvkUlX1epDhFM//Fxj7j6k1T/AVMB72l9iTBQdQfVmhbPF6pCLcmYRL+clPv4HGgKiSUE4VV93Q8kMamDpQ3vA8/Z7P24Spk8aP0TCI4pK7cv8v1Ww+DxS8EVM3gCGJHoJjPDbU758ufgPW7kqeAYLWoY1fa4B9fru69rYAMdX+pERyP+e/4ikFBQb4zMtlOYX/pp6L/Efe5kAdyKwBJzWIHcQDi15pfEvb5krU6Jth2MyKaUKke1baUI0SlIy/1Qwk8eWoMeNDlswzms0o6VRG3IPufAcTaoThr3MgBgDGr6Mu52OpJSiwdfBLDv3tCO/qw+yR/lSuQbChylzxtoQu4Kuu5cjt2CJlTMUyZaZ9j3JgOuwQ0xZInAmjcBbgCgm/exYetOK3/NxRvoesAVPYdd/aBZs6wBuBlTh/vvPSfyiL3nX8IAYJtFR48qUlM3Jn+RCGjvTvnAgoDNgcAM9cfUpsKJMkipTISSXG1+9gUGOjIvwQc9WCXRsUxYgESHa5TUrsA1om4FlV8pOOjp6jhqTSibDfLij3GJCIGgPpDFIzPsC4rDKEof/BLAYMwJSSf59TtEJLbZ/HU4dwSmGKK0WUYaufwcptHP2Dwr+rNDfsk/CyUgF1zsmLbUT62hafxczqWkjq60iJntChMOita/53PQVIz+43z+oGYKiMxVOP6jzAJCq82m2cbuw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR84MB1992.NAMPRD84.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(66574015)(71200400001)(55016003)(966005)(53546011)(52536014)(508600001)(186003)(2906002)(38070700005)(122000001)(76116006)(5660300002)(7696005)(83380400001)(8936002)(33656002)(316002)(66476007)(55236004)(66446008)(6506007)(66556008)(166002)(9686003)(8676002)(30864003)(82960400001)(6916009)(86362001)(64756008)(38100700002)(26005)(66946007)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?jKtVCpHH38yc8/ZVgQjD9vXMQxc+GZ1Ij9fQ5orSI+Z65kl+60c8dLe8+rGl?= =?us-ascii?Q?acDmdUI8GJwDT+h6Tsketb3d6VnTiBTA/4NaXRQHlFSAGdbPQ2t/nd5ib8KR?= =?us-ascii?Q?odt8VXP3b5VorzYQFYEqnO1F0e2gM5H1Cj2n7HB8C/t3VTLz5WOq6KZz7EuB?= =?us-ascii?Q?ByA8pr9LfZvDhUIRGpXHxPd9DyjJupSaM6uwcBbXozLCu7/mNeKgCAmG4wZN?= =?us-ascii?Q?BBzKEK1vi6vc61k2DABSQ8J2ynfXYYmKFTNlbL9O6SYxe6q425YzdiNNTkpR?= =?us-ascii?Q?SBf0/4pz4AYKa5wCz5eiHh2l7itFt63oXBMxHIBvCEF38H5LU+MfDzfcPuM3?= =?us-ascii?Q?mRA/KNBeC2gNoTrKlqokV24lpz2U8SR71r+tQ1irJebeapBFTJlWKOVSKXWF?= =?us-ascii?Q?VG/vuU9D8nNkyE11BpiNDYXi9RTtGVBJ169CZSUJsXmXDaUYsDXwCmIG7ATy?= =?us-ascii?Q?DonWJY+s77z/k+PByj+e7ADcgjSQhrBMQk+u2oLSiII6yba0ke6GFZGvWaha?= =?us-ascii?Q?LRRk0P3wsuXHLZXgJF1d7+jw6XPYHaaFQAzD7bdIuORkkcRyVze2OUFfNMvV?= =?us-ascii?Q?CgL1t9j4mNlbWpCIplRSxqIC6q10ddk+I3T3O81cxJqPNwoRmEtszIZ+3lml?= =?us-ascii?Q?ozKDmXeQ15TiFjo1c7P2wAJ8Qrrc0k1vPxUfEzhcSwG1DsraJPpEMglR7Js8?= =?us-ascii?Q?EqU64MyYs7XBxqNate9yBIIOFWbo/VlcS74XB1/E1yX/7Rs35kY5cwhTNmvQ?= =?us-ascii?Q?G10HHh7ZRztt/CWzxG8cx9clqYG/sHPbiciE0814VWxDB4GZNs/ncWwDJ9pJ?= =?us-ascii?Q?FdPIVKEEX42uYzFGaq+fNBWiWaOoAevfCFGEPa2UAyrm+1Op9SmoJ8fsx25O?= =?us-ascii?Q?co9qGcsaL1/M3dklT4Qo/FMvtBoeaPEvHIsTH0x/81s450oulpNzxbee/lag?= =?us-ascii?Q?SAtw/GNdV2LCcilV3OvSldFsd3gHXv31UPQqWdg3xGSeLB7gMOdinFFpoosa?= =?us-ascii?Q?hcAFVaZWbvYcOwkgd3pKGF58YrbzVJz0T6sSZbot7CCltz+yxBs1uN0LfTp7?= =?us-ascii?Q?tUbJpgPpnlVZRnyKqD0Aj12YTX256/2eRmGQ5q4qDbRbYy1YVWmpfY7cTpuB?= =?us-ascii?Q?EKwIoDmnp00CZvXw97vBFT4Q4psnsxCMhlDNR/Uvx9fvdGaHWw27JJgBPFMK?= =?us-ascii?Q?IOSEosLHMHOU9AN9TNvpsgd79FfjGnzne7VV5vtdlMiRt2En82RlcmRiDSG5?= =?us-ascii?Q?SIhj75onuMOAI7RIk85SwFfOKaN40SHPtkxI1kx+udY3IvSVQFkOxrLzBX5e?= =?us-ascii?Q?6/lK1EkLcXtX7XkdIfAAS6t9Gm6WtVnAldN3F9Zu4hQEGZjknj5Ld6o25SW8?= =?us-ascii?Q?ct6pJiwFPsfbJg45ItIBZY2FL/ewn9n3I6af93doF3iySRSR96/28OTe/ru3?= =?us-ascii?Q?j+XOyAVajzMLjIZZbYX26Jf/Xo6SFxSdiGIb48ipVjYoIQgTogbmVOeiKseo?= =?us-ascii?Q?CgUphi4wQhMQFaKpBLrTtj30bLh/mZAlVzA4S7Y6BG0zfdi8k9GbulOapOsJ?= =?us-ascii?Q?Q3xBYD9uVVuRsmNYJLebd/2p6TJ6+mSUJxWw5kXyCSt0D9rLUtDmHrtP33dQ?= =?us-ascii?Q?tGQ30EqIHq44i6mMU8bqzqU=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR84MB1992D82F14CAF0F3B89E52D4945B9SJ0PR84MB1992NAMP_" X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR84MB1992.NAMPRD84.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 1da79977-f04c-4374-ef5c-08d9dc9b76ea X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2022 05:04:12.1379 (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: uq2xk99SQRghcb8GftIILqX/bVckksChQTqv7T8bj4AMvjEYMex0qcvoHCDqBBqAwMGMMiYgnWwp7KJ3qIO8LQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR84MB1766 X-OriginatorOrg: hpe.com X-Proofpoint-ORIG-GUID: DYWSSgQYwBeBDU4w8twIHVwq1PcgXecp X-Proofpoint-GUID: DYWSSgQYwBeBDU4w8twIHVwq1PcgXecp X-Proofpoint-UnRewURL: 22 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-01-21_01,2022-01-20_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1011 phishscore=0 mlxlogscore=999 impostorscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 suspectscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2201210035 Archived-At: Subject: [bess] draft-saumvinayak-bess-all-df-bum : All PEs as DF: Distributed firewall-gateways across Overlay fabrics X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.29 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: Fri, 21 Jan 2022 05:04:22 -0000 --_000_SJ0PR84MB1992D82F14CAF0F3B89E52D4945B9SJ0PR84MB1992NAMP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [changing the subject line] Hello Bess Members, Chairs, We have covered a use-case which is not handled by any of the existing stan= dard documents in bess. The details of use-case are also discussed in the email chain below. Kindly provide you inputs or feedback on the proposed changes in the draft = https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/ Thanks Saumya. From: Dikshit, Saumya Sent: Tuesday, September 28, 2021 12:46 PM To: Dikshit, Saumya ; Joshi, Vinayak ; Rabadan, Jorge (Nokia - US/Mountain View) ; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-d= f-election-framework@ietf.org Cc: bess@ietf.org Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and = rfc Hi Jorge and Bess member Can you please go provide your inputs on the use-case and solution describe= d in https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/ Thanks Saumya. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Dikshit, Saumya Sent: Wednesday, September 15, 2021 4:44 PM To: Joshi, Vinayak >; R= abadan, Jorge (Nokia - US/Mountain View) >; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-d= f-election-framework@ietf.org Cc: bess@ietf.org Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc Hi Jorge and Members of Bess WG, Please let us know your views on https://datatracker.ietf.org/doc/draft-sau= mvinayak-bess-all-df-bum/. We have described the use-case this draft intends to solve, leveraging the = existing TLVs. Please include this as wg draft. Thanks Saumya. From: Dikshit, Saumya Sent: Friday, September 3, 2021 5:53 PM To: Joshi, Vinayak >; R= abadan, Jorge (Nokia - US/Mountain View) >; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-d= f-election-framework@ietf.org Cc: bess@ietf.org Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and = rfc Hi Jorge and others in Bess WG, We have come out with a new draft to which proposes a DF-election-mode wher= e in all the PEs intend to play the DF-role. Please go through the document and provide your comments: https://datatrack= er.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/ Thanks Saumya. From: Joshi, Vinayak Sent: Monday, August 23, 2021 5:22 PM To: Dikshit, Saumya >= ; Rabadan, Jorge (Nokia - US/Mountain View) >; draft-ietf-bess-evpn-fast-df-recovery@ietf.org<= mailto:draft-ietf-bess-evpn-fast-df-recovery@ietf.org>; draft-ietf-bess-evp= n-df-election-framework@ietf.org Cc: bess@ietf.org Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and = rfc +1 for standard compliance on the control plane to indicate [All Active + A= ll DF]. However, I think local bias is still needed to prevent some scenarios E.g.: 1) Host1 sends out ARP request for the Firewall. 2) It reaches VTEP-1 over VxLAN from Vtep_Host1. Two options at Vtep_1 a) Proprietary Option: VTEP 2 does not forward it over the VxLAN DCI = tunnel to Vtep2. I.e. VTEP 1 has to match the ARP for Firewall. b) Vtep_1 sends it over VTEP 2 on VxLAN DCI. VTEP 2's local bias proc= edure prevents it from getting into Firewall_2. This makes it easier to im= plement on Vtep_2. This is because Vtep_1 need not selectively block BUM ov= er the VxLAN tunnel (ARP from Host1 to resolve Host2's IP has to be forward= ed by Vtep_1 to Vtep_2). Regards, Vinayak From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Dikshit, Saumya Sent: Thursday, August 19, 2021 11:39 PM To: Rabadan, Jorge (Nokia - US/Mountain View) >; draft-ietf-bess-evpn-fast-df-recovery@ietf.or= g; draft-ietf-bess-e= vpn-df-election-framework@ietf.org Cc: bess@ietf.org Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc >>>> If you still want to control the unicast and BUM flows to one FW or th= e other depending on the leaf, you can still do it but that's implementatio= n specific since it relies on the route selection in vtep_host1 and vtep_ho= st2. +1 on the implementation part. It's good to have few proprietary solutions = in place. On another note, the best way forward could be the standards-support/enable= r for EVPN control-plane; like an option to allow more than one PEs (in active-active) to process the= BUM (arp request) traffic. Thanks Saumya. From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.rabadan@nokia= .com] Sent: Thursday, August 19, 2021 9:40 PM To: Dikshit, Saumya >= ; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-df-election-framework@ie= tf.org Cc: bess@ietf.org Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and = rfc I think you are saying that the FW can fail but it's interface to the leaf = is oper-up. I don't think the network can do anything to prevent traffic to= that interface then. And of course, in your new diagram local bias does not play. As I said, loc= al bias works in the previous diagram. Those new leaf nodes will do aliasing to the remote all-active ES. If you still want to control the unicast and BUM flows to one FW or the oth= er depending on the leaf, you can still do it but that's implementation spe= cific since it relies on the route selection in vtep_host1 and vtep_host2. Thx Jorge From: Dikshit, Saumya > Date: Thursday, August 19, 2021 at 8:49 AM To: Rabadan, Jorge (Nokia - US/Mountain View) >, draft-ietf-bess-evpn-fast-df-recovery@ietf.or= g >, 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 >>> the static mac is configured associated to an interface and conditional= ly active based on the oper-status of the interface Ack on that and that's pretty organic (tying it to the interface/AC state). But it may not solve the case where other hosts (other than firewall) are b= ehind the interface/AC (which is live and kicking). Need to track firewall state and trigger an administrative delete of the st= atic-MAC. >>> As I mentioned I should have added first_hop vtep/PE for Host1/2 as well, to reflect that reachability to firewall from the host(s) is across the Ove= rlay (EVPN fabric). I have redone the topology to show host1 and host2 behind first hop vteps "= Vtep_host1" and "Vtep_host2" respectively. In this updated topology local-bias will not come into play, as traffic fro= m host1/2 to firewall arrives over the evpn-fabric. . SITE-1 | SITE-2 ------------------------------------------------------ Host1 Host2 \ / Vtep_host1 Vtep_host2 | | | [ EVPN-fabric ] | | | Vtep1 =3D=3D =3D=3DWAN=3D=3D=3D=3D=3D=3D Vtep2 / \ Firewall _1 Firewall_2 (MAC_F) (MAC_F) From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.rabadan@nokia= .com] Sent: Thursday, August 19, 2021 9:04 PM To: Dikshit, Saumya >= ; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-df-election-framework@ie= tf.org Cc: bess@ietf.org Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and = rfc About this: >>>> the local static MAC disappears As I have observed in few implementations that static MACs are admin-config= ured (other than control-plane published with sticky-bit). So will need a admin intervention to clean them up. In the implementations I know, the static mac is configured associated to a= n interface and conditionally active based on the oper-status of the interf= ace. So no admin intervention. IMHO it does not make much sense to keep a s= tatic mac installed if the associated attachment circuit is down. Thanks. Jorge From: Dikshit, Saumya > Date: Thursday, August 19, 2021 at 8:28 AM To: Rabadan, Jorge (Nokia - US/Mountain View) >, draft-ietf-bess-evpn-fast-df-recovery@ietf.or= g >, 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 Thanks Again Rabadan and apology for the confusion. As I mentioned I should have added first_hop vtep/PE for Host1/2 as well, to reflect that reachability to firewall from the host(s) is across the Ove= rlay (EVPN fabric). I have redone the topology to show host1 and host2 behind first hop vteps "= Vtep_host1" and "Vtep_host2" respectively. In this updated topology local-bias will not come into play, as traffic fro= m host1/2 to firewall arrives over the evpn-fabric. . SITE-1 | SITE-2 ------------------------------------------------------ Host1 Host2 \ / Vtep_host1 Vtep_host2 | | | [ EVPN-fabric ] | | | Vtep1 =3D=3D =3D=3DWAN=3D=3D=3D=3D=3D=3D Vtep2 / \ Firewall _1 Firewall_2 (MAC_F) (MAC_F) >>>> the local static MAC disappears As I have observed in few implementations that static MACs are admin-config= ured (other than control-plane published with sticky-bit). So will need a admin intervention to clean them up. Thanks Saumya. From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.rabadan@nokia= .com] Sent: Thursday, August 19, 2021 8:35 PM To: Dikshit, Saumya >= ; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-df-election-framework@ie= tf.org Cc: bess@ietf.org Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recovery and = rfc For the first case, again, for the local hosts, local bias makes sure the A= RP requests go only to the local FW, i.e. host-1 ARP Requests goes to FW-1 = only, irrespective of the DF state. For the second case, I don't understand. When the local FW goes down, the l= ocal static MAC disappears and the one from the EVPN route should be instal= led. Thx Jorge From: Dikshit, Saumya > Date: Thursday, August 19, 2021 at 7:56 AM To: Rabadan, Jorge (Nokia - US/Mountain View) >, draft-ietf-bess-evpn-fast-df-recovery@ietf.or= g >, 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 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 cred= entials ? ARP request (MAC_F) should to sent to the local vtep, which shoul= d 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-dom= ain} in this scenario. >>>> In the implementations that I know, the local static MAC will be prefe= rred over the EVPN MAC/IP route with the static bit, hence again you will h= ave the behavior you want The static-mac approach has an issue, when the local firewall goes down, th= ere 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 >= ; draft-ietf-bess-evpn-fast-df-recovery@ietf.org; draft-ietf-bess-evpn-df-election-framework@ie= tf.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 sa= me 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-bi= as 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 t= hat a third leaf with a local host will do aliasing to both, but since it s= eems 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 a= s 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 t= he 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 b= ehavior you want.. and again, only in your example with two directly connec= ted leaf nodes. My 2 cents. Thx Jorge From: Dikshit, Saumya > Date: Thursday, August 19, 2021 at 4:51 AM To: draft-ietf-bess-evpn-fast-df-recovery@ietf.org >, draft-ietf-bes= s-evpn-df-election-framework@ietf.org > Cc: 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/ and 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 supp= orted with existing DF-election procedures. Scenario: All PE (Vtep1 and Vtep2 in below example) routers attached to same ES and b= oth act as DF. This is a typical case of distributed firewall (active/active) across fabri= cs (sites), Where in, the preferred firewall is the one local to the site, whereas, upo= n failure, packets need to be redirected (over WAN, via DCI/VPN) towards the remote si= te firewall. The firewall-device is connected to it's first-hop vtep over the same bridg= e-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 M= AC 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 Vt= ep1 or Vtep2 should be flooded to network towards the local firewall. SITE-1 | SITE-2 ------------------------------------------------------ Host1 | Host2 | | | Vtep1 =3D=3D =3D=3DWAN=3D=3D=3D=3D=3D=3D Vtep2 | | | Firewall _1 | Firewall_2 (MAC_F) (MAC_F) Please let me know if there is a way out (with out) using existing standard= s. Thanks Saumya. -----Original Message----- From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: Tuesday, July 6, 2021 8:31 PM To: i-d-announce@ietf.org Cc: 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 director= ies. 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/ There is also an htmlized version available at: 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=3Ddraft-ietf-bess-evpn-fast-df-recovery-0= 2 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess --_000_SJ0PR84MB1992D82F14CAF0F3B89E52D4945B9SJ0PR84MB1992NAMP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[changing the subject = line]

 

Hello Bess Members, Ch= airs,

 

We have covered a use-= case which is not handled by any of the existing standard documents in bess= .

The details of use-cas= e are also discussed in the email chain below.

 

Kindly provide you inp= uts or feedback on the proposed changes in the draft https://datatracker.ietf.org/doc/= draft-saumvinayak-bess-all-df-bum/  

 

Thanks

Saumya.

 

From: Dikshit, Saumya
Sent: Tuesday, September 28, 2021 12:46 PM
To: Dikshit, Saumya <saumya.dikshit@hpe.com>; Joshi, Vinayak &= lt;vinayak.joshi@hpe.com>; Rabadan, Jorge (Nokia - US/Mountain View) <= ;jorge.rabadan@nokia.com>; draft-ietf-bess-evpn-fast-df-recovery@ietf.or= g; 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-recove= ry and rfc

 

Hi Jorge and Bess memb= er

 

Can you please go prov= ide your inputs on the use-case and solution described in https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/  

 

Thanks

Saumya.

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Dikshit, Saumya
Sent: Wednesday, September 15, 2021 4:44 PM
To: Joshi, Vinayak <vina= yak.joshi@hpe.com>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; draft-iet= f-bess-evpn-fast-df-recovery@ietf.org; draf= t-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df= -recovery and rfc

 

Hi Jorge and Members o= f Bess WG,

 

Please let us know you= r views on https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/.

We have described the = use-case this draft intends to solve, leveraging the existing TLVs.

Please include this as= wg draft.

 

Thanks

Saumya.

 

From: Dikshit, Saumya
Sent: Friday, September 3, 2021 5:53 PM
To: Joshi, Vinayak <vina= yak.joshi@hpe.com>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; draft-iet= f-bess-evpn-fast-df-recovery@ietf.org; draf= t-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

 

Hi Jorge and others in= Bess WG,

 

We have come out with = a new draft to which proposes a DF-election-mode where in all the PEs inten= d to play the DF-role.

Please go through the = document and provide your comments: https://datatracker.ietf.org/doc/draft-saumvinayak-bess-all-df-bum/

 

Thanks

Saumya.

 

 

 

+1 for standard compli= ance on the control plane to indicate [All Active + All DF].

However, I think local= bias is still needed to prevent some scenarios

 

E.g.:

1)  Host1 sends o= ut ARP request for the Firewall.

2)  It reaches VT= EP-1 over VxLAN from Vtep_Host1. Two options at Vtep_1

a) &nbs= p;    Proprietary Op= tion:  VTEP 2 does not forward it over the VxLAN DCI tunnel to Vtep2. = I.e. VTEP 1 has to match the ARP for Firewall.

b) &nbs= p;     Vtep_1 s= ends it over VTEP 2 on VxLAN DCI. VTEP 2’s local bias procedure preve= nts it from getting into Firewall_2.  This makes it easier to implemen= t on Vtep_2. This is because Vtep_1 need not selectively block BUM over the VxLAN tunnel (ARP from Host1 to resolve Host2’s I= P has to be forwarded by Vtep_1 to Vtep_2).

 

Regards,

Vinayak

 

 

 

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Dikshit, Saumya
Sent: Thursday, August 19, 2021 11:39 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; draft-iet= f-bess-evpn-fast-df-recovery@ietf.org; draf= t-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: Re: [bess] Query to authors of draft-ietf-bess-evpn-fast-df= -recovery and rfc

 

 

>>>> If you still want to control the unicast an= d BUM flows to one FW or the other depending on the leaf, you can still do = it but that’s implementation specific since it relies on the route selection in vtep_host1 and vtep_host2.

+1 on the implementation part. It’s good to have few proprietary so= lutions in place.

On another note, the best way forward could be the standards-support/enab= ler for EVPN control-plane;

like an option to allow more than one PEs (in active-active) to process t= he BUM (arp request) traffic.

 

Thanks

Saumya.

 

From: Rabadan, Jorge (Nokia - US/Mountain Vie= w) [mailto:jorge.rabadan@nokia.c= om]
Sent: Thursday, August 19, 2021 9:40 PM
To: Dikshit, Saumya <sa= umya.dikshit@hpe.com>; draft-iet= f-bess-evpn-fast-df-recovery@ietf.org; draf= t-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

 

I think you are saying that the FW can fail but it’s interface to t= he leaf is oper-up. I don’t think the network can do anything to prev= ent traffic to that interface then.

 

And of course, in your new diagram local bias does not play. As I said, l= ocal bias works in the previous diagram.

Those new leaf nodes will do aliasing to the remote all-active ES.

 

If you still want to control the unicast and BUM flows to one FW or the o= ther depending on the leaf, you can still do it but that’s implementa= tion specific since it relies on the route selection in vtep_host1 and vtep_host2.

 

Thx

Jorge

 

 

From: Dikshit, Saumya <saumya.dikshit@hpe.com>
Date: Thursday, August 19, 2021 at 8:49 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>, draft-iet= f-bess-evpn-fast-df-recovery@ietf.org <draft-ietf-bess-evpn-fast-df-recovery@= ietf.org>, draf= t-ietf-bess-evpn-df-election-framework@ietf.org <draft-ietf-bess-evpn-df= -election-framework@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

>>> the static mac is configured associated to an interface and c= onditionally active based on the oper-status of the interface

Ack on that and that’s pretty organic (tying it to the interface= /AC state).

But it may not solve the case where other hosts (other than firewall) = are behind the interface/AC (which is live and kicking).

Need to track firewall state and trigger an administrative delete of t= he static-MAC.

 

 

>>> 

As I mentioned I should have added first_hop vtep/PE for Host1/2 as w= ell,

to reflect that reachability to firewall from the host(s) is across t= he Overlay (EVPN fabric).

 

I have redone the topology to show host1 and host2 behind first hop v= teps “Vtep_host1” and “Vtep_host2” respectively.

In this updated topology local-bias will not come into play, as traff= ic from host1/2 to firewall arrives over the evpn-fabric.=

.

 

    SITE-= 1            &n= bsp;    |        &nb= sp;            =     SITE-2
------------------------------------------------------   &nb= sp;            =             &nb= sp;  
      Host1      &nb= sp;            =             &nb= sp;          Host2<= /p>

    =       \       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; /

Vtep_host1  &n= bsp;            = ;             &= nbsp; Vtep_host2         =            
         |    &= nbsp;           &nbs= p;             =             &nb= sp;        |

    =      |       [ EVPN-fabri= c ]             = ;   |

         |    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         |
     Vtep1  =3D=3D =3D=3DWAN=3D=3D=3D=3D=3D=3D&nbs= p; Vtep2           &= nbsp;
       /      &= nbsp;           &nbs= p;             =              &n= bsp;       \     &nb= sp;            =  
Firewall _1           &nb= sp;            =       Firewall_2     &nbs= p;       
  (MAC_F)          &= nbsp;           &nbs= p;           (MAC_F)

 

 

 

From: Rabadan, Jor= ge (Nokia - US/Mountain View) [m= ailto:jorge.rabadan@nokia.com]
Sent: Thursday, August 19, 2021 9:04 PM
To: Dikshit, Saumya <sa= umya.dikshit@hpe.com>; draft-iet= f-bess-evpn-fast-df-recovery@ietf.org; draf= t-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

 

About this:

 

>>>> the local static MAC = disappears=

As I have observed in few implementations that= static MACs are admin-configured (other than control-plane published with = sticky-bit).

So will need a admin intervention to clean the= m up.

 

 

In the implementations I know, the static mac = is configured associated to an interface and conditionally active based on = the oper-status of the interface. So no admin intervention. IMHO it does not make much sense to keep a static mac = installed if the associated attachment circuit is down.

 

Thanks.

Jorge

 

From: Dikshit, Saumya <saumya.dikshit@hpe.com>
Date: Thursday, August 19, 2021 at 8:28 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>, draft-iet= f-bess-evpn-fast-df-recovery@ietf.org <draft-ietf-bess-evpn-fast-df-recovery@= ietf.org>, draf= t-ietf-bess-evpn-df-election-framework@ietf.org <draft-ietf-bess-evpn-df= -election-framework@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

Thanks Again Rabadan and apology for the confusion.

 

As I mentioned I should have added first_hop vtep/PE for Host1/2 as w= ell,

to reflect that reachability to firewall from the host(s) is across t= he Overlay (EVPN fabric).

 

I have redone the topology to show host1 and host2 behind first hop v= teps “Vtep_host1” and “Vtep_host2” respectively.

In this updated topology local-bias will not come into play, as traff= ic from host1/2 to firewall arrives over the evpn-fabric.=

.

 

    SITE-= 1            &n= bsp;    |        &nb= sp;            =     SITE-2
------------------------------------------------------   &nb= sp;            =             &nb= sp;  
      Host1      &nb= sp;            =             &nb= sp;          Host2<= /p>

    =       \       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; /

Vtep_host1  &n= bsp;            = ;             &= nbsp; Vtep_host2         =            
         |    &= nbsp;           &nbs= p;             =             &nb= sp;        |

    =      |       [ EVPN-fabri= c ]             = ;   |

         |    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         |
     Vtep1  =3D=3D =3D=3DWAN=3D=3D=3D=3D=3D=3D&nbs= p; Vtep2           &= nbsp;
       /      &= nbsp;           &nbs= p;             =              &n= bsp;       \     &nb= sp;            =  
Firewall _1           &nb= sp;            =       Firewall_2     &nbs= p;       
  (MAC_F)          &= nbsp;           &nbs= p;           (MAC_F)

 

>>>>= the local static MAC disappears

As I have observed in few implementations tha= t static MACs are admin-configured (other than control-plane published with= sticky-bit).

So will need a admin intervention to clean th= em up.

 

Thanks

Saumya.

 

From: Rabadan, Jo= rge (Nokia - US/Mountain View) [= mailto:jorge.rabadan@nokia.com]
Sent: Thursday, August 19, 2021 8:35 PM
To: Dikshit, Saumya <sa= umya.dikshit@hpe.com>; draft-iet= f-bess-evpn-fast-df-recovery@ietf.org; draf= t-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

 

For the first case, again, for the local host= s, local bias makes sure the ARP requests go only to the local FW, i.e. hos= t-1 ARP Requests goes to FW-1 only, irrespective of the DF state.

 

For the second case, I don’t understand= . When the local FW goes down, the local static MAC disappears and the one = from the EVPN route should be installed.

 

Thx

Jorge

 

From: Dikshit, Saumya <saumya.dikshit@hpe.com>
Date: Thursday, August 19, 2021 at 7:56 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>, draft-iet= f-bess-evpn-fast-df-recovery@ietf.org <draft-ietf-bess-evpn-fast-df-recovery@= ietf.org>, draf= t-ietf-bess-evpn-df-election-framework@ietf.org <draft-ietf-bess-evpn-df= -election-framework@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: RE: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

Thanks a lot for a promp= t reply Jorge.

 

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

 

>>>> FW1 and FW2 can be attached to = the same all-active ES

How to handle the broadc= ast packets like ARP request for the firewaill credentials ? ARP request (M= AC_F) should to sent to the local vtep, which should act as a DF.

The hairpinning of ARP r= equest 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 scena= rio.

 

>>>>= In the implementations that I know, the local static MAC will be preferred over the EVPN MAC/IP route wi= th 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, Jo= rge (Nokia - US/Mountain View) [= mailto:jorge.rabadan@nokia.com]
Sent: Thursday, August 19, 2021 7:47 PM
To: Dikshit, Saumya <sa= umya.dikshit@hpe.com>; draft-iet= f-bess-evpn-fast-df-recovery@ietf.org; draf= t-ietf-bess-evpn-df-election-framework@ietf.org
Cc: bess@ietf.org
Subject: Re: Query to authors of draft-ietf-bess-evpn-fast-df-recove= ry and rfc

 

Hi Saumya,

 

To be clear, your query has nothing to do wit= h the two documents you refer to. In fact I don’t see any issue relat= ed to multihoming.

Given that in your example host-1 and FW-1 ar= e 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 al= l-active ES, I assume local-bias behavior as in RFC8365 (seems you are usin= g 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 thir= d leaf with a local host will do aliasing to both, but since it seems you o= nly 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, he= nce forwarding comes down to the local selection on each node. In the imple= mentations that I know, the local static MAC will be preferred over the EVP= N 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>
Date: Thursday, August 19, 2021 at 4:51 AM
To: draft-ietf-bess-evpn-fast-df-recovery@ietf.org <draft-ietf-bess-evpn-fast-d= f-recovery@ietf.org>, draf= t-ietf-bess-evpn-df-election-framework@ietf.org <draft-ietf-bess-evpn-df= -election-framework@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>
Subject: Query to authors of draft-ietf-bess-evpn-fast-df-recovery a= nd rfc

Hello Authors of https://datatracker.ietf.org= /doc/rfc8584/ and https://datatracker.ietf.org/doc/draft-ietf-b= ess-evpn-fast-df-recovery

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

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

This is a typical case of distributed firewall (active/active) across fabri= cs (sites),
Where in, the preferred firewall is the one local to the site, whereas, upo= n failure,
packets need to be redirected (over WAN, via DCI/VPN) towards the remote si= te firewall.
The firewall-device is connected to it's first-hop vtep over the same bridg= e-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) preferab= ly.
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 M= AC 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 Vt= ep1 or Vtep2 should be flooded to network towards the local firewall.

    SITE-1        &n= bsp;        |    &nb= sp;            =         SITE-2
------------------------------------------------------   &nb= sp;            =             &nb= sp;  
      Host1      &nb= sp;        |    &nbs= p;            &= nbsp;      Host2
         |    &= nbsp;           &nbs= p;    |         = ;            &n= bsp;    |
     Vtep1  =3D=3D =3D=3DWAN=3D=3D=3D=3D=3D=3D&nbs= p; Vtep2           &= nbsp;
       |      &= nbsp;           &nbs= p;    |         = ;            &n= bsp;     |       &nb= sp;           
Firewall _1           |&n= bsp;            = ;      Firewall_2     &nb= sp;       
  (MAC_F)          &= nbsp;           &nbs= p;           (MAC_F)

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

Thanks
Saumya.

-----Original Message-----
From: BESS [mailto:bess-bounces@ie= tf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, July 6, 2021 8:31 PM
To: i-d-announce@ietf.org
Cc: 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 director= ies.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

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

Abstract:
   Ethernet Virtual Private Network (EVPN) solution provides Desi= gnated
   Forwarder election procedures for multi-homing Ethernet Segmen= ts.
   These procedures have been enhanced further by applying Highes= t
   Random Weight (HRW) Algorithm for Designated Forwarded electio= n in
   order to avoid unnecessary DF status changes upon a failure.&n= bsp; This
   draft improves these procedures by providing a fast Designated=
   Forwarder (DF) election upon recovery of the failed link or no= de
   associated with the multi-homing Ethernet Segment.  The s= olution is
   independent of number of EVIs associated with that Ethernet Se= gment
   and it is performed via a simple signaling between the recover= ed 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-reco= very/

There is also an htmlized version available at:
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=3Ddraft-ietf-bess-evpn-fast= -df-recovery-02


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


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org= /mailman/listinfo/bess

--_000_SJ0PR84MB1992D82F14CAF0F3B89E52D4945B9SJ0PR84MB1992NAMP_--