Re: [bess] [**EXTERNAL**] Re: EVPN VPWS BDF forwarding behavior at MH site

"Shah, Himanshu" <hshah@ciena.com> Tue, 13 August 2019 01:24 UTC

Return-Path: <prvs=71281de025=hshah@ciena.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 9E5A9120025 for <bess@ietfa.amsl.com>; Mon, 12 Aug 2019 18:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ciena.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 mVGxM9iX342x for <bess@ietfa.amsl.com>; Mon, 12 Aug 2019 18:24:14 -0700 (PDT)
Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (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 B5F1212002E for <bess@ietf.org>; Mon, 12 Aug 2019 18:24:13 -0700 (PDT)
Received: from pps.filterd (m0174892.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x7D1JWHl009561; Mon, 12 Aug 2019 21:24:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=06252019; bh=LhruSimnrnBaKMvFWAOTcqc38vtfIxfb0mrVocgdnZI=; b=awnGqsqioJtb1rp5WSNNbSzqVhkQliBRpYj376OCqCWQ0M1DADTx13pzOec1pOcNbWHB 70xtqGCQwL+tAD701h1V8togjiyE0IQuCKOeQ0gerrAaM9dZiI+wlloc7sx5Xv2yctDJ nF3usqVooGANp4cKfuFPuxjevSslHyxCCXyCX6LtdGQD9janHpMQgG8xqjitD4OlS5Or iUvSQlNlv6Y9xe7RMa3NEiCHx6Mo+9VJFsGgQTQR1GP9CiKJLDAssMZdRQh0yiHrXAzn WJ9vzvEpCgVXk5c/nor/i3JWen7Fpfp6/51hdrUuJrPmaaB9kAVMIIFFWdepwj0CwqsB OA==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2055.outbound.protection.outlook.com [104.47.38.55]) by mx0a-00103a01.pphosted.com with ESMTP id 2ubf9xgs3j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Aug 2019 21:24:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ti6wz/NBw4RDwhywoOBIAMQ3j7AioVKwGC4cLwCS4neglw4PzlvSnaz47ORJeK57qr5cOl58riDH/k2dZtPAWRrkGmRID3Dg4ZMQLZG6lsxMxZ29EXi+tbEUyDM1H+vnrjl7AKJLe7T/P8bezJiP6UZbrPT7QRQIrXVc+MjrtFcIpHoWNfHgM+YKMUhQbg3xLLJip45WDTMDuZHmnwUNH5nPCY6CXDiNACpqsM3iDcHHpYpPsZZr96HJppjYcOXsNeviK4P+r2NYmylSvq94G41aUptsCiqxnOeQaNWjUpl8Ic9cyTeMiEzhyGlFzmOgaQDwoFQ5MW6wPHoPI0dO8A==
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=LhruSimnrnBaKMvFWAOTcqc38vtfIxfb0mrVocgdnZI=; b=JHU0Z/rPuVBNyX7YI7lFhaD3fTV5diDGDO4MlzdzgWOhdIooMWwmtE3afwa+zPaS55YpiZ/G+eoBMFzle2Nvpz5zPlGzs1yBJgBwHvV7MsbQ6+ToED8qNX/ewBMQAPrcH+GYTenJ5gyyv2WADz0Q6+bkz1IJvYIviviTQ/dYwlhkIJLoLQ1dEakkWHIcdDBEafs9YKhzohLYJv3kRKC1OetiB4QxI+uiBmEd4epEm8nmrtYa2TSTjNLhbnjOkBagdJeW7GIFak0C29KlOp8TE4WQln07LIewKzBDIG2ailCSLGKVRPDRJ4ix1t0t7DAwFe+LB1lD/YtOTwBwKDgZzA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ciena.com; dmarc=pass action=none header.from=ciena.com; dkim=pass header.d=ciena.com; arc=none
Received: from BN8PR04MB6082.namprd04.prod.outlook.com (20.178.214.146) by BN8PR04MB5652.namprd04.prod.outlook.com (20.179.73.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Tue, 13 Aug 2019 01:24:06 +0000
Received: from BN8PR04MB6082.namprd04.prod.outlook.com ([fe80::b1a3:6f15:513a:2c1]) by BN8PR04MB6082.namprd04.prod.outlook.com ([fe80::b1a3:6f15:513a:2c1%5]) with mapi id 15.20.2157.020; Tue, 13 Aug 2019 01:24:06 +0000
From: "Shah, Himanshu" <hshah@ciena.com>
To: gangadhara reddy chavva <meetgangadhara@gmail.com>, "UTTARO, JAMES" <ju1738@att.com>
CC: "Thirumavalavan Periyannan (thiperiy)" <thiperiy@cisco.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [**EXTERNAL**] Re: [bess] EVPN VPWS BDF forwarding behavior at MH site
Thread-Index: AQHVUVgestCCGau5p0C6IJruMst2ZKb3hciAgABOGAA=
Date: Tue, 13 Aug 2019 01:24:06 +0000
Message-ID: <BF56C613-95CE-47AD-B517-961BDD7780D9@ciena.com>
References: <CAAG_SC_gizf5nRVGOL1XJ4nSHg_7RwP92wcgjqi9MCTMMiUA7A@mail.gmail.com> <3A8DD12F-E9CF-4B91-8B28-05344A82E752@cisco.com> <CAAG_SC8HrpfcvNM-jpbPb2TYsgUvuyc=9FboQJ8MsE7tVVQihg@mail.gmail.com> <B17A6910EEDD1F45980687268941550F4D898198@MISOUT7MSGUSRCD.ITServices.sbc.com> <CAAG_SC92AeYfdqt=FQMMHK0_W-2L6e0A5JNErBmd6EdzJgy4Lg@mail.gmail.com>
In-Reply-To: <CAAG_SC92AeYfdqt=FQMMHK0_W-2L6e0A5JNErBmd6EdzJgy4Lg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1a.0.190609
x-originating-ip: [165.225.38.253]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dcaa521b-b10b-4a3a-d5fd-08d71f8cef76
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7167020)(7193020); SRVR:BN8PR04MB5652;
x-ms-traffictypediagnostic: BN8PR04MB5652:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BN8PR04MB56524FE13128D3C59F8D14E0AFD20@BN8PR04MB5652.namprd04.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01283822F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(39860400002)(376002)(346002)(189003)(199004)(53754006)(6486002)(486006)(561944003)(5660300002)(478600001)(53546011)(53936002)(55236004)(256004)(8676002)(33656002)(6506007)(229853002)(446003)(11346002)(2906002)(476003)(36756003)(2616005)(236005)(14444005)(71190400001)(71200400001)(606006)(6436002)(966005)(316002)(66066001)(6116002)(25786009)(86362001)(3846002)(64756008)(4326008)(66556008)(66446008)(102836004)(54896002)(66476007)(14454004)(6512007)(6306002)(76116006)(91956017)(99286004)(58126008)(6246003)(186003)(81166006)(8936002)(66946007)(7736002)(81156014)(54906003)(110136005)(26005)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR04MB5652; H:BN8PR04MB6082.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DluWaLLSLiRzsbo9fcX7K/taX+CHGLEuGcTloaRleNpFhdBHxJu9yCZj1VkeyshWnveGzIZmmKetXOb7Bj+azOJJDyGq+f33s+OjVPgzjNKmQxMSfWl1wuHSgxz7VHjlOFZF6/Mzq6HdfygD7SPMGi3EvLH8L9CD6G/INUrca8KKOPiLblzN9ypx296xzewHmLVOqE4+nYIcwiFWRUVUqWzh3LzAVaHFcMsheKMrwxre61RcuADn/6sFp/ppll80TASzTqCoWYv4qZDO5l7u8mf6RKKJvspqMeAJJApow/N52nVyOIiAxmXx3pZ1KgAKFzNPku0g7Pb2cwNJLkx537d6tsBQR29rjXf45+UW0avPAaBI2HC2XTKalSVNg4K4uMFDqJJBs+UdjAkFlmcI+u777gMdVkcbeAsMox+O+O4=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BF56C61395CE47ADB517961BDD7780D9cienacom_"
MIME-Version: 1.0
X-OriginatorOrg: ciena.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dcaa521b-b10b-4a3a-d5fd-08d71f8cef76
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 01:24:06.8150 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wAlsyzjv2uFWoydvRKRxyNlOoVlJwgDt0cBBeafAaOPZwo1yMMlpCZ88zgqi46Ce
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR04MB5652
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-08-12_09:2019-08-09,2019-08-12 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 spamscore=0 mlxscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 impostorscore=0 phishscore=0 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1908130011
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/s8z8vM6n5wnyLjyN2igv_3joJVY>
Subject: Re: [bess] [**EXTERNAL**] Re: EVPN VPWS BDF forwarding behavior at MH site
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: Tue, 13 Aug 2019 01:24:18 -0000

Just so that we all are on same page –

You have PE1 & PE2 as MH peers with PE1 as primary while PE2 as backup for certain EVI with PE3 as remote PE.
The problem you describe is, what if PE3 quickly changes over the path to PE2, and PE2 has not yet changed to primary role.
The solution you propose is – Let PE2 be unidirectionally active (remote->local) even when in standby role.
This will prevent one way traffic loss. However, local to remote is delayed until PE2 becomes primary via EVPN means (DF election, etc)

You mentioned MH-IPBFD between PE1<->PE3 and BGP-PIC to activate path between PE3<->PE2.

So followings need to be considered –

  *   PE1 and PE3 path is broken : meaning PE1 is alive but MH-IPBFD triggers
     *   If path between PE1 and PE2 is not broken, withdraw of ES route by PE1 would cause DF reelection trigger,

may/may not be within BGP-PIC based resumption

  *   PE1 has died – MH-IPBFD triggers
     *   If PE1 & PE2 also had MH-IPBFD for liveliness check then PE2 can react faster
     *   The danger with this scheme is that if path between PE1 and PE2 is broken but from both to PE3 is fine,

PE2 will elect itself as primary which results in both being active, EAD/EVI will conflict with EAD/ES which is still single-active.

     *   There may be other complication on CE side with LACP becoming active and CE doing load-balancing.

All in all – Optimizing packet loss for one way communication may not necessarily be beneficial (if TCP, missing ACK will cause re-send anyway).
What would be important is to avoid sustained service blackouts.

Thanks,
Himanshu

From: BESS <bess-bounces@ietf.org> on behalf of gangadhara reddy chavva <meetgangadhara@gmail.com>
Date: Monday, August 12, 2019 at 5:53 PM
To: "UTTARO, JAMES" <ju1738@att.com>
Cc: "Thirumavalavan Periyannan (thiperiy)" <thiperiy@cisco.com>om>, "bess@ietf.org" <bess@ietf.org>
Subject: [**EXTERNAL**] Re: [bess] EVPN VPWS BDF forwarding behavior at MH site

Yes, Jim Uttaro, it is related to FXC, please let me know your comments on the below proposal.

Regards,
Gangadhar

On Mon, Aug 12, 2019 at 6:45 PM UTTARO, JAMES <ju1738@att.com<mailto:ju1738@att.com>> wrote:
I assume this discussion applies to FXC ( Flexible Cross Connect )..

Thanks,
              Jim Uttaro

From: BESS <bess-bounces@ietf.org<mailto:bess-bounces@ietf.org>> On Behalf Of gangadhara reddy chavva
Sent: Saturday, August 10, 2019 7:29 AM
To: Thirumavalavan Periyannan (thiperiy) <thiperiy@cisco.com<mailto:thiperiy@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] EVPN VPWS BDF forwarding behavior at MH site

