[rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)

[Silvano Gai]

Do we have any quantitatively data about the need of ARP/ND proxy?

With an ARP cache of 30 minutes, typical in hosts today, even with a 100
K hosts in a VLAN we get at most 55 ARP seconds. Since not all the hosts
talk with each other, it is more typically like 5 ARP/sec.

The ARP/ND cache on the RBridge must be significantly shorter than 30
minutes to not increase the amount of obsolete information.

Are we reducing from 5 ARP/sec to 3 ARP/sec for 100 K hosts per VLAN?

Is this the big optimization for which we care to create corner cases
and potential incompatibilities?

-- Silvano

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
> Sent: Tuesday, April 03, 2007 3:38 PM
> To: J. R. Rivers; Silvano Gai; Eric Gray (LO/EUS); Radia Perlman;
> rbridge at postel.org
> Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> 
> 
> 
> > -----Original Message-----
> > From: J. R. Rivers [mailto:jrrivers at nuovasystems.com]
> > Sent: Tuesday, April 03, 2007 3:31 PM
> > To: Caitlin Bestler; Silvano Gai; Eric Gray (LO/EUS); Radia
> > Perlman; rbridge at postel.org
> > Subject: RE: [rbridge] Two "shared VLAN" alternative proposals
> >
> >
> > snip...
> > >
> > >
> > > At the minimum we need to ensure that all RBridges have the
> > > information that would enable them to efficiently and
> > reliably act as
> > > an ARP/ND proxy.
> >
> > It depends on how you define the requirements of ARP/ND
> > proxy.  I have seen this general mechanism used in many
> > contexts... only one of which is covered by an IETF RFC
> > (AFAIK).  Bridges in their basic definition don't have ARP/ND
> > proxy.  Only bridges that subsume some type of IP related
> > functionality contain these.
> >
> > If an RBridge "looks and smells" like a bridge, then there is
> > natural traffic separation between VLANs, and this allows
> > systems companies to view RBridges as "better bridges".
> >
> > JR
> >
> >
> 
> The reason RBridges are "better bridges" is that they
> deal with the issues of large subnets far better than
> bridges do.
> 
> Efficient distribution of ARP/ND information is also
> an issue where a "better bridge" is needed to scale
> to larger subnets efficiently.