Subject: [rbridge] End station discovery/liveness detection

From: jaihyung at etri.re.kr (CHO, JAI HYUNG)
Date: Tue, 15 Mar 2005 16:34:13 +0900

Dear Joe,

>CHO, JAI HYUNG wrote:

>> 1) ARP is sent actively to probe an inactive terminal and obtain MAC info, 
>> right? 
> 
>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.
 
see following case;
 
+----------+ 
|rbridge|---[Hub1]----[Hub2]----[ 100s of terminals ] 
+----------+
 
suppose the rbridge once learned MAC info of 100s of terminals. 
rbidge will periodically advertise location of 100s of terminals 
using link-status protocol. after a while, some are switched off, 
some are hibernated and some are just busy on local work. 
the rbridge must advertise aliveness of active terminals. 
how does rbridge know which terminal is active and which is dead? 
in this case, monitoring data frame or sensing local link doesn't help. 
you may not use active probing using ARP, however 
you will need substitute method for rbridge's probing or 
periodical reporting of active terminals, other than just MAC learning.

>> 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 !!!! 
> 
>ARP is not sent to the destination; it is sent to broadcast.
 
In the context above, "sent" means being transferred to 
destination by any means, including broadcasting or multicasting or 
any guided transfer method. 
Arguing on syntax hardly helps on technical discussion.

>> - 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. 
> 
>No, again as above.

as above of what reference? specific point please. 
note that even in 802 bridges keep up all MAC addresses in all bridges 
belong to same broadcast domain. MAC address is not aggregatable. 
unless some VLAN grouping or IP subnetting is used, rbridges will 
have the overhead of learning all MAC infos.
 
>> - 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? 
> 
>No, again as above.
 
also, please be specific.
 
>> 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. 
> 
>I think of it the way you do - on-demand, the way learning bridges work.
 
and then what happen? why did you stop thinking of this method. 
what problem did you face? I have a solution. I want to share my idea.
 
>> "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. 
> 
>That's not an rbridge; that's a set of routers.
 
what's your criteria of distinguishing hybrid switch and router? 
for me, a router requires IP processing function in data forwarder, whereas, 
hybrid switch is a machine providing IP equivalent service using L2 hardware. 
the concept of employing IP aware protocol over L2 hardware is same 
as rbridge and my proposal. read the above text carefully. I just talked ARP, 
shortest-path and subnet. Isn't that a bit different way of using ARP 
compared to rbridge that you drafted? and you spell it router.... 

>> 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). 
>
 
what defined in RFC2644 is service termination of L2 at routers. 
I am sure some objective of rbridge is to replace the role of 
routers, and extend the range of L2 service (including ARP) across 
rbridged LANs. In that case, RFC2644 is not exactly relevant to 
new concept of hybrid switch.
 
I am wondering, somehow, you think one whole rbridge domain 
should be one IP subnet. If so. (though not sure of your opinion) 
as Alex noted, I must point out that the size of one rbridge cloud 
can be more than 50,000 terminals if rbridge is used in metro-Ethernet.
Currently metro-Ethernet ISPs use L3 switches 
to tackle scaling problem. IEEE recently works on Provider Bridge 
standard (802.1ad) of which the main objective is to replace L3 switches 
to bridges. Main idea of pbridge is providing VLAN interconnectivity 
between customer network using bridged provider network. 

I think IETF rbridge will eventually compete with IEEE pbridge in market. 
In that case, I am wondering what grouping 
method you will propose to be distinguished from IEEE pbridge. 
In order to get favorable support from customer, you need a method of 
systematically organizing rbridged network consists of 100,000 of terminals. 
I can't think better method than IP subnetting of customer networks 
and interconnecting subnets by rbridge.

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: Tue, 15 Mar 2005 06:39:41 -0800

>>new (MAC) source addresses, the same as with a learning bridge.

It knows because it hears traffic FROM those terminals. It times-out 
idle entries, just like a learning bridge.

> in this case, monitoring data frame or sensing local link doesn't help. 

See above - that's what makes time-outs work.

> periodical reporting of active terminals, other than just MAC learning.

I agree that active probing doesn't work,  but neither does your 
assumption of hard state. You need soft state - state which times out.

> Arguing on syntax hardly helps on technical discussion.

If my terminal sends a broadcast that includes your terminal's IP 
address inside, there is NO information about your MAC address to learn. 
  All the system can learn is my MAC address - which it learns because 
it is the source address of a packet.

When you send the ARP reply, it will contain your MAC address as the 
source of that packet, which is where (and when) it will be learned.

It is sufficient to learn MAC addresses when seeing them as source 
addresses of L2 packets that enter the rbrige system.

> have the overhead of learning all MAC infos.

The rbridge is going to keep the MAC addresses only of all actively 
speaking terminals. Others will timeout. (i.e., as to the first 
assertion that ARPs are used to probe for a complete list of all 
terminals, your item #1).

> also, please be specific.

As I mentioned above in the description of how learning works (even in 
an rbridge), rbridge doesn't care about ARP per se; all it cares about 
is the source MAC address of packets. There is no need to peek at ARP.

> what problem did you face? I have a solution. I want to share my idea.

My understanding is that an rbridge will learn the ingress of a MAC 
address when it sees packets enter that ingress with that MAC address as 
an L2 packet source address.

The arrival of the address means we learn it and propagate its routing 
info. End stations need not use ARP to learn an address (it may be 
loaded out-of-band, e.g.), so once we know where to send a MAC address 
we should expect to handle it at -any- ingress, not just the one that 
sent (or did not send) an ARP.

> hybrid switch is a machine providing IP equivalent service using L2 hardware.

L2 - forwards based on L2 information

L3 - forwards based on L3 information

There are hybrids, but an rbridge from the _outside_ looks like (IMO) an 
L2 device, not a hybrid. Internally it makes use of L3-derived routing 
protocols for distributing encapsulation information and forwarding entries.

> compared to rbridge that you drafted? and you spell it router.... 

It is different, and not what I think we're talking about.

> routers,

It is to replace the role of existing bridges. It is not to provide L3 
services.

> and extend the range of L2 service (including ARP) across 
> rbridged LANs.

Yes, all L2 services should be handled across a group of rbridges, just 
as they would be over a group of bridges.

> In that case, RFC2644 is not exactly relevant to 

Perhaps - that may be an interesting new WG. This WG, IMO, is not 
focused on a device which provides a hybrid external service, however, 
so this is out of scope.

> should be one IP subnet.

It might have overlapping non-interacting IP subnets (vlans), but yes, 
IMO IP subnets map to L2 nets.

> If so. (though not sure of your opinion) 
> to tackle scaling problem. 

Yes - partly because spanning tree doesn't scale.

> IEEE recently works on Provider Bridge 

I am unable to access that spec; what little information indicates that 
pbridge is more like auto-managed vlans, and does not address the need 
for a replacement for spanning tree inside a set of bridges (esp. in 
being backward compatible with such).

> and interconnecting subnets by rbridge.

I think you have that backwards; I would have rbridges of groups of 
10,000 and IP routers between the groups.

FWIW, IMO rbridges might scale better than bridges, but they will never 
scale as well as routers. That's OK, though - routers require 
renumbering when migrating, and rbridges/bridges do not. There's the 
tradeoff...

Joe
-------------- 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/20050315/6ba0c45c/signature.bin