Re: [mdnsext] mDNSext features/requirements rollup

My former employer (a large multi-national electronics device manufacturer) at one time had ~13,000 AppleTalk Zones and 10's of thousands of devices. We had all sorts of issues:
- Name collisions when far spread admins choose the same name for their zones.
- Router performance issues handling that many zones and devices.
- Issues with software trying to display that many zones and devices.
We were more than glad to get rid of Apple Talk when IP became the defacto standard.
My point is to becareful what you mean by large scale :-)
-Neil
________________________________________
From: mdnsext-bounces@ietf.org [mdnsext-bounces@ietf.org] on behalf of RJ Atkinson [rja.lists@gmail.com]
Sent: Friday, February 15, 2013 9:26 AM
To: mdnsext@ietf.org
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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

_______________________________________________
mdnsext mailing list
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext