[bess] Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04
Joe Clarke <email@example.com> Thu, 30 August 2018 13:11 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C10A130EF4; Thu, 30 Aug 2018 06:11:06 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Joe Clarke <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Date: Thu, 30 Aug 2018 06:11:06 -0700
Subject: [bess] Opsdir last call review of draft-ietf-bess-evpn-proxy-arp-nd-04
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 13:11:07 -0000
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. 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. 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. === Section 4 "When CE3 sends an ARP Request asking for IP1..." Technically, CE3 is asking for the MAC address of IP1. === Section 4.2 s/potential Layer-2 switches seating/potential Layer-2 switches sitting/ === 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. === Section 6.5 LAG is not listed in your glossary of abbreviations. === Section 7 Typically the conventions section is located at the top of a document, after the abstract.
- [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