[rbridge] An ARP/ND draft

[Radia Perlman]

Reading through this thread, there seems to be one misconception:

When "unicasting" an ARP/ND query to the probably egress RBridge, (say
R2) the Ethernet frame as transmitted by the source does *not* have to
be modified in any way.

The ingress RBridge, say R1, merely encapsulates it as a unicast TRILL
frame (by not setting the multidestination bit in the TRILL header,
and putting the nickname R2 into the egress field.

------
As for the various possibilities for verifying the ARP cache: if R1
thinks it knows the answer, rather than flooding the
query, it can
a) proxy ARP and assume it just knows
b) unicast the ARP to R2, and only if it doesn't get a response, then
flood an ARP

The idea is that R1 might think it knows, just like bridges think they
know where an endnode MAC is, but they discard it on a timeout in case
it's wrong. This optimization gives an RBridge an opportunity to
cheaply verify an entry.


Radia



On Sat, Jul 17, 2010 at 10:37 PM, Joe Touch <touch at isi.edu> wrote:
>
>
> On 7/17/2010 7:13 PM, Donald Eastlake wrote:
>> In any case, the ability to use "old" cached IP-->MAC mapping as a
>> hint for an RBridge to try first when a query comes along seems like
>> it could significantly reduce broadcasts.
>
> OK, I'll bite. Why is this useful?
>
> And - more importantly - how do you debug it when it is wrong or
> spoofed? Are you really asking users of this "optimization" to wait for
> some (new) timeout to get their hardware to work as expected?
>
> AFAICT, either the ingress rbridge knows the ARP response or it doesn't.
> If it doesn't, it should clearly NOT be limiting the scope of the ARP in
> finding the address.
>
> Joe
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>