[rbridge] Max Network size / ARP servers

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Guillermo Ibáñez wrote:
...
> We must be aware of the high cost of ARP processing cost in hosts of a 
> big network under the basic broadcast ARP approach.

It's a question of what BIG means. First, broadcast is the backup
anyway. Second, caching at endhosts and snooping of broadcast responses
reduces request load.

Finally, I may be in the minority here, but this has nothing to do with
RBridge. I don't see the primary benefit of RBridge to support scaling
to millions of nodes on an L2 net, nor do I see it as an opportunity to
rewrite how ARP is implemented.

Knwon optimizations can always be applied, but the core of its operation
in this regard is to support conventional broadcast services. ARP is no
different than any other broadcast service in that regard.

...
> ARP servers can support replication. The point is whether it is an
> objective to improve ARP security or the current situation is acceptable 
> in the foreseable big networks.

RBridges are designed to replace bridges to improve routing, not to
improve ARP security - the latter of which needs its own solution. Given
that solution, it can certainly be supported in an RBridge, but I don't
see why we would consider RBridges to uniqely enable or require it.

...
>>>What does the ARP server do with a request of the destination if it
>>>hasn't seen any communication from that host before?
>
> Flooding, of course. Flooding is unavoidable at the end, but must be
> kept to a minimum for big networks to not use up hosts processing power.
...
>>>What I would like to see is a comparison between  the cachés 
>>>(distributed server/register) approach  with the current ARP proxy 
>>>approach considering all aspects: engineering, security, broadcast 
>>>volume, etc
>> 
>> See LANE and other NBMA literature. There are benefits, but there are
>> also substantial robustness issues. Note that we can do NOTHING to avoid
>> flooding when speaking to systems that haven't spoken yet - we won't
>> find them at all unless the ARP emerges at the right egress link (L2
>> network), and there's no way to know a-priori which one that will be.
>> 
> I will look at it, but I do not think it is the same thing.

Both use the same solution to avoiding broadcast - a centralized ARP server.

>> Some measurements on ARP load are available at:   
>> http://100x100network.org/papers/myers-hotnets2004.pdf

That paper has some interesting positions, but that would be open
research. When a solution has been developed and tested, it might be
considered for standardization. Since this is not an IRTF effort,
though, that would be future work, IMO.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgQJUE5f5cImnZrsRAnCTAKD5v0cnZuarZZrNnn673nsNYQzZzACcCMz1
nDUUaT/jinVhlwJxYltXwq4=
=G783
-----END PGP SIGNATURE-----