Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

[Nick Hilliard <[e-mail]>]

Brian E Carpenter wrote on 23/10/2018 20:39:
> So, to be a bit picky, your statement that switches don't hold per-host
> IPv4 state wasn't quite right. You're stating that they may hold such
> state but it doesn't measurably impact forwarding capacity. Fair enough,
> and duly noted.

Brian,

your pickiness was foreseen and is dealt with in my email of Sep 8 :-)

The one-sentence summary is: switches don't carry ipv4 state.  The 
two-sentence summary adds that sometimes there is state handled in the 
control plane, but it doesn't affect forwarding and it isn't appropriate 
to claim that adding an ipv4 address or two or ten thousand to a network 
is going to make a difference to the forwarding capacity of the device, 
because it won't.

Sometimes there is some state held about some things on the control 
plane, but it does not impact forwarding capacity.  The term "measurably 
impact" is inaccurate - the impact is zero.  This is because switch 
asics - i.e. the bits of silicon that do the forwarding - don't have the 
hardware smarts to carry state.  This is easily demonstrated at e.g. 
IXPs where there are gigantic numbers of ip addresses being forwarded, 
but the switches remain blissfully unaware of them.  They're just 
frames.  Similarly on large L2 domains, the only thing that counts is 
the number of MAC addresses, and these are the same whether the 
ethertype is for ipv4 or ipv6.

Looking at arp proxies from a helicopter point of view, these are 
management-plane daemons which are fed frames punted up from the 
forwarding plane of the networking device, whether that's an AP or an 
EVPN l2 domain or whatever.  It really doesn't matter whether there are 
10, or 100, or 10000 entries in the lookup table because the data 
structures used to hold them are tiny and handled in standard RAM, which 
is plentiful on the sort of kit that would need to implement an ARP 
proxy to start with.  On any competently coded stack, the lookup 
mechanism will be implemented with a hash table which will give 
something close to O(1) lookups. In other words, control planes which 
implement arp (and ND) proxies are coded in a way which allows them to 
act efficiently on the control plane, and in a way which does not touch 
the forwarding plane.

Otherwise, the rest of my email from Sep 8 will fill you in on how 
control planes handle overloading.

Standard caveats apply about bad design and using kit which is unfit for 
purpose.

Someone mentioned multicast: this is slightly different, but is excluded 
from this discussion on the basis that it needs to be explicitly 
configured on a per-switch + per-vlan basis, whereas any network which 
doesn't want to run ipv4 is unlikely to have done this, and if they 
have, it's a misconfiguration and they badly need to make up their 
minds.  As as side note, this is one of the things that makes multicast 
scale badly - it injects state into otherwise stateless networks.

I hope this explains some of the nuances involved.

Nick