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

[Éric Vyncke via Datatracker <[e-mail]>]

É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 :-)

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 ?

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

-- Section 3.1 --
"A Proxy-ARP/ND implementation SHOULD support static, dynamic and EVPN-learned
entries." why not a MUST ? Or at least for dynamic & EVPN-learned ? or at least
one ?

"Upon receiving traffic from the CE... the PE will activate the IP->MAC and
advertise it in EVPN" it is unspecified how many bindings can be advertised in
the case of multiple static MAC for one IP... only one or all ?

-- Section 3.2 --
Why not flooding to all other PEs the ARP/NS with unknown options ? It would be
safer.

-- Section 3.6 --
This function MUST be a mandatory part of the list of functions of section 3.

-- Section 5.2 --
An easy to fix: "Any unknown source MAC->IP entries" isn't it IP->MAC as in the
rest of the document including the terminology section ?

-- Section 5.4 --
"traffic to unknown entries is discarded" which traffic (section 5.5 is much
better to this point suggest to copy the text)? The NDP/ARP or normal data
plane traffic ? Where is this behavior specified in the 6 sub-functions of
section 3 ?


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

Consider adding a section about host not doing GARP or doing no DAD or
optimistic DAD.

-- Section 1 --
Is there any reason why the terminology section is not alphabetically sorted ?

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

-- Section 2.2 --
Unsure about the meaning of "large layer-2 peering network"... Do we peer at
layer-2 ? Now, I understand what is meant of course but the wording appears
strange to me (not being an English native), may I suggest "large layer-2
network for peering" ?

Please expand GARP in "Unsolicited GARP". Also, this is a pleonasm as
gratuitous ARP are by definition "unsolicited" ;-)

The definition of a CE in an IXP network would be welcome.

I am afraid that I do not agree with "The issue may be better in IPv6 routers"
even if the IPv6 addresses are static in this environment (i.e., no RFC 4941
addresses).

-- Section 3 --
An IPv6 example would also be useful as NS is not like ARP.

Should the default behavior/sub-function of flooding be added to the list of 1)
to 6) ?

-- Section 3.1 --
"Upon receiving traffic from the CE"... but with which IP address ? (OK
guessable but let's be clear in a standard specification). It also seems to me
like a local policy / feature that do not require standardization.

"Note that MAC and IPs with value 0 SHOULD NOT be learned" unsure why it is a
singular MAC and plural IP ;-)

"only if the ARP/NA message creating the entry was NOT flooded before" what is
meant by 'flooded' ?

Suggestion to add some descriptions of the impact of a rebooting/new PE with an
empty cache while other PE have caches.

-- Section 3.1.1 --
Should RFC 4861 also be mentioned in "The use of the R Flag in NA messages has
an impact on how hosts select their default gateways when sending packets
off-link" ?

"Static entries SHOULD have the R Flag information added by the management
interface.", else what is the default setting of te R-flag ?

"This configured R Flag SHOULD be an administrative choice with a default value
of 1", so all other CE will appear as a router ? Not critical in the case of
IXP as it is a default free zone but in a DC (suggest s/SHOULD/MAY/)?

Is there a recommended setting for the O-flag?

-- Section 3.2 --
Is "'anycast' is enabled in the BD" specified somewhere in this document ?

Suggest to split the point d) in three items: one for each flag.

Why is there no IPv6 equivalent of e) ?

In point f), "or discarded" can a packet with known IP->MAC mapping be
discarded as well ?

-- Section 3.4 --
Please expand "IRB"

Should "flushed if the owner is no longer in the network" be complemented with
a BGP withdrawal ?

Is there any security exposure (control plane DoS) by forcing the PE without
IRB to have an IPv6 LLA ?

-- Section 3.6 --
Strong suggestion to s/the PE MAY send a CONFIRM message to the former owner of
the IP/the PE SHOULD send a CONFIRM message to the former owner of the IP/

Unsure why CONFIRM is in uppercase BTW.

"If the PE does not receive an answer within a given timer" is there a
recommended value for this timer ?

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

-- Section 5.1 --
"in the peering network" is this use case only valid in the case of IXP ?

-- Section 5.2 --
"The Proxy-ARP/ND function is enabled" but what about the sub-functions
enumerated in section 3 ?

"by snooping ARP/ND messages issued by the CEs" isn't the learning sub-function
?

-- Section 5.3 (and others) --
Why is this section apparently limited to IXP only ?

-- Section 5.5 --
There is a big overlap between this clear/good sub-sections and the previous
ones. Suggest to keep only this one + section 5.6.

-- Section 5.6 --
"IPv6 'anycast' may be required in DCs, while it is not a requirement in IXP
networks." I have doubts that anycast is never used in IXP networks. Let's
rather say "seldom used in IXP networks".

-- Section 6 --

Nothing is said about putting some limits on the number of entries for an IP
address... Else, this could lead to a DoS against the proxy & BGP sessions.

  "For example, IXPs should disable all unneeded control protocols, and
   block unwanted protocols from CEs so that only IPv4, ARP and IPv6
   Ethertypes are permitted on the peering network.  In addition, port
   security features and ACLs can provide an additional level of
   security."
While the above text is a good recommendation, I wonder what it the
relationship with this document ?

== NITS ==

-- Abstract --
s/(DBs)/(BDs)/

-- Section 2.2 --
s/IPv4 layer-3 addresses/IPv4 addresses/

-- Section 3.1 --
Please use lower hexadecimal number, e.g., s/0x86dd/0x86dd/

-- Section 5.5 --
The "IXP-LAN" terminology is only used in this section while others are using
"peering network" or "IXP networks". Let's choose only one ;-)