Jorge, Thanks, that should help. No need to change the text.
Regards, Vinayak From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com] Sent: Tuesday, September 28, 2021 11:25 AM To: Joshi, Vinayak <vinayak.jo...@hpe.com>; The IESG <i...@ietf.org>; draft-ietf-bess-evpn-proxy-arp...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com>; jeanmichel.com...@orange.com; Eric Vyncke (evyncke) <evyn...@cisco.com> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT) Hi Vinayak, In the document the reply sub-function section says that the PE SHOULD reply to DAD NS messages, but it is not a MUST. So if your implementation has a config knob to not reply DAD NS messages as an exception, it could still be compliant with the document. Thanks. Jorge From: Joshi, Vinayak <vinayak.jo...@hpe.com<mailto:vinayak.jo...@hpe.com>> Date: Tuesday, September 28, 2021 at 4:21 AM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org> <draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com> <jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com>>, Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT) Hi Jorge, Thank you for a detailed response. As you said this is a corner case - hence may be it can be left to implementation. That is, a PE can have a config knob to treat DAD NS as an exception and not respond to it. Regards, Vinayak From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:jorge.raba...@nokia.com] Sent: Monday, September 27, 2021 9:44 PM To: Joshi, Vinayak <vinayak.jo...@hpe.com<mailto:vinayak.jo...@hpe.com>>; The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>; jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com>; Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT) Hi Vinayak, Others can comment too, but these are my comments: - One of the main benefits of proxy-arp/nd is the reduction of flooding, and DAD is multicast traffic and it may be significant in an EVPN BD. So proxy-ND replying to DAD NS messages is still important IMO. - Although I guess the use-case you describe may be possible, one may wonder why the DHCPv6 server allocation strategy would allocate IP1 to MAC2, when it had just received a release for the IP from MAC1. And even without proxy-ND, it will take some time for the remote hosts to update their caches anyway, so it is not that the communication is uninterrupted if proxy-nd did not reply to DAD NS. - Also, the mechanisms in the document will update the proxy-ND entries as soon as possible, either due to CE1 acquiring a different IP and being learned or via the proxy-nd maintenance sub-function. - You mention GARPs for IPv4, there may also be unsolicited NA messages issued by CE1 in some cases, which would speed things up as well. Due to the above, I would keep the current text in the document in regards to the reply to DAD NS messages. It would be good if others comment too, but to me it sounds like a corner case and in any case, the tables will be updated anyway. Maybe we can add some text in the security section if it helps? Thanks. Jorge From: Joshi, Vinayak <vinayak.jo...@hpe.com<mailto:vinayak.jo...@hpe.com>> Date: Monday, September 27, 2021 at 12:34 PM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org> <draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com> <jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com>>, Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> Subject: RE: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT) Hi Jorge, A question related to DAD performed by CEs in the context of Proxy-ND. 1) Say is IP1 allocation to MAC1 on a CE is released by the CE 1 (DHCP release) and IP1 is assigned to MAC2 (CE2) by DHCP server immediately (common in DCs). 2) Now CE2 tries to perform DAD before accepting IP1 and it sends out a NS. 3) The local PE might still have IP1==>MAC1 because EVPN route might still be in flight. 4) If the local PE performs Proxy-ND and responds to the CE2, CE2 falsely detects a duplicate address. EVPN route convergence latency can lead to incorrect IP==>MAC mapping due to Proxy-ARP/Proxy ND in general. Perhaps in a Grat-ARP arriving from CE2 originated can correct it quickly. But in the DAD scenario above CE2 might just discard IP1. Should DAD NSs be not subjected to Proxy-ND by the local PE and should it always be flooded? Regards, Vinayak From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Thursday, September 23, 2021 1:05 PM To: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>; bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>; jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com>; Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> Subject: Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT) Hi Eric, Thank you very much once again for your thorough review, it helped a lot. Please see my comments and resolutions below with [jorge3]. Revision 15 incorporates all the changes. Assuming this can clear your DISCUSS and COMMENTs (please let us know otherwise), I think the document also addresses Erik Kline's comments, and it is now ready to go. Thanks. Jorge From: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>> Date: Tuesday, September 14, 2021 at 2:50 PM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org> <draft-ietf-bess-evpn-proxy-arp...@ietf.org<mailto:draft-ietf-bess-evpn-proxy-arp...@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>>, jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com> <jeanmichel.com...@orange.com<mailto:jeanmichel.com...@orange.com>> Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT) Hello Jorge, Sorry for belated reply... IETF week and some holidays were on the path... The -14 revision has vastly improved the document and has addressed the majority of my points. There are anyway still one open blocking DISCUSS point and three COMMENT points (but feel free to ignore them). See in the elided text for EV3> Regards, -éric ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- == DISCUSS == -- Section 3.2 -- Why not flooding to all other PEs the ARP/NS with unknown options ? It would be safer. [jorge] yes, the new text is as follows, let me know please: f. A PE MUST only reply to ARP-Request and NS messages with the format specified in [RFC0826] and [RFC4861] respectively. Received ARP-Requests and NS messages with unknown options SHOULD be either forwarded (as unicast packets) to the owner of the requested IP (assuming the MAC is known in the Proxy-ARP/ND table and BD) or discarded. An option to flood ARP-Requests/NS messages with unknown options MAY be used. The operator should assess if flooding those unknown options may be a security risk for the EVPN BD. An administrative option to control this behavior ('unicast-forward', 'discard' or 'forward') SHOULD be supported. The 'unicast-forward' option is described in Section 3.4. EV> please note that the 'forward' behavior does not seem to be listed as a sub-function [jorge2] Not listed as a specific sub-function but 'forward' is the flooding behavior when the ARP-Request/NS is received and the lookup in the proxy-ARP/ND table is unsuccessful, as described in section 3. I changed the bullet f) a bit for clarity: f. For Proxy-ARP, a PE MUST only reply to ARP-Request with the format specified in [RFC0826]. For Proxy-ND, a PE MUST reply to NS messages with the format and options specified in [RFC4861], and MAY reply to NS messages containing other options. Received NS messages with unknown options MAY be forwarded (as unicast packets) to the owner of the requested IP (assuming the MAC is known in the Proxy-ARP/ND table and BD). An administrative choice to control the behavior for received NS messages with unknown options ('unicast-forward', 'discard' or 'forward') MAY be supported. The 'forward' option implies flooding the NS message based on the MAC DA. The 'unicast-forward' option is described in Section 3.4. If 'discard' is available, the operator should assess if flooding NS unknown options may be a security risk for the EVPN BD (and is so, enable 'discard'), or if, on the contrary, not forwarding NS unknown options may disrupt connectivity. EV2> the text should also state that NS messages MAY be 'discarded' to be consistent with the administrative choice. EV2> in the 'MAY be forward', the text is only about unicast while the administrative choice includes the 'forward' / flooding EV2> the administrative choice should also include 'reply' (even if I really dislike this choice as it can break badly things) EV2> strongly suggest to add a 'SHOULD forward' or 'This document RECOMMEND to 'forward'' EV3> an answer or a new text for the above is all that remains from my previous DISCUSS points. [jorge3] I rewrote the text in revision 15 to clarify all those points. I split the bullet and made it clearer for IPv6. Hope it helps remove your concern: e. For Proxy-ARP, a PE MUST only reply to ARP-Request with the format specified in [RFC0826]. f. For Proxy-ND, a PE MUST reply to NS messages with known options with the format and options specified in [RFC4861], and MAY reply, discard, forward or unicast-forward NS messages containing other options. An administrative choice to control the behavior for received NS messages with unknown options ('reply', 'discard', 'unicast-forward' or 'forward') MAY be supported. - The 'reply' option implies that the PE ignores the unknown options and replies with NA messages, assuming a successful lookup on the Proxy-ND table. - If 'discard' is available, the operator should assess if flooding NS unknown options may be a security risk for the EVPN BD (and if so, enable 'discard'), or if, on the contrary, not forwarding/flooding NS unknown options may disrupt connectivity. This option discards NS messages with unknown options, irrespective of the result of the lookup on the Proxy-ND table. - The 'unicast-forward' option is described in Section 3.4. - The 'forward' option implies flooding the NS message based on the MAC DA. This option forwards NS messages with unknown options, irrespective of the result of the lookup on the Proxy-ND table. The 'forward' option is RECOMMENDED by this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- Section 2.1 -- I would have assumed that the multicast nature of IPv6 address resolution would cause more problems than IPv4 ARP. The use of link-local multicast groups do not usually help as MLD snooping is often disabled in switches for link-local. Not to mention that there could be more IPv6 addresses per node than IPv4 address and IPv6 addresses keep changing. Do the authors have data to back this section ? [jorge] I added a sentence in that respect. As a side note, one of the references that we include claims that the use of SN-multicast addresses in NS messages is actually better than broadcast in ARP, given that SN-multicast IP Das can be easily identified and discarded at the receiving CEs (assuming that the PEs do not have MLD snooping enabled) https://delaat.net/rp/2008-2009/p23/report.pdf<https://delaat.net/rp/2008-2009/p23/report.pdf> EV> I failed to see the added sentence in -13 EV> the URL you wrote above does not work anymore... Also, quite an old reference [jorge2] you're right - I removed the reference since it no longer exists. Although illustrative, It is not important to understand the text anyway. The paragraph about mcast is this one: The issue might be better in IPv6 routers if MLD-snooping was enabled, since ND uses SN-multicast address in NS messages; however, ARP uses broadcast and has to be processed by all the routers in the network. Some routers may also be configured to broadcast periodic GARPs [RFC5227]. The amount of ARP/ND flooded traffic grows exponentially with the number of IXP participants, therefore the issue can only grow worse as new CEs are added. EV2> The text does not address the fact that IPv6 nodes have more than 1 IPv6 address, which keeps changing. EV2> The text does not justify the 'exponentially', I would have assumed linearly (or even perhaps squared but not exponential) EV3> my two points above are still opened but they are non-blocking [jorge3] I tried to address both comments in revision 15: The issue might be better in IPv6 routers if MLD-snooping was enabled, since ND uses SN-multicast address in NS messages; however, ARP uses broadcast and has to be processed by all the routers in the network. Some routers may also be configured to broadcast periodic GARPs [RFC5227]. For IPv6, the fact that IPv6 CEs have more than one IPv6 address contributes to the growth of ND flooding in the network. The amount of ARP/ND flooded traffic grows linearly with the number of IXP participants, therefore the issue can only grow worse as new CEs are added. -- Section 3.2 -- Why is there no IPv6 equivalent of e) ? [jorge] we think the use of these ARP probes is not that common, whether IPv6 DAD procedures are performed by all CEs, and we want the PEs to reply to DAD messages if they can, to reduce the flooding among PEs. That's how it has been implemented. Let me know if it is ok. EV2> AFAIK, Windows does (at least did) ARP probe to do IPv4 DAD. So, it MUST either reply when there is a mapping or flood it. EV3> so, I still wonder what to do with the several Windows (and possibly others) ARP probes (non blocking) [jorge3] ok, reflecting on this, I think you are right, and we should be consistent with IPv6. In rev 15, I removed the point (e) about ARP probes, and included in point (c): c. A PE SHOULD reply to broadcast/multicast address resolution messages, that is, ARP-Request, ARP probes, NS messages as well as DAD NS messages. An ARP probe is an ARP request constructed with an all-zero sender IP address that may be used by hosts for IPv4 Address Conflict Detection as specified in [RFC5227]. A PE SHOULD NOT reply to unicast address resolution requests (for instance, NUD NS messages). In point f), "or discarded" can a packet with known IP->MAC mapping be discarded as well ? [jorge] do you mean with known options? I don't think that needs to be specified but let me know if you think differently. EV2> I meant with known mapping and unknown options. The new text is kind of strange as one sentence says "MAY be forwarded" and the next sentence says that there are 3 choices. A little ambiguous ? EV3> I still find the text weird and inconsistent [jorge3] True. Please see above. I hope the new text clears the ambiguity.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
