Re: [mdnsext] mDNSext features/requirements rollup

[RJ Atkinson <[e-mail]>]

On 15  Feb 2013, at 01:18 , David Farmer wrote:
> So the routers are in the idea location to do this, but I'm
> really concerned about the instability adding more network state
> into the routers.  

I have operational experience with large-scale  (e.g. campus 
wide) deployments of AppleTalk over Ethernet that used low-cost 
(and by today's standards) very very low performance CPUs 
(e.g. 68K) with tiny amounts of RAM.

The AppleTalk service advertisement proxying and zone
advertisement proxying did NOT create any sort of
instability.  Back in those days, the deployed world was
multi-protocol with some DECnet, some IP, a lot of IPX,
and some other stuff besides, so there was a lot more
state that needed to be kept inside the routers.
With today's IP-centric world, the state needed in
routers is much less, generally just a bridge table,
an IPv4 RIB/FIB and an IPv6 RIB/FIB.  Further, unlike
back then, the actual packet forwarding generally 
does not involve the switch/router CPU or the RAM
associated with the CPU.  Instead, commodity or custom
packet processing ASICs handle the heavy lifting
today, and most of the other state (e.g. bridge table, 
IPv4 & IPv6 FIBs) is stored separately in commodity TCAM.

So modern enterprise switches have tons of spare RAM
and A LOT more CPU to spare than those devices did
back in the 1990s.

> While in large scale enterprise routers we try to make
> things as stateless as possible, ideally the routing table only,
> and we are supporting 2500 to 7500 devices with a single
> large scale router.

Back in the day, tiny (68K + smallish RAM) AppleTalk (EtherTalk) 
routers were supporting 2000+ devices successfully -- without
instability.  Today's enterprise routers and L3 switches are 
MUCH more capable, with more spare capacity.

So my operational experience says that this is not a real
problem, provided we are ordinarily sensible.  

For one thing, mDNS information ought to be "soft state", that 
regularly expires in some sensible way, and gets tossed and 
relearned when someone chooses to reboot (or significantly 
reconfigure without rebooting) some router or L3 switch.

Yours,

Ran