Subject: [rbridge] End station discovery/liveness detection

From: jaihyung at etri.re.kr (CHO, JAI HYUNG)
Date: Mon, 14 Mar 2005 23:20:13 +0900

Dear All
 
Pardon me if I ask some question regarding this discussion.
 
1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
right? 
2) And the MAC information is distributed using something like link-status 
protocol. 
3) The distributed MAC information is used for passing datagram to actual 
destination. By the way, in most IP terminals, the first datagram sent to destination 
terminal is, again...., ARP !!!!

- Therefore, in summary, the rbridge does ARP probing constantly although 
my terminal never get called by others. 
- in other words, rbridges must keep up MAC address of all terminals in lookup table 
although the actual number of MAC addresses other terminals need to know is only a 
few of servers. 
- the link-status protocol distributes MAC info which will be anyway known by 
ARP when it is actually necessary by terminal. In other words, rbridge
uses ARP and link-status protocol to know the information that will be known 
by ARP?

For me, it sounds strange. 

Why does rbridge try to 
build up MAC table although it is possible that the MAC info can be 
installed on bridges on-demand when ARP is actually exchanged between source and 
destination ? Of course if we use ARP for this purpose instead of link-status protocol.
 
Here is my suggestion;

"Divide local network by IP subnets. Pass ARP between rbridges in a way 
that prevent looping and reduce unnecessary flooding and via shortest path.
The shortest -path, I mean, is according to subnets and other information.
ARP will be flooded in destination subnet anyway. 
When a destination terminal replies, just install the MAC entry on 
lookup table of rbridges. Thus a MAC forwarding path, i.e. a L2 connection,
is established via sub-optimal path across IP subnets.
 
This is not ATM, nor MPLS, but something L2 LSP.
 
Using this method, rbridges do not need to probe terminals constantly, 
do not need to build entire MAC table, also do not need to 
worry about terminals that are indirectly connected, removed or inactive. 
am I wrong?
 
Jaihyung Cho

>Alex Zinin wrote: 
>> Yes, this would work, and would most probably represent the largest part of 
>> station attachments in today deployments. There are corner cases, like a 
>> mini-hub in a cubicle with a single station attached to it, but we don't 
>> optimize for those and a probing-based safe-fail should take care of them. 
> 
>That sort of probing can cause large amounts of broadcasts outside the 
>rbridge campus, notably which may cascade into a subsequent rbridge 
>(imagine two campuses that get connected by a hub). 
> 
>What about this case (the direct attached one) is so significantly worth 
>optimizing? 
> 
>Joe

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 06:29:43 -0800

> 1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 

No. Not in general, and I haven't heard that proposed as a way to make 
the rbridge work.

New MAC addresses are noticed by seeing packets enter the rbridge with 
new (MAC) source addresses, the same as with a learning bridge.

> 2) And the MAC information is distributed using something like link-status 

Yes - within each rbridge campus.

> terminal is, again...., ARP !!!!

ARP is not sent to the destination; it is sent to broadcast.

> my terminal never get called by others. 

No, as above.

> although the actual number of MAC addresses other terminals need to know is only a 

No, again as above.

> uses ARP and link-status protocol to know the information that will be known 

No, again as above.

> destination ? Of course if we use ARP for this purpose instead of link-status protocol.

I think of it the way you do - on-demand, the way learning bridges work.

> The shortest -path, I mean, is according to subnets and other information.

That's not an rbridge; that's a set of routers.

> ARP will be flooded in destination subnet anyway. 

ARP will not flood beyond the first IP subnet; see RFCs 1812 (don't 
forward all 1's broadcast, which is ARP) and RFC 2644 (don't even 
forward subnet-directed broadcasts).

> worry about terminals that are indirectly connected, removed or inactive. 

See above. ;-)

Joe

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050314/a1ffd7c0/signature.bin