Re: [bess] Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Jorge,

Another sorry for the belated reply…

See below for EV2> based on your reply and on the -14. I have also removed everything where we are in agreement.

As my review/ballot is dated January, I will review it again and update my ballot accordingly.

Regards

-éric

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>
Date: Tuesday, 8 June 2021 at 12:50
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Bocci, Matthew (Nokia - GB)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

Hi Eric,

Sorry for my belated reply to yours too!

Thanks again for taking the time to review our response. We just published revision 14.
See my comments in-line with [jorge2] to the outstanding points (I believe I addressed all pending points), and please let me know if that is enough to clear your DISCUSS.

Thanks!
Jorge


From: Eric Vyncke (evyncke) <[e-mail]>
Date: Monday, May 3, 2021 at 4:37 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>, [e-mail] <[e-mail]>
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… Your email was kind of lost in my post-IETF-110 filled in-tray...

See below for EV> (for the many comments, as you have addressed them, I replied nothing).

Once I am clear about how normal DAD (i.e., non optimized by your document) continues to work, then I am clearing my DISCUSS. So, more explanations by email or in the I-D are welcome.

Regards

-éric


From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>
Date: Thursday, 18 March 2021 at 09:04
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Bocci, Matthew (Nokia - GB)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)

Hi Éric,

Thanks for this, it is very useful. Please see my comments in-line with [jorge].
We just published a revision, addressing yours and all the comments received in all the reviews.

Thanks again!
Jorge

From: Éric Vyncke via Datatracker <[e-mail]>
Date: Thursday, January 21, 2021 at 3:13 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>, Bocci, Matthew (Nokia - GB) <[e-mail]>, [e-mail] <[e-mail]>
Subject: Éric Vyncke's Discuss on draft-ietf-bess-evpn-proxy-arp-nd-11: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for
draft-ietf-bess-evpn-proxy-arp-nd-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-proxy-arp-nd/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. This system could indeed be very
useful but I am afraid that this is a very complex system especially for IPv6
NDP.

Minor regret in the shepherd write-up as the WG summary did not include any
comment on the WG consensus.

Thanks to Jean-Michel Combes for its Internet directorate review at:
https://datatracker.ietf.org/doc/review-ietf-bess-evpn-proxy-arp-nd-11-intdir-telechat-combes-2021-01-20/
as Jean-Michel added some important comments, please review them as well as I
support them especially those around DAD that should be a blocking DISCUSS
point.

I also second Erik Kline's DISCUSS points.

Question to the authors and BESS WG chairs: was this document submitted to a
6MAN/V6OPS WGs review ? This is where all IPv6 experts live :-)
EV2> Still waiting for a reply on this (mainly to update the processes for similar documents), nothing is blocking for this one.


Please find below some blocking DISCUSS points, some non-blocking COMMENT
points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

Would RFC 8929 be enough to solve the problem ?
[jorge] I found RFC8929 an interesting reading, thanks for the reference. However, unless I’m missing something the use-case is very different.
It seems RFC8929 tries to reduce broadcast domains by using MLSNs where each link is its own broadcast domain. In EVPN BDs, the idea is reduce the control plane Broadcast/Multicast flooding among PEs of the same BD by replacing them with BGP EVPN routes. For ARP/ND, this basically means we learn at the ingress PE by snooping ARP/NAs and advertise the entries in EVPN MAC/IP routes so that the egress PE learns ARP/ND entries, and can reply to its local ARP-Requests/NS. Also in RFC8929, even for the bridging proxy, it seems that the proxy appears as an IPv6 host on the backbone, which is not the case in this document. Another difference is that the proxy in RFC8929 uses only ND messages to register bindings and in our document, we also use static entries and EVPN messages (in addition to snooped ARP and NA messages).
Please let me know if you see it otherwise.

EV> the use case is indeed different but the handling of new ND code should be the same or similar even if the ‘transport/sharing’ of information is different. Moreover RFC 8929 has been published by an IPv6-heavy WG.
[jorge2] are you suggesting to add a reference to RFC8929 in the introduction, for ND only? Let me know if you think that would help.

EV2> Indeed, at the bare minimum a reference to RFC 8929 should appear in the introduction with some explanations on why it is not applicable (the use case is very similar in my mind if you see the multi-link subnet (MLSN) as the broadcast domain attached to a PE). The major difference is how the control plane is implemented: either with BGP or with ND.
EV2> RFC 8929 also goes deep into the complex items of ND. So, re-using part of the RFC 8929 techniques would be useful.


-- Section 3 --
"A Proxy-ARP/ND implementation MAY support all those sub-functions or only a
subset of them.", I am afraid that it is mandatory that the reply and
duplicate-ip must be coupled: either both of them are active or none of them
are active else the system allows for duplicate IP addresses.
[jorge] the new text is as follows, let me know if it is okay. Note that the duplicate ip detection on the PEs is new in this document, and we didn’t want to make it mandatory we allow backwards compatibility with RFC7432 EVPN PEs that do proxy-ARP/ND.

   A Proxy-ARP/ND implementation MUST at least support the Learning,
   Reply and Maintenance sub-functions.  The following sections describe
   each individual sub-function.

EV> this is a progress of course but I am still puzzled how duplicate address detection can work then ? Failing to do DAD can cause very critical operational issues. Or do you rely on other mechanisms ?
[jorge2] ok, I see your point, changed the text in rev 14.
“A Proxy-ARP/ND implementation MUST at least support the Learning, Reply, Maintenance and Duplicate IP detection sub-functions”

EV2> Do not forget the Oxford coma after ‘maintenance’

----%<-----%<------x

-- 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’’
---%<-----%<-------

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Consider adding a section about host not doing GARP or doing no DAD or
optimistic DAD.
[jorge] the document does not impose the use of GARP or DAD or ODAD, or its absence. Could you please elaborate what you would like to see in that section?

EV> what would be the impact of a CE moving ‘silently’ (no GARP/DAD/ODAD) from PE1 to PE2 ?
[jorge2] Added the following paragraph at the end of section 3:
In a network where CEs move between PEs, the Proxy-ARP/ND function
   relies on the CE signaling its new location via GARP or unsolicited
   NA messages so that tables are immediately updated.  If a CE moves
   "silently", that is, without issuing any GARP or NA message upon
   getting attached to the destination PE, the mechanisms described in
   Section 3.5 make sure that the Proxy-ARP/ND tables are eventually
   updated.

EV2> Good for the text, let’s hope though that the mechanism in section 3.5 does the job


---%<----%<--------

-- 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

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)

---%<-----%<-------

-- Section 3 --
An IPv6 example would also be useful as NS is not like ARP.
[jorge] added:

   In the same example, if we assume IP1, IP2, IP3 and IP4 are now IPv6

   addresses and Proxy-ARP/ND is enabled in BD1:



   1.  PEs will start adding entries in a similar way as for IPv4,

       however there are some differences:



       A.  IP1->M1 and IP2->M2 are learned as dynamic entries in PE1 and

           PE2 respectively, by snooping NA messages and not by snooping

           NS messages.  In the IPv4 case, any ARP frame can be snooped

           to learn the dynamic Proxy-ARP entry.  When learning the

           dynamic entries, the R and O Flags contained in the snooped

           NA messages will be added to the Proxy-ND entries too.



       B.  PE1 and PE2 will advertise those entries in EVPN MAC/IP

           Advertisement routes, including the corresponding learned R

           and O Flags in the ARP/ND Extended Community.



       C.  PE3 also adds IP4->M4 as dynamic, after snooping an NA

           message sent by CE4.



   2.  When CE3 sends an NS message asking for the MAC address of IP1,

       PE3 behaves as in the IPv4 example, by intercepting the NS, doing

       a lookup on the IP and replying with an NA if the lookup is

       successful.  If it is successful the NS is not flooded to the

       EVPN PEs or any other local CEs.



   3.  If the lookup is not successful, PE3 will flood the NS to remote

       EVPN PEs attached to the same BD and the other local CEs as in

       the IPv4 case.


EV> thank you

EV2> rereading it... and suggest to remove the comparison with IPv4 in the IPv6 example.

---%<-----%<------

-- Section 3.1.1 --

---%<-----%<----------

Is there a recommended setting for the O-flag?
[jorge] I modified the sentence as follows:
“These configured R and O Flags MAY be an administrative choice with a default value of 1.”
EV2> will need to think about the suggested value when I am reviewing the whole document


-- Section 3.2 --
Is "'anycast' is enabled in the BD" specified somewhere in this document ?
[jorge] good point. I added the following in the Learning sub-function section:
“This document specifies an "anycast" capability that can be configured for the proxy-ND function of the PE, and affects how dynamic Proxy-ND entries are learned based on the O Flag of the snooped NA messages. If the O Flag is zero in the received NA message, the IP->MAC SHOULD only be learned in case the IPv6 "anycast" capability is enabled in the BD. Irrespective, an NA message with O Flag = 0 will be normally forwarded by the PE based on a MAC DA lookup.”

EV2> Could also be in the terminology section (no hard feeling, just a suggestion)


...%<------%<----------



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.


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 ?


---%<------%<--------


-- Section 3.6 --

---%<---------%<----------


I have re-read three times the "anti-spoofing MAC" part, and, I still do not
understand it... Is MAC-AS the black-hole address (then why not using a all 0
MAC address) or an alternative MAC address (but then who modifies the frame
header to the CE) ?
[jorge] this is about updating all the CE’s ARP/ND caches with the AS-MAC for the IP, to make sure the spoofer does not attract the traffic for the IP. Using an all 0s MAC would not be accepted by the CEs, and we wouldn’t know if there is traffic from the CEs to the ‘suspect’ IP. I re-worded it a bit, let me know if it is better:
“Optionally the PE MAY associate an "anti-spoofing-mac" (AS-MAC) to the duplicate IP in the Proxy-ARP/ND table. The PE will send a GARP/unsolicited-NA message with IP1->AS-MAC to the local CEs as well as an RT2 (with IP1->AS-MAC) to the remote PEs. This will update the ARP/ND caches on all the CEs in the BD, and hence all the CEs in the BD will use the AS-MAC as MAC DA when sending traffic to IP1. This procedure prevents the spoofer from attracting any traffic for IP1. Since the AS-MAC is a managed MAC address known by all the PEs in the BD, all the PEs MAY apply filters to drop and/or log any frame with MAC DA= AS-MAC. The advertisement of the AS-MAC as a "black-hole MAC" (by using an indication in the RT2) that can be used directly in the BD to drop frames is for further study.”

EV2> Humm re-re-reading this part of section 3.7. Isn’t this procedure also acting as a DoS against IP1 ? As all the traffic to IP1 will not reach the valid one ?
EV2> The terminology section is also a little unclear, it should at least use “MAC address” rather than “MAC”
EV2> more generally, this process is just piggy-backed on the proxy itself and does not bring a lot. I would suggest to remove this anti-spoofing part.


----%<---------%<----------