Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04
"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Sun, 04 November 2018 23:45 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 07C2A130DE8; Sun, 4 Nov 2018 15:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level:
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 6niW3wSMAt7i; Sun, 4 Nov 2018 15:45:44 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00109.outbound.protection.outlook.com [40.107.0.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 083E61293FB; Sun, 4 Nov 2018 15:45:40 -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:X-MS-Exchange-SenderADCheck; bh=lnfW9Ko9Cc/Hq0dUGIDTt7ubu1PmCPefl3LOZnfQgNk=; b=r8czs/XNF+OhIJ3pQHRVX+bRzcFdGBGXuPohdJ6dQdQGF0DgLaOz4iOVYl5MLMzGOhuaqhG6AbwkRPWGheSPkuRnT0exOaVof/txn0sRSOcWiuKo1rZEz+EB9XX3rW1LlvrXb5pe61shssN4gby25DFIVkUadnQP9vpvvS99s/8=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB4948.eurprd07.prod.outlook.com (20.178.19.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.7; Sun, 4 Nov 2018 23:45:38 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::6996:3137:3456:ae8]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::6996:3137:3456:ae8%5]) with mapi id 15.20.1294.032; Sun, 4 Nov 2018 23:45:38 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Joe Clarke <jclarke@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org" <draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04
Thread-Index: AQHUQGLuV378Xs5kjkel2yDzMRdsIKUxrfUA
Date: Sun, 04 Nov 2018 23:45:37 +0000
Message-ID: <3E7915CC-296B-49F6-B25F-23713589BCA4@nokia.com>
References: <153563466646.3197.17486989329935846815@ietfa.amsl.com>
In-Reply-To: <153563466646.3197.17486989329935846815@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.12.0.181014
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [210.160.37.27]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4948; 6:ZdE0vhglI55OB0C6JE9KDZsJVS0159vIf3KF2bimtmdBjVahH8meQQnHbilupw3o2BkkpPmFX03CsqSi9kH16Tu4juil7btLn1Kdn7WVLNfei8xDiSrIOS262fc4MmY4MCsCQAA4DsXvRMDtN5dkqxG2buyVGJqnb/fSbi30yY6TGf5KoIsYzBRTnB+DidTqcSToSspitU0mJEKAtv7CnqDAn5jkS6TFzh4n6jwYanmBVHwzdE50Dw+i9Bki82ftHshsVxJit2k8I6dn5r1W5MA2MuLY6Tnap5hmDiP02YGMpVdPX+8TM24O6BTBYAfW6rZZ2gdDIdOyuZ6GJO021T7MfXNyydZwqy58JdpU2Cu84TJmtL4UJJnDDw6aRhmxlPzxLEIia9qK6dTUtMs03S+CcEChdEePK9XHeHrdoIAcP+owgV2pY1dontS6gI90mOy4oVpH0MDM3+wWFg8huA==; 5:n82v9T/pLFcdyMM31Y+A5nj7GZKdFspEVPR20Tb/OLY1+kBZKz1yl2n27MZor9ZuBlmwyq1SLCY3mFvu1nFX1m6WXh9nb3dJjerZxTySz3MBRwQeW8GO7OnTWQvfwEojEE7fL4I/7audHV+pDjzwF9LBYNxwUkbJ8jq6VLhfqNE=; 7:N5VuuhMlLPVu988OEQJZZ54gVx9dmjBVnAO1yPNneH9778bfZ476T/nFDZMcSwT4MiWE5BTk2GWw1G3dykZhAjqbHEkOaKZe4WcYf2vMXwJdjBUzY4V8o23YuBRqrARPnvITBocVu9813609DpPG4A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 649f30fb-edda-4988-8440-08d642af9f72
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB4948;
x-ms-traffictypediagnostic: AM0PR07MB4948:
x-microsoft-antispam-prvs: <AM0PR07MB49483B8783C801ECB818EFDBF7C90@AM0PR07MB4948.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(269456686620040)(192374486261705)(95692535739014)(195916259791689)(109105607167333)(82608151540597)(18271650672692)(161740460382875)(97927398514766)(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4948; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4948;
x-forefront-prvs: 084674B2CF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(136003)(39860400002)(189003)(199004)(13464003)(6436002)(3846002)(6486002)(6116002)(4326008)(86362001)(6506007)(53546011)(14444005)(256004)(102836004)(6246003)(11346002)(99286004)(2616005)(446003)(66066001)(6512007)(486006)(316002)(476003)(5660300001)(76176011)(8936002)(54906003)(110136005)(2501003)(106356001)(36756003)(68736007)(105586002)(2906002)(81156014)(25786009)(8676002)(97736004)(14454004)(186003)(81166006)(478600001)(305945005)(26005)(53936002)(2900100001)(561944003)(33656002)(71190400001)(71200400001)(82746002)(229853002)(7736002)(83716004)(58126008); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4948; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: W4qN82qEToxItQ1l1ZE+yvkIB1uAAfFvAmOxwhS5hJBc90ODfAZ0tUiolrXoBxuafYxgA2W5sL1Iz/PzCbta97d/rl29ooVdFxEGKLUK6LZhUsj014l4TpXKVMFxe6wzT43lPOGZAm6WYbT2mkttDbp/JPP49gvzFRVNzYuc1IZhAIqhy9E8BfT94cnAolaE0rYTOB/Z6816o9itqgwSGitZL07T90gdoIcSklnSyk9CbeenjbRylgIhqJMMuuBixAqoadrimuQbeK40F+vcrmvMVsSEgTwP8wnt9Ji0wTBd/XyYXw0Frtx/J/jEgjwzLgb0DtiqYf7NckuCKYAt+B9p9PXO1LnED6kXfn1M/1E=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <38073982EC52CF4ABDF2F99E3E3674C5@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 649f30fb-edda-4988-8440-08d642af9f72
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2018 23:45:38.0395 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4948
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/D9W1aEP9PnFki8tt_nVIXFNqYyQ>
Subject: Re: [bess] Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04
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: Sun, 04 Nov 2018 23:45:47 -0000
Hi Joe, My apologies for the delay. Thank you very much for the very useful review. We took all your comments and made the corresponding changes in the new version. Please see more in-line with [JORGE] along with your comments. Thanks. Jorge -----Original Message----- From: Joe Clarke <jclarke@cisco.com> Date: Thursday, August 30, 2018 at 6:11 AM To: "ops-dir@ietf.org" <ops-dir@ietf.org> Cc: "draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org" <draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "bess@ietf.org" <bess@ietf.org> Subject: Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04 Resent-From: <alias-bounces@ietf.org> Resent-To: <jorge.rabadan@nokia.com>, <senthil.sathappan@nokia.com>, <kiran.nagaraj@nokia.com>, <wim.henderickx@nokia.com>, <greg.hankins@nokia.com>, <thomas.king@de-cix.net>, <daniel.melzer@de-cix.net>, <nordmark@sonic.net>, <matthew.bocci@nokia.com>, <stephane.litkowski@orange.com>, <mankamis@cisco.com>, <martin.vigoureux@nokia.com>, <db3546@att.com>, <aretana.ietf@gmail.com>, Matthew Bocci <matthew.bocci@nokia.com> Resent-Date: Thursday, August 30, 2018 at 6:11 AM Reviewer: Joe Clarke Review result: Has Issues I have been assigned to do an OPS DIR review of draft-ietf-bess-proxy-arp-nd. This document describes how the proxy ARP/ND functions of EVPN can be used to mitigate the impact of address resolution in large broadcast domains. While the text does support the abstract and describes how such proxy functions can help prevent flooding of broadcast traffic into the EVPNs, I found something noticeably missing from an operational point of view. This was especially apparent since the concept of an ARP-Sponge was also discussed. That is, one of the big operational headaches of a large broadcast domain is with negative ARP/ND (especially ARP). We actually see this in the IETF conference networks due to internet backscatter (we might be considered a DC in this regard). While the proxy functions can mitigate the positive address resolution, they will not help with negative caching. I feel that should be discussed, at least in the security recommendations, assuming there is not a proposal for adding capabilities to the EVPN proxy functions to further mitigate this. [JORGE] not sure what you mean by "negative caching". If you refer to the ability of certain routers/servers to inject dummy MACs into the ARP caches so that hosts stop ARPing for absent IPs, the solution actually may help, since there is an option to suppress unknown ARP-Requests/NS flooding explained in Section 4.5. Should you choose to enable this option on the Proxy-ARP/ND functions of the PEs, you no longer flood unknown ARP-Requests, and therefore there is no longer need to inject those dummy MAC addresses to stop the flooding. A host may keep ARP'ing for an absent host, but at least those messages won't bother the entire BD. I added this text in the security section: -------------- "The procedures in this document reduce the amount of ARP/ND message flooding, which in itself provides a protection to "slow path" software processors of routers and Tenant Systems in large BDs. The ARP/ND requests that are replied by the Proxy-ARP/ND function (hence not flooded) are normally targeted to existing hosts in the BD. ARP/ND requests targeted to absent hosts are still normally flooded, however the suppression of Unknown ARP-Requests and NS messages described in Section 4.5. can provide an additional level of security against ARP-Requests/NS messages issued to non-existing hosts." -------------- An overall nit is that you seem to mix capitalization of various terms like Ethernet, Proxy-ARP, Layer-2, etc. It would be good to normalize these for easier reading. [JORGE] done in the posted revision. Thanks. Other comments and nits on a per-section basis are found below. Section 2.1: In general, I found this section lacking when compared with the IXP section below it. You describe that large DCs may have a problem with broadcasts, but that is a known quantity. What I was expecting is to see more on how this document is applicable to that scenario like you did with the subsequent IXP section. [JORGE] ok, I added a bit more text in Section 2.1. === Section 4 "When CE3 sends an ARP Request asking for IP1..." Technically, CE3 is asking for the MAC address of IP1. [JORGE] true. Fixed, thx. === Section 4.2 s/potential Layer-2 switches seating/potential Layer-2 switches sitting/ [JORGE] done, thx. === Section 4.4 You say that a dynamic Proxy-ARP/ND entry SHOULD be flushed. It MUST be flushed if the age-time expires. I think this should be restated applying the SHOULD to whether or not an age-time is implemented. IMHO, if an age-time is implemented, keeping an entry in the table after it has aged out is incorrect behavior. An implementation MUST NOT do that. [JORGE] Agreed. Changed to "MUST be flushed". === Section 6.5 LAG is not listed in your glossary of abbreviations. [JORGE] added, thx. === Section 7 Typically the conventions section is located at the top of a document, after the abstract. [JORGE] changed, thank you.
- [bess] Opsdir last call review of draft-ietf-bess… Joe Clarke
- Re: [bess] Opsdir last call review of draft-ietf-… Rabadan, Jorge (Nokia - US/Mountain View)
- Re: [bess] Opsdir last call review of draft-ietf-… Joe Clarke