Subject: [rbridge] ARP/ND (was RE: Two "shared VLAN" alternativeproposals)

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 4 May 2007 13:33:24 -0400

(I started this message a while ago but hadn't sent it...)

Three points on ARP/ND that I don't think had been mentioned, the first
two possibly in favor of optimization, the 3rd against for ND:

(1) There are networks where peripheral traffic is more expensive than
core traffic. Assume wired infrastructure between the Rbridges but radio
links, where bandwidth is expensive, between them and end stations.
Further, assuming that most of the traffic is local to the network,
perhaps voice, and stations arrive/leave at a substantial pace, such a
first responders at an emergency incident scene. Is flooding all ARPs so
they are radio broadcast really the right thing to do?

(2) An optional Rbridge extension to optimize out the inner MAC
addresses for IP traffic can be done for broadcast and IP derived
multicast without any ARP/ND information but would require such
information for the unicast case.

(3) ND is extensible and more complex than ARP so, even setting aside
secure ND, it would be more complex to proxy than ARP.

Thanks,
Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Silvano Gai
Sent: Wednesday, April 04, 2007 12:30 PM
To: J. R. Rivers; Eric Gray (LO/EUS); Caitlin Bestler; Radia Perlman;
rbridge at postel.org
Subject: Re: [rbridge] ARP/ND (was RE: Two "shared VLAN"
alternativeproposals)

Let me try to summarize what I learnt from the replies to my message. 

ARP/ND optimization:
1) it is not justified by a bandwidth issue;
2) it is not justified by a latency issue;
3) may help reduce the problem with the broadcast storm, but the problem
is really IP multicast. Solution like the one proposed by Radia at the
last IETF address both IP multicast and ARP; therefore there is no need
for a special ARP/ND solution;
4) it introduces corner cases.

Why do we want to do ARP/ND optimization in the first version of TRILL?

I restate my proposal: let's drop it by the first version of TRILL and
deal with it later, in a separate document.

-- Silvano

> -----Original Message-----
> From: J. R. Rivers
> Sent: Wednesday, April 04, 2007 8:26 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)
> 
> 
> Sorry I must have mis-stated my point.  It seems that if ARP is the
bulk
> of your multicast traffic, then optimizing it doesn't seem like much
> return-on-investment.  If other multicast comprises the bulk, then
> optimizing ARP doesn't seem to provide much return-on-investment.
> 
> JR
> 
> 
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> > Sent: Wednesday, April 04, 2007 7:38 AM
> > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia
> > Perlman; rbridge at postel.org
> > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > alternative proposals)
> >
> > It doesn't.  However, you mentioned IP multicast as another area of
> > concern...
> >
> > Thanks!
> >
> > --
> > Eric Gray
> > Principal Engineer
> > Ericsson
> >
> > > -----Original Message-----
> > > From: J. R. Rivers [mailto:jrrivers at nuovasystems.com]
> > > Sent: Wednesday, April 04, 2007 10:36 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
> > >
> > >
> > > Why does ARP/ND equate to IP multicast optimization?
> > >
> > > JR
> > >
> > >
> > > > -----Original Message-----
> > > > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> > > > Sent: Wednesday, April 04, 2007 7:34 AM
> > > > To: J. R. Rivers; Silvano Gai; Caitlin Bestler; Radia
> > > > Perlman; rbridge at postel.org
> > > > Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> > > > alternative proposals)
> > > >
> > > > 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
> > > > targeting 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.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge