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.
----------------------------------------------------------------------
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
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
-- 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)
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
