Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Thu, 04 October 2018 20:00 UTC

Return-Path: <jorge.rabadan@nokia.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 24231128D68 for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 13:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.764
X-Spam-Level:
X-Spam-Status: No, score=-0.764 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 7pNKkqUjmncJ for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 13:00:55 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0105.outbound.protection.outlook.com [104.47.0.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5100130DE3 for <bess@ietf.org>; Thu, 4 Oct 2018 13:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mysxqsv4or+uLGYm2tUGbMEB+XJ4/6mBvA49V291rDk=; b=OdyI8ysf0aAJY5613EimPkW6r7tn8fOAzM6jO07crY2Qic/oDBaN3X9MYyJ30qiH1DdaSLTO9TEF2hLvVKzpLmpjWI2pBs7ivuuUEwvzxLDePxrD5vfyL+TrynM+t5kMqUPDuiEKePaRL2Q+Tx96NW+76U0AdqIoQM3G+67C1uA=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB3955.eurprd07.prod.outlook.com (52.134.82.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.15; Thu, 4 Oct 2018 20:00:50 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::6996:3137:3456:ae8]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::6996:3137:3456:ae8%4]) with mapi id 15.20.1207.024; Thu, 4 Oct 2018 20:00:49 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
CC: "jaikumar.somasundaram@ericsson.com" <jaikumar.somasundaram@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, "jiang.he@ericsson.com" <jiang.he@ericsson.com>, "p.muthu.arul.mozhi@ericsson.com" <p.muthu.arul.mozhi@ericsson.com>
Thread-Topic: [bess] EVPN MH: Backup node behavior in Primary Path Failure
Thread-Index: AQHUW7tPwY67GDKFZkSdu6BevJADsqUO0DWQgAAs0YD///JDgIAAWw6A///uagCAADLCAA==
Date: Thu, 04 Oct 2018 16:38:51 +0000
Message-ID: <9B51E983-4E46-4E7B-9F28-F161A6CB362F@nokia.com>
References: <067ED9A1-F8D0-4C53-97A0-3E6FA7E063EC@nokia.com> <VI1PR07MB4302D68B2828F10E49C834A486EA0@VI1PR07MB4302.eurprd07.prod.outlook.com> <D4979895-D9D9-434D-A247-62682E678853@nokia.com> <CAKz0y8zP+h+=tvEiiM=5MZxzdtk43_jOJ8BxtgENs5D-Orx98Q@mail.gmail.com> <19D6CCFE-183E-4BF7-A7D2-7D5F9DA96D7A@nokia.com> <CAKz0y8xzxNv2EBuCmUC2r5=tDozc1th41Ao0dbdVXcAbEQLJRw@mail.gmail.com>
In-Reply-To: <CAKz0y8xzxNv2EBuCmUC2r5=tDozc1th41Ao0dbdVXcAbEQLJRw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.11.0.180909
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [135.245.20.19]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB3955; 6:WqHKP/1RXisGluTDlMOHr6xD9Doq/yt1r1IXn/J7TDznQcu3enwRCplcy0qDF6tgm3Hl90zVvn+osd32clg8/yuvNKjRQcZF6DfUeSnTKqmqCGIu3Iu5Yc2nv1t58kDWfvyxFd4PmEoppJqtyqrfgIbiBd1PyQTeDAajX52yC5uGwiaf3Yvy7Cw2q3GrJPmFkroUopBcn53oAezDsjqaK2SFybTW63VAdA1XUTlNixXuHPpwiy5p/Epe216SlZpet1/DS9PzLpFqP4bBVEeUc7gt0s2Uw8KpuVmWBncI6w8fj0kQvaWNRyUc4BrRjIPT4/rQYCMh4d/+SC0lGpkLcZNoa1zMR/hJtevAZBJO+Y/1e/Gs83tKOCjuDg7SHZxBzYAqemrmmH1PMlSl/T3mpl7vRBLY0i6qdVqqndgUQYkWdjIB9w3rwjC1x66KFL6z4mfoPZR3p5zPjCUYg+y86w==; 5:mSJ0icRTcffWuLGS4ptofmT+GVZbWEeQMtnZesyEdIDNQShLqhlD2EYWnoo5yGnrf8HWg4Yldw5vpam5QBL3qp2KFwLjQr8hiKKDFPGbxz8TcR/9iMwp6IbOWabUQr7LspKAvN0hqjJTnyHr5b9KRQ3fMGa3RInja+J0asfP3R0=; 7:VxdTsK3laTld747IUBXT5BXYIjLyBKMv2DA+4Y3wMJHH8t8JOAzKgLZine/Wdun/OZ5Z7GUPWF2cVHPZo41UevkLFRAPLG4UhZ7NaF5I958wngMxukgeI0ZF3B4wBe8siqUy/Ob31hAHmkcr4e+nquCU1Byxj7zueyr6KDL/NYRUez0ql8KtThnh9TNZhqqBsV3Hsc2xyG4NN2X4Mcnn45Zk7Cqh+5RhwacDpOMTLNrI/OhYliYwI0vQh35U7S64
x-ms-office365-filtering-correlation-id: e8ae6e75-25dd-4f64-3b47-08d62a341497
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB3955;
x-ms-traffictypediagnostic: AM0PR07MB3955:
x-microsoft-antispam-prvs: <AM0PR07MB395537FCD352BBF172DB1794F7EA0@AM0PR07MB3955.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(85827821059158)(195916259791689)(109105607167333)(82608151540597)(37575265505322)(248295561703944)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231355)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(3002001)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:AM0PR07MB3955; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB3955;
x-forefront-prvs: 0815F8251E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(346002)(376002)(396003)(53754006)(53474002)(199004)(189003)(256004)(6916009)(66066001)(6116002)(97736004)(3846002)(486006)(33656002)(2906002)(2616005)(966005)(83716004)(606006)(476003)(446003)(5660300001)(71200400001)(76176011)(105586002)(186003)(6486002)(106356001)(14454004)(26005)(6506007)(5250100002)(6436002)(53546011)(2900100001)(71190400001)(229853002)(102836004)(11346002)(478600001)(81166006)(8676002)(99286004)(316002)(7736002)(25786009)(81156014)(236005)(6246003)(58126008)(14444005)(6666003)(82746002)(86362001)(6306002)(36756003)(4326008)(8936002)(68736007)(53936002)(54906003)(93886005)(54896002)(39060400002)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB3955; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: fPk6jEYu+RmC3Dr7+Eo5ikXD+1UJATce5KP32qVYUhf8/JUzHcO+VHbVjPelKNLkIb+2J5vgRZi0euX0YrSENIq19p3kjGQEVAg0ImMUudpUWlSqjAVZPkRDdGRlhgO9MhzBHoHpx4dM9rFlXDTM3courwJFNL/VUgLbfKq8J3BUPQ7gYO4nDRBep3OFRY8SrPwhkXxxWna103Etw7JrphFDpArcV/IOI50NY7AuKDRV9vWrT6Zq3r/lZSV7JEFQGpkg6j7pQ6PmVqhSzqDqaXSKc7WXCxNLpCvhDltV+cH4inuC6ARnEr9iaS3qI5VyMPiFebNapAgkFy2xcourIVKE9tDE/rNhZbxTjBMongksDRo2xNMANuazDxvqYK4XzKKQH8BXW5vipjNXxtgSJQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_9B51E9834E464E7B9F28F161A6CB362Fnokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e8ae6e75-25dd-4f64-3b47-08d62a341497
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2018 20:00:43.1310 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3955
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/ER3nbT2E8VDBIkAm-fSkQUR4RcA>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
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, 04 Oct 2018 20:00:58 -0000

Muthu,


From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Thursday, October 4, 2018 at 5:37 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: "jaikumar.somasundaram@ericsson.com" <jaikumar.somasundaram@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, "jiang.he@ericsson.com" <jiang.he@ericsson.com>, "p.muthu.arul.mozhi@ericsson.com" <p.muthu.arul.mozhi@ericsson.com>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks, Jorge. This is inline with my thinking. So, in single-active multihoming, once the primary is dead we don't need to wait for the DF election to happen for the backup (or some other PE in the ES) to become active and start forwarding traffic over the ES, instead it only requires the remote PEs and backup to realize that the primary is dead (thru' NH tracking / BFD) and start forwarding over the ES, right?
[JORGE] When the other PEs in the ES realize the DF is dead, they need to remove the dead PE from the candidate list and run DF Election. You may optimize things if you only have two PEs in the ES (such as skip the timer) but if you have more than 2 PEs in the ES, there is really no concept of backup PE in RFC7432, but simply the other PEs are non-DF. However, the concept of backup PE in an ES with more than two PEs is specified in RFC8214, where all the PEs in the ES not only elect a DF but also a backup DF, and signal this backup condition in the AD per-EVI routes. Note this is not there in RFC7432.

Regards,
Muthu

On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>> wrote:
Muthu,

About this:

Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would withdraw the routes if the primary PE / DF itself fails? Instead, the BGP session would timeout causing the primary PE's neighbors to flush out the A-D routes received from the primary PE, right? This can take several seconds, isn't it?

No, not in the implementations I know of. Next Hop tracking will immediately detect that the PE is not in the network anymore and the routes will be invalidated. You can also bootstrap the BGP sessions to BFD.
But that has nothing to do with EVPN!.. it’s regular BGP.