Hi Thiru,

here is the clarifications for your questions.

this is basically primary PE reach ability /  availability can be determined through BFD/Multihop BFD, in this case FRR switch can happen very quickly at the remote PE, control plane convergence later.

please see in line answers for the below questions:
for faster convergence if we can install the route such that BDF can allow the traffic from remote PE towards to multi homed segment, we can forward the traffic received from the remote PE.

Gangadhar >> this explains the route programming at multi homed site, if elected PE is BDF, program the label path, so that traffic received from remote PE will be send to multi homed CE.

at the same time we shouldn't allow the traffic from multi homed site this leads to duplicate traffic on the remote PE. to achieve this we should not program the path from multi home site towards remote PE until this PE elected as DF for that VPWS instance.

Gangadhar >> again this is at BDF, we shouldn't allow the traffic from multi homed site CE to remote PE, for this BDF should not program the path towards remote PE, so at BDF if there is any traffic from CE will be get  dropped at BDF.


I hope this will clarify your question.

Regards,
Gangadhar



On Sat, Aug 10, 2019 at 2:50 AM Thirumavalavan Periyannan (thiperiy) <thiperiy@cisco.com<mailto:thiperiy@cisco.com>> wrote:
Hello Gangadhara,

How remote PE detect the DF failure? It’s based on EVI/AD Withdraw message from DF PE if so then NDF PE also received this route and changed its DF status at the same time Remote PE changed its nexthop to NEW DF PE.

The below info is not clear, could you please help me to understand.

for faster convergence if we can install the route such that BDF can allow the traffic from remote PE towards to multi homed segment, we can forward the traffic received from the remote PE.

at the same time we shouldn't allow the traffic from multi homed site this leads to duplicate traffic on the remote PE. to achieve this we should not program the path from multi home site towards remote PE until this PE elected as DF for that VPWS instance.

Thanks,
Thiru

On 09-Aug-2019, at 19:02, gangadhara reddy chavva <meetgangadhara@gmail.com<mailto:meetgangadhara@gmail.com>> wrote:
HI All,

i have one question on EVPN VPWS BDF forwarding behavior at MH site.
when PE is selected as BDF, it will communicate the EAD EVI route with B bit set to remote PE. so remote PE will install the FRR route with primary path towards DF PE and secondary path towards BDF.
when ever primary path get disconnected it will switch the path to secondary path quickly at remote PE. because of this data from the remote PE will reach to BDF very quickly, but if BDF is not programmed its path towards multi homed segment then traffic will be get dropped until control plane convergence and it will be elected as DF.

for faster convergence if we can install the route such that BDF can allow the traffic from remote PE towards to multi homed segment, we can forward the traffic received from the remote PE.

at the same time we shouldn't allow the traffic from multi homed site this leads to duplicate traffic on the remote PE. to achieve this we should not program the path from multi home site towards remote PE until this PE elected as DF for that VPWS instance.

can you please let me know if there are any problems with this kind of approach..

<image.png>

Regards,
Gangadhar






_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=dw_cbEJEFGb2ttG_aLztLllgQ6WbTf5f6YdWdNY3Sgo&s=VYEDWxQx9AA9mJMDxJ8_BoKV0xANI0ORk2zfcb3cfF4&e=>