Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Fri, 26 January 2018 13:41 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 A6EF21200C5 for <bess@ietfa.amsl.com>; Fri, 26 Jan 2018 05:41:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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_H2=-0.001, SPF_PASS=-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 PhYnB3M_PwYW for <bess@ietfa.amsl.com>; Fri, 26 Jan 2018 05:40:57 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0129.outbound.protection.outlook.com [104.47.2.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA49D1200B9 for <bess@ietf.org>; Fri, 26 Jan 2018 05:40:56 -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=5A5go0advarUKYjvkPTQSs6kmpy7QcdqHp6wtIFFul4=; b=c6tK7o0nLT8w4MedW7w4n/TODjfBCS5LHqBdxnq0M7EKMFAsOn9Y04s1AuYjUgi+D5MgT87jUB06byxPPV8TiTrDntmyE4gylz7dYvEGnCxetx2wrFXkV1UufLVGnGf9SlxHfrVNEhXsqXiI6wya7eL8rAsujzTSK1SsjZivam0=
Received: from AM4PR07MB3409.eurprd07.prod.outlook.com (10.171.189.158) by AM4PR07MB1603.eurprd07.prod.outlook.com (10.166.132.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 26 Jan 2018 13:40:53 +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.0464.006; Fri, 26 Jan 2018 13:40:53 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>
CC: "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt
Thread-Index: AQHTlig3IVA98BXKB0KWfpq0Ut41/aOGOwMA
Date: Fri, 26 Jan 2018 13:40:53 +0000
Message-ID: <3E9BE272-566F-4E9E-B2A4-971692782BAB@nokia.com>
References: <CA+-tSzxrG+79GzoRZgVVsra4j1dg5mnUschi8ryP1THzmVG=Gw@mail.gmail.com>
In-Reply-To: <CA+-tSzxrG+79GzoRZgVVsra4j1dg5mnUschi8ryP1THzmVG=Gw@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
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [83.61.204.166]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB1603; 7:LNw3C0pWgY08egzc7rt0gYM7JDyhVXgjoRi/10WwPHXse4bIX5X37dTvT3C8efaveXivXbd76NP9yIZRMC5/NYibfRS2wkO2IZhncj2aCN5VJZCSaa8KAFBXCYbCIIX4h0YDl0YATNp5dcK+iyND2X6n6foSfMH1uviim6KMzCbejC3O3CZtqAe1sV6cH9tMrm/Ie2XBmFFFKpP1m5kdj2T872T4LVpzdUJjvHEhGKIlZXThCplyQ5AQDF6FNnIB
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(366004)(376002)(396003)(199004)(189003)(377424004)(51914003)(5660300001)(83506002)(478600001)(66066001)(6916009)(2950100002)(53386004)(14454004)(105586002)(3280700002)(966005)(83716003)(99286004)(6246003)(2906002)(97736004)(53936002)(6436002)(53946003)(6486002)(68736007)(6512007)(54896002)(6306002)(236005)(3846002)(6116002)(2171002)(86362001)(229853002)(316002)(58126008)(8676002)(25786009)(81156014)(4326008)(8936002)(81166006)(2900100001)(102836004)(36756003)(59450400001)(82746002)(53546011)(6506007)(186003)(5250100002)(606006)(26005)(3660700001)(76176011)(106356001)(7736002)(230783001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1603; 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: 56ea5512-f9f0-484a-ef12-08d564c26b8c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:AM4PR07MB1603;
x-ms-traffictypediagnostic: AM4PR07MB1603:
x-microsoft-antispam-prvs: <AM4PR07MB16038F757752EBE04D5B55F2F7E00@AM4PR07MB1603.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(15479808377102)(158342451672863)(120809045254105)(82608151540597)(85827821059158)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231023)(11241501184)(806099)(2400081)(944501161)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:AM4PR07MB1603; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB1603;
x-forefront-prvs: 05641FD966
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 4mfdzGAcOlRz9e90Ret+27IfH2mPcJlH2QByoZGoASDDcLsTf4j3A09ynwByL9xSIV0SZpVexrI8inlD0McDk0jA75ylFzLWIhqY9vfUmE9KpD0nkb03EvxwtNKhG9tH
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_3E9BE272566F4E9EB2A4971692782BABnokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 56ea5512-f9f0-484a-ef12-08d564c26b8c
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2018 13:40:53.2530 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1603
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/lSDNwr8uIOuHDcEPTvpnRKvT1Y4>
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: Fri, 26 Jan 2018 13:41:01 -0000
Annop, That’s fine. We can certainly add something like this: “Advertising all the DC MAC addresses in the control/management plane is usually the case when the NVEs reside in hypervisors. Refer to [EVPN-Overlays] section 7.” Thank you. Jorge From: <ghanwani@gmail.com> on behalf of Anoop Ghanwani <anoop@alumni.duke.edu> Date: Thursday, January 25, 2018 at 11:02 PM To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Cc: "bess@ietf.org" <bess@ietf.org> Subject: Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt Jorge, Thanks for the clarification. This makes sense. It may be worth adding a reference in the DCI draft to the section mentioned below. Anoop On Tue, Jan 23, 2018 at 11:34 PM, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>> wrote: Hi Anoop, There are (lots of) cases where the NVEs reside in hypervisors, hence NVE and its hosts/VMs are co-located in the same server, and MAC/IP routes for the hosts are advertised as they come up (since they are learned thru the management/control plane). Check [1] which is written based on that. In the evpn-overlay draft the NVEs are running EVPN. Even if your controller and data plane are separated, if you have multiple controllers they will run EVPN. Even if you have a single controller, it will run EVPN with the DC Gateway. So, I’m afraid I disagree with your statement that EVPN in the DC means MAC are learned from the data path. In my experience there are many deployed DCs where EVPN is used and MACs are learned in the control/mgmt. plane. Thank you. Jorge [1] https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-11#section-7 From: <ghanwani@gmail.com<mailto:ghanwani@gmail.com>> on behalf of Anoop Ghanwani <anoop@alumni.duke.edu<mailto:anoop@alumni.duke.edu>> Date: Wednesday, January 24, 2018 at 1:59 AM To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-overlay-06.txt Thanks Jorge. I'm struggling to understand the example. When would all the MACs be learned in control/management plane _and_ BGP EVPN be in use in the DC? In the normal case, if I'm using a controller in the DC with the NVEs in the servers, then there is no benefit to running EVPN in the DC. And if I'm running EVPN in the DC, the common case (only case currently deployed?) is where MACs are learned from the data path at the NVEs and imported into BGP for transport to other NVEs, so I wouldn't satisfy the requirement for all MACs being learned in the control/management plane. Is there a use case I am missing? Thanks, Anoop On Mon, Jan 22, 2018 at 10:54 PM, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>> wrote: 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<mailto:bess-bounces@ietf.org>> on behalf of Anoop Ghanwani <anoop@alumni.duke.edu<mailto:anoop@alumni.duke.edu>> Date: Tuesday, January 23, 2018 at 1:47 AM To: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto: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
- [bess] I-D Action: draft-ietf-bess-dci-evpn-overl… internet-drafts
- Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-o… Anoop Ghanwani
- Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-o… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-o… Anoop Ghanwani
- Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-o… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-o… Anoop Ghanwani
- Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-o… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] I-D Action: draft-ietf-bess-dci-evpn-o… Anoop Ghanwani