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

[J. R. Rivers]

It seems that if ARP is the bulk of your broadcast/multicast, then you
don't really need a very efficient broadcast/multicast mechanism.  Some
networks can be characterized as you've stated; however, there are
others that use L2/IP multicast in a substantial fashion.

JR


> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com] 
> Sent: Wednesday, April 04, 2007 6:14 AM
> To: Silvano Gai; Caitlin Bestler; J. R. Rivers; Radia 
> Perlman; rbridge at postel.org
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> 
> Silvano,
> 
> 	Where IP (v4 or v6) is the exclusive higher layer in a specific
> network deployment, it is likely that ARP is one of the most common 
> forms of broadcast traffic that may occur.  As we've 
> previously agreed 
> that broadcast traffic is of particular concern in TRILL, the 
> potential
> to drastically reduce (or possibly eliminate) common broadcast traffic
> should be considered a worth-while objective.
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> > Sent: Tuesday, April 03, 2007 7:22 PM
> > To: Caitlin Bestler; J. R. Rivers; Eric Gray (LO/EUS); Radia 
> > Perlman; rbridge at postel.org
> > Subject: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> > alternative proposals)
> > Importance: High
> > 
> > 
> > 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.
> > 
> > 
>