Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

["Eric Levy- Abegnoli (elevyabe)" <[e-mail]>]

The minimum requirement (draft says 20) is definitely not a good idea, as it depends so much on use cases. The value could easily vary from 2 (datacenter, dhcp assigned addresses, 1 LL, one global) to thousands (RFC4389 proxy on the path to the limiting device).

That is another thing which is a very bad idea: LRU. These limiting devices are not routers in the vast majority of cases, they are switches (including wireless controllers and APs). This is because they need to sit as close as possible to the offending device.

Typically, these devices can see multicast packets (DAD is the only one that is guaranteed to happen, sort-of…), not unicast.  SAVI switches entirely rely on DAD for instance. Punting unicast ND packets, and even worse data packets to the CPU of a switch so that it can figure out which addresses are LRU may be quite problematic to say the least.  LRU with just DAD would be a joke, as it only tells you when the entry was created. A crystal ball would be better in my opinion.

The rest of the draft is fine: logging, configuring, all good common sense. Is it worth a draft? I don’t think so.
A draft that would establish any sort of two way communications between the host and the network would be a lot more valuable. Rather than signaling the count is exhausted, network could signal the limit is getting close for instance. Provided that the host does something about it, for instance recycling LRU addresses, it would save the network from having to decide by itself.
Eric


On Tue, Nov 8, 2022 at 2:13 PM Ole Troan <otroan=[e-mail]<mailto:[e-mail]>> wrote:
A requirement like that would be perfectly fine in an RFQ. Less so in an RFC.

Ok, so then let's see *what* would be acceptable to put into an RFC.

The draft says that the hardware must allow the operator to configure the limits that the network places on the hosts, and should do something reasonable when the limit is hit, such as drop the address that was used least recently. I don't see how any of these statements can be controversial and it makes sense for them to be in an RFC. These hosts do exist (example: ChromeOS), and if a network operator (example: Jen) wants to support them, then it should be possible to do so.

The draft also says that if the network does not allow enough addresses per client for current implementations, those implementations will experience user-visible outages. As I see it, that's simply a fact (those implementations do exist, and they do fail), so I don't see how it could be controversial.

The thing that there doesn't seem to be consensus on is whether the IETF can/should place a minimum requirement on the number of addresses.

Did I miss something?