Thx
Jorge

From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com<mailto:muthu.arul@gmail.com>>
Date: Thursday, October 4, 2018 at 1:14 PM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>
Cc: "jaikumar.somasundaram@ericsson.com<mailto:jaikumar.somasundaram@ericsson.com>" <jaikumar.somasundaram@ericsson.com<mailto:jaikumar.somasundaram@ericsson.com>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, "jiang.he@ericsson.com<mailto:jiang.he@ericsson.com>" <jiang.he@ericsson.com<mailto:jiang.he@ericsson.com>>, "p.muthu.arul.mozhi@ericsson.com<mailto:p.muthu.arul.mozhi@ericsson.com>" <p.muthu.arul.mozhi@ericsson.com<mailto:p.muthu.arul.mozhi@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Please see inline..

On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>> wrote:
In-line.

Thx
Jorge

From: Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com<mailto:jaikumar.somasundaram@ericsson.com>>
Date: Thursday, October 4, 2018 at 11:28 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Cc: Jiang He <jiang.he@ericsson.com<mailto:jiang.he@ericsson.com>>, P Muthu Arul Mozhi <p.muthu.arul.mozhi@ericsson.com<mailto:p.muthu.arul.mozhi@ericsson.com>>
Subject: RE: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Thanks Jorge for the quick reply.
Please find further question below.

From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>
Sent: Thursday, October 4, 2018 1:52 PM
To: Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com<mailto:jaikumar.somasundaram@ericsson.com>>; bess@ietf.org<mailto:bess@ietf.org>
Cc: Jiang He <jiang.he@ericsson.com<mailto:jiang.he@ericsson.com>>; P Muthu Arul Mozhi <p.muthu.arul.mozhi@ericsson.com<mailto:p.muthu.arul.mozhi@ericsson.com>>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Hi,


Questions:
1.       Will the node in backup mode forward the packet to CE?

[JORGE] as soon as it becomes DF it can forward packets to the CE. The backup node will have to run DF election upon the ES route withdrawal from the primary. If AC-DF is enabled, it can also react to the withdrawal of AD routes from the primary PE.

[Jai] Does that mean if any packet comes to a node that is still in the backup mode will get dropped, before the new DF election is complete? Why cant this be used as FRR? Or what is the use case of having backup node(s)?

[JORGE2] when the primary node fails, ES and AD routes are withdrawn.
Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would withdraw the routes if the primary PE / DF itself fails? Instead, the BGP session would timeout causing the primary PE's neighbors to flush out the A-D routes received from the primary PE, right? This can take several seconds, isn't it?

Regards,
Muthu

The AD route withdrawal is an indication for remote nodes that they have to send traffic to the backup (for a given MAC) or to flush the MACs if there are more than 2 PEs in the ES. Around the same time or maybe earlier, the ES route withdrawal will make the backup PE take over as DF. So the overall convergence time will depend on how/when those two things happen in time. Only the DF PE can forward traffic. A non-DF can never forward traffic or there will be risk of duplicate packets.


2.       Will all the nodes in backup mode forward the packet before DF election?

[JORGE] Only the new DF can forward.



3. If they forward, how is duplicate packets handled, in this case?
[JORGE] see above.

My two cents..

Thanks.
Jorge



From: BESS <bess-bounces@ietf.org<mailto:bess-bounces@ietf.org>> on behalf of Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com<mailto:jaikumar.somasundaram@ericsson.com>>
Date: Thursday, October 4, 2018 at 10:03 AM
To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Cc: Jiang He <jiang.he@ericsson.com<mailto:jiang.he@ericsson.com>>, P Muthu Arul Mozhi <p.muthu.arul.mozhi@ericsson.com<mailto:p.muthu.arul.mozhi@ericsson.com>>
Subject: [bess] EVPN MH: Backup node behavior in Primary Path Failure


Hello Everyone,

Sorry if it is a duplicate. I repost this query as I did not receive any response yet.
(I was wondering if this mail already reached the group or not)


I have a question on Primary PE encountering a failure in EVPN multihoming

in single active mode.



RFC7432, section 14.1.1:

<snip>

   If there is more than one backup PE for a given ES, the remote PE

   MUST use the primary PE's withdrawal of its set of Ethernet A-D per

   ES routes as a trigger to start flooding traffic for the associated

   MAC addresses (as long as flooding of unknown unicast packets is

   administratively allowed), as it is not possible to select a single

   backup PE.

</snip>



Questions:

1. Will the node in backup mode forward the packet to CE?

2. Will all the nodes in backup mode forward the packet before DF election?

3. If they forward, how is duplicate packets handled, in this case?



Please help me anwere these questions.



Thanks & Regards

Jaikumar S


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