Hello Jorge
As I am back from vacations, it is time to write a reply. We are now very close
to a revision which would allow me to clear my blocking DISCUSS. Look below for
EV4> (which is trivial to fix)
Big thank you for also addressing/replying to my non-blocking COMMENT points
;-) (I have elided the text about them)
Regards,
-éric
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com>
Date: Thursday, 23 September 2021 at 09:35
To: The IESG <i...@ietf.org>, "draft-ietf-bess-evpn-proxy-arp...@ietf.org"
<draft-ietf-bess-evpn-proxy-arp...@ietf.org>, "bess-cha...@ietf.org"
<bess-cha...@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "Bocci, Matthew (Nokia
- GB)" <matthew.bo...@nokia.com>, "jeanmichel.com...@orange.com"
<jeanmichel.com...@orange.com>, Eric Vyncke <evyn...@cisco.com>
Subject: Re: É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>
Date: Tuesday, September 14, 2021 at 2:50 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com>, The
IESG <i...@ietf.org>, draft-ietf-bess-evpn-proxy-arp...@ietf.org
<draft-ietf-bess-evpn-proxy-arp...@ietf.org>, bess-cha...@ietf.org
<bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Bocci, Matthew (Nokia -
GB) <matthew.bo...@nokia.com>, jeanmichel.com...@orange.com
<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.
EV4> what is the behavior when the ‘reply’ option is selected and there is no
successful lookup ? I guess it is ‘forward’ but this is worth specifying in
the text.
- 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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
