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

[Eric Gray (LO/EUS)]

JR,

	I agree.  However, I believe we (as a working group) have
already
agreed that the IP multicast optimization is essential.  Also, it is my
point (and it is certainly arguable) that perhaps TRILL should not be
targetting the general applications of L2 where other forms of L2 bcast
are likely to be a significant factor - but should instead focus on the
applications of L2 specific to IP only (or IP dominant) networks.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: J. R. Rivers [mailto:jrrivers at nuovasystems.com] 
> Sent: Wednesday, April 04, 2007 9:58 AM
> To: Eric Gray (LO/EUS); Silvano Gai; Caitlin Bestler; Radia 
> Perlman; rbridge at postel.org
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN" 
> alternative proposals)
> Importance: High
> 
> 
> 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.
> > > 
> > > 
> > 
>