[rbridge] Max Network size

[Joe Touch]

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



Guillermo Ibáñez wrote:
>>>>>I wonder if an ARP server/registrar approach can be foreseen as an 
>>>>>alternative or complementary strategy.  The Designated Rbridge registers 
>>>>>each host, when an ARP is received, at a (distributed) ARP server.
>> 
>>>>When an ARP reply is received, that can be done. But the first ARP to an
>>>>otherwise unknown host, which has silently attached to a stub at an
>>>>RBridge ingress, is unknown. The only way to find it is to flood.
>> 
>>>True. But this is the only case.
>> 
>> The problem is that it's the defining case. All others can, as you
>> observe, be optimized with a variety of engineering solutions. IMO, none
>> are all that interesting - ARP already caches at the endhost anyway.
> 
> Yes.  But till then you avoid in many cases to do flood.

I'm not convinced about the "many" part; as I mentioned, the endsystems
cache. There are also snooping issues - ARP replies, if broadcast, can
preload these caches. By looking for ways to avoid flooding, we avoid
some of the optimizations already designed into ARP.

That said, this is where a good study would help; it's premature to do
anything except provide basic functionality (broadcast ARP) and mention
that optimizations MAY be useful, IMO.

>>>>>This 
>>>>>can help to enforce security (like preventing MAC spoofing) and  also 
>>>>>ensure ARP resolution in one step without broadcast. 
>> 
>>>>Correct the above if not correct, but assuming that there is no way to
>>>>secure ARP that doesn't modify ARP too.
>> 
>>>ARP query would be performed by the Designated Router (encapsulated 
>>>query directed to the ARP server).
>> 
>> The ARPs are originated outside the campus; the two options are to
>> encapsulate the ARP and broadcast it or to encapsulate it and send it to
>> an internal cache (the ARP server). Neither is secure, since they are
>> triggered by external, unauthenticated ARPs.
>> 
> I do not understand this "outside" origination of ARPs.  My 
> understanding is that ARPs are sent by local hosts or routers.

I've been speaking of ARPs as originating outside the RBridge, from
hosts connected to egress RBridges. Those ARPs are not performed by the
Designated Router; they just arrive at the egress.

The discussion of Designated Routers in the I-D is an optimization; I've
been speaking of the base case. Base case ARPs cannot be authenticated.

>>>I am not expert, but I guess the 
>>>server can autenticate the DRs.
>> 
>> Sure - but that only authenticates the internal cache; there's no way to
>> authenticate the initial broadcast whose reply is used to populate the
>> cache.
>>  
> But the caché, as a centralized point, can detect duplicated addresses 
> and other abnormal behaviour....

Sure - but at what cost? Central point of failure? That's not an
acceptable trade-off, especially to enforce ARP properties that are
generally not enforced on conventional Ethernet LANs.

...
>>>An ARP cache query from host would produce from DR two 
>>>packets : a registration of originating host at ARP registrar and an ARP 
>>>query of destination host at ARP server. 
>> 
>> 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.

Agreed. But L2 semantics include flooding; ARP isn't the only use of
broadcast.

> We can think of new mechanisms for cachés (ARP servers), as they 
> implement a centralized function for a set of IP addresses, to track 
> hosts mobility.

What you're proposing is to turn an RBridge into an NBMA (non-broadcast,
multiaccess network), and to push ARP into a server, ala ATM LAN
Emulation (LANE). I see that as a step backwards, esp. because, as noted
above, ARP isn't the only use of broadcast.

> 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.

If we include a cache, we run the risk of having the cache semantics of
the endsystem collide with that of the network cache. Overall, I'd say
let's build an RBridge with broadcast and let's show that the load is a
big enough problem to deal with it first.

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

iD8DBQFCf+R+E5f5cImnZrsRAspuAKDsoKdE7mjnWVafIlgtfda2JXdLfwCgoHcn
oYZ1MjPaGdRLSmKtUQnlm/U=
=d26+
-----END PGP SIGNATURE-----