Re: Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04

Joe Clarke <jclarke@cisco.com> Mon, 05 November 2018 01:36 UTC

Return-Path: <jclarke@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5B4129619; Sun, 4 Nov 2018 17:36:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level:
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 2VwHYmzTUj-x; Sun, 4 Nov 2018 17:36:23 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B431276D0; Sun, 4 Nov 2018 17:36:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1579; q=dns/txt; s=iport; t=1541381783; x=1542591383; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=QqyZU0WSiTFjim0nE3Ri3vvn5Ovl5evHG/1NHXrJa7A=; b=D+RCGozX54Jjorv2npXx2R5O6xb6naj1EB0w32N6uLHCeGmZb6l7nW7K J+Q6imqDyrCpbaT7gS/XLEodQ4YxBJ//T29vUVMTc1q8ssNlV7N4Ao3QV BHhiyUGR+cmjfx/qdxQPgmQyriVxC9JVbZ9xGFZwK6GHKosVJNU5oSwDh I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B7AAAtnd9b/5NdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBZYIFaXyEHpQsgWAtmScNgXeCdQKDPiI4FgEDAQECAQECbSiFOwEFI1YQCxgCAiYCAlcGAQwIAQEXgwaCAqhvgS6KE4ELimsXgUE/gTiCa4gCglcCiQmGLjOEdIpUCZELBhiBVYd8JoZplBqDLIFaIYFVTSMVgyiQdiGOTwEB
X-IronPort-AV: E=Sophos;i="5.54,466,1534809600"; d="scan'208";a="474040413"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 01:36:22 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTP id wA51aE0q023385; Mon, 5 Nov 2018 01:36:17 GMT
Subject: Re: Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.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>
References: <153563466646.3197.17486989329935846815@ietfa.amsl.com> <3E7915CC-296B-49F6-B25F-23713589BCA4@nokia.com>
From: Joe Clarke <jclarke@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: <ae4da85f-c9ea-26a8-0fe9-bb5a46aa6974@cisco.com>
Date: Sun, 04 Nov 2018 20:36:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <3E7915CC-296B-49F6-B25F-23713589BCA4@nokia.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/3GnqWfGjFbUH8V1f-g0ZA3ER0-M>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 01:36:25 -0000

On 11/4/18 18:45, Rabadan, Jorge (Nokia - US/Mountain View) wrote:
> [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." 
> --------------

Thanks.  I re-read section 4.5, and I think this does indeed address my
comment.  The addition of this text is appreciated.

Joe