[rbridge] ARP/ND (was RE: Two "shared VLAN" alternative proposals)
J. R. Rivers
jrrivers at nuovasystems.com
Wed Apr 4 09:47:57 PDT 2007
I don't disagree... I couldn't make the connection between this and
proxy ARP/ND.
JR
> -----Original Message-----
> From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> Sent: Wednesday, April 04, 2007 9:07 AM
> To: J. R. Rivers
> Cc: rbridge at postel.org
> Subject: RE: ARP/ND (was RE: [rbridge] Two "shared VLAN"
> alternative proposals)
>
> JR,
>
> Just to be precise, in the working group discussions, we have
> been making a very strong distinction between multicast and broadcast.
>
> I agree that - in an environment where multicast is a large
> factor (where large means something like more than 1% of the total
> injected traffic), the traffic associated with ARP is way down in
> the noise. However, if any effective form of multicast optimization
> is implemented, the impact of potentially looping multicast can be
> scoped to affected VLANs (and possibly even to multicast "listeners")
> by techniques other than TTL (such as queue management that provides
> effective isolation of logical interfaces, or hard upper limits on
> total multicast traffic, for instance).
>
> --
> Eric Gray
> Principal Engineer
> Ericsson
>
> > -----Original Message-----
> > From: J. R. Rivers [mailto:jrrivers at nuovasystems.com]
> > Sent: Wednesday, April 04, 2007 11: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)
> > Importance: High
> >
> >
> > 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
> > > > > 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.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
More information about the rbridge
mailing list