IETF Logo Mail Archive

Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Tue, 23 January 2018 06:54 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 40B6A12DA02 for <bess@ietfa.amsl.com>; Mon, 22 Jan 2018 22:54:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Level:
X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 xUhywQ2VtRwU for <bess@ietfa.amsl.com>; Mon, 22 Jan 2018 22:54:35 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00112.outbound.protection.outlook.com [40.107.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E408912DA04 for <bess@ietf.org>; Mon, 22 Jan 2018 22:54:34 -0800 (PST)
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; bh=PqHqFj68Olnv3KSxHiDTqHlEJykGzYpVhQhHEbs6Bag=; b=sig0O6PIIMxbjupW0p7dNVsDCiotMb5ai58r6j3Jqw6vXMuwFTmnJmjR2gYLJNIFLd8u5ocn9ho+1zxMemJVPVOc6OnAmOMuUqGcGQjT8mma6VKP0Ld6PnGhybQA8gCW1YeJWqJMd95JM9WBApDTxeJzT5O/O7rZ68EWkmFYMCQ=
Received: from AM4PR07MB3409.eurprd07.prod.outlook.com (10.171.189.158) by AM4PR07MB3330.eurprd07.prod.outlook.com (10.171.189.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Tue, 23 Jan 2018 06:54:32 +0000
Received: from AM4PR07MB3409.eurprd07.prod.outlook.com ([fe80::9029:c61f:9f4b:f39b]) by AM4PR07MB3409.eurprd07.prod.outlook.com ([fe80::9029:c61f:9f4b:f39b%13]) with mapi id 15.20.0444.013; Tue, 23 Jan 2018 06:54:31 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt
Thread-Index: AQHTk8W5tU21+OUzDUCTd7SgbMd2VaOAn8KAgAB3fYA=
Date: Tue, 23 Jan 2018 06:54:31 +0000
Message-ID: <4E3F711F-43BE-4265-8D02-1E06F365E68F@nokia.com>
References: <151665551888.6447.2066617935178716452@ietfa.amsl.com> <CA+-tSzw2AgwuR7brdQfbhmJ4Soq6OW3+NkO5UBSacF6jAHhP7Q@mail.gmail.com>
In-Reply-To: <CA+-tSzw2AgwuR7brdQfbhmJ4Soq6OW3+NkO5UBSacF6jAHhP7Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.9.0.180116
x-originating-ip: [135.245.20.28]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB3330; 7:wGA7eqqA0lfIkkf4vtOFb7lMmalDhlqOsc/33qnPiMgBi8aHAuxVLGu0r985ylShg9cNVEoO4BnIaQ+yMzjNqDcZN5pcZSvSP/tnESewu0qlRt0tgBRVtqamKmYgExD6YzagrVVw6wkketr0ZjG1ePHd6qcrLH0IEwT7IKSTh29oHy32kFKIccX/U52J7C2d25O+LOIsQy7kQE+LflffNhIFCiWDS6ZybO43z46QedSUYcQoYRgPaO7kGanACOHk
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(979002)(39860400002)(39380400002)(376002)(346002)(396003)(366004)(199004)(189003)(377424004)(3846002)(790700001)(6116002)(83506002)(2906002)(102836004)(26005)(76176011)(966005)(6246003)(478600001)(99286004)(53386004)(58126008)(8676002)(81156014)(8936002)(81166006)(110136005)(106356001)(68736007)(83716003)(316002)(25786009)(14454004)(53546011)(6506007)(230783001)(59450400001)(105586002)(9326002)(6346003)(7736002)(33656002)(6306002)(6512007)(97736004)(66066001)(5660300001)(6436002)(54896002)(6486002)(86362001)(36756003)(82746002)(2950100002)(229853002)(2900100001)(2501003)(5250100002)(236005)(53936002)(2171002)(3660700001)(606006)(3280700002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3330; H:AM4PR07MB3409.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: d2e2cb7e-0a34-4a08-2a9f-08d5622e27db
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534145)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM4PR07MB3330;
x-ms-traffictypediagnostic: AM4PR07MB3330:
x-microsoft-antispam-prvs: <AM4PR07MB33303EFE51A1E488D8924919F7E30@AM4PR07MB3330.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(15479808377102)(120809045254105)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231046)(11241501184)(806099)(2400081)(944501161)(93006095)(93001095)(10201501046)(6055026)(6041288)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:AM4PR07MB3330; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3330;
x-forefront-prvs: 05610E64EE
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-microsoft-antispam-message-info: rHUAvz12/2UcprfuoWG1GwYjZa7aP/1Z5ImtfUNb9cSXWFwVDlfYE2LWxQ40+chTtKkntn9IinLydt15zQXZganjxsTbsP4fZb53mWnu8Qf3c54pWmpz3oigR/+5UvyI
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_4E3F711F43BE42658D021E06F365E68Fnokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d2e2cb7e-0a34-4a08-2a9f-08d5622e27db
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 06:54:31.8391 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3330
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/yV9eVLdonei9Rw62jaKisYSu8sU>
Subject: Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
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, 23 Jan 2018 06:54:38 -0000

Hi Annop,

This paragraph intended to clarify that (in the same section):

This document proposes that local policy determines whether MAC
   addresses and/or the Unknown MAC route are advertised into a given
   DC. As an example, when all the DC MAC addresses are learned in the
   control/management plane, it may be appropriate to advertise only the
   Unknown MAC route.

Is it not enough?

Thank you.
Jorge

From: BESS <bess-bounces@ietf.org> on behalf of Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Tuesday, January 23, 2018 at 1:47 AM
To: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt

I have a question about the following paragraph in this draft:
>>>

   The solution specified in this document uses the 'Unknown MAC' route

   which is advertised into a given DC by each of the DC's GWs.  This

   route is a regular EVPN MAC/IP Advertisement route in which the MAC

   Address Length is set to 48, the MAC address is set to

   00:00:00:00:00:00, the IP length is set to 0, and the ESI field is

   set to the DC GW's I-ESI.
>>>
How does an ingress NVE tell the difference between an unknown MAC DA that is reachable (but perhaps aged out) within the current DC versus a MAC DA that is reachable in a remote DC?  In the first case, the correct action would be to replicate to all NVEs that participate in the incoming packet's VN; in the second case the correct action is to unicast it to the DC GW.  Is this assumption that the DC GW will then take over the job of replicating to the NVEs within the DC?

It would be good if some clarification can be added to the document.

Thanks,
Anoop

On Mon, Jan 22, 2018 at 1:11 PM, <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:

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           : Interconnect Solution for EVPN Overlay networks
        Authors         : Jorge Rabadan
                          Senthil Sathappan
                          Wim Henderickx
                          Ali Sajassi
                          John Drake
        Filename        : draft-ietf-bess-dci-evpn-overlay-06.txt
        Pages           : 27
        Date            : 2018-01-22

Abstract:
   This document describes how Network Virtualization Overlays (NVO) can
   be connected to a Wide Area Network (WAN) in order to extend the
   layer-2 connectivity required for some tenants. The solution analyzes
   the interaction between NVO networks running Ethernet Virtual Private
   Networks (EVPN) and other L2VPN technologies used in the WAN, such as
   Virtual Private LAN Services (VPLS), VPLS extensions for Provider
   Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how
   the existing Technical Specifications apply to the Interconnection
   and extends the EVPN procedures needed in some cases. In particular,
   this document describes how EVPN routes are processed on Gateways
   (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well
   as the Interconnect Ethernet Segment (I-ES) to provide multi-homing,
   and the use of the Unknown MAC route to avoid MAC scale issues on
   Data Center Network Virtualization Edge (NVE) devices.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-dci-evpn-overlay/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-06
https://datatracker.ietf.org/doc/html/draft-ietf-bess-dci-evpn-overlay-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-dci-evpn-overlay-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

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

v2.23.0 | Report a Bug | By Email