[rbridge] End station discovery/liveness detection

[touch at ISI.EDU (Joe Touch)]

CHO, JAI HYUNG wrote:
>  
> 
> Dear Joe Touch,
> 
> 
>>>>>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.
>  
> oh, didn't you? 
> In chapter 4 section C of Radia's Infocom paper, it is clearly 
> stated that:
>  
> ". the DR (rbridge) can periodically issue ARP queries for D (destination), 
> to reassure itself that D still resides on its LAN"
>  
> maybe you wrote the rbridge draft without reading Radia's paper.
>  
> Also, if you read past thread of this discussion, you'll see Radia, Alex, 
> Russ are all discussing about some probing method.

So far I have heard it as a way to optimize rbridge's routing info, but 
not required to make it work. I should have been more specific with my 
statement, agreed.

Even so, I disagree that it is useful for optimization. Not all authors 
agree on every word of a doc sometimes ;-)

>>>>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? 
>>
>>It knows because it hears traffic FROM those terminals. It times-out 
>>idle entries, just like a learning bridge.
> 
> oh.I see.. 
> so, you argue that rbridge shouldn't prob end-station for liveness test 
> or terminals shouldn't report status, but do link-status update 
> as frequently as MAC entries appear in rbridge's MAC table, right?

The last step does not follow from the first. The updates need to happen 
relatively quickly when changes appear, but there may be delays to 
aggregate changes and avoid routing storms that would be triggered by a 
series of MAC changes.

> Is it your own opinion, or a conclusion reached by consensus? 

We haven't started the work of the WG. It is my opinion, but based on 
work we did in PILC where we did examine this issue in detail, and 
conclusion was reached by consensus. It may or may not apply here, but 
that is for the WG to decide.


> Reading past discussion on this mail thread, it seems other 
> people have little bit different idea.

Yes, but they have not considered (IMO) the full impact of the 
optimization on the L2 devices attached to an rbridge. Probing is fine 
when L2 devices are directly attached, but when two rbridge campuses are 
connected, or when L2 devices connect to conventional bridged subnets 
then to an rbridge campus, such probing can cause broadcast storms on 
the attached subnets.

It seems dangerous and inappropriate for an rbridge to try to avoid 
internal broadcasts by periodically issuing external broadcasts, but I 
haven't see anyone who has proposed this optimization address the 
situation I raised as a counterexample.

> ok... anyway, let's suppose in your way that link-status update 
> will happen in that frequency, and see what problem you will face. 
> I am wondering if you know how often terminals broadcast ARP 
> and how frequently MAC entries are changing.

I don't know, but also don't care. ;-) IMO, an rbridge could work if it 
does as well as a bridge, and bridges do not do periodic liveness tests.

> In my company, my terminal is attached in a VLAN that includes 
> about 100 terminals. When I capture Ethernet frames, I see nearly 
> 2 ~ 3 ARP broadcasts at every second. 
> 
> If 100 terminals produce 2~3 ARPs per second, a rbridged network 
> of 50,000 terminals will cause 1000 ~ 1500 link-status update 
> and route calculation at every second.

As (far) above, that amount of update isn't required; the routing tables 
can be updated quickly, but not triggered per se by every single MAC change.

Further, just because some party loses or times-out an ARP cache and 
does an ARP broadcast does _not_ mean that the related MAC addresses 
(source or dest) have moved. The routing table needs to be updated only 
if something moves.

> Of course all rbridges 
> must perform the calculation simultaneously. In fact, the overhead 
> is doubled if the link-status info is fed from destination rbridge 
> by ARP reply, and from source rbridge by L2 frame.
> 
> I am wondering what system can handle this processing overhead. 
> This is the scalability issue that Alex has pointed out at the beginning 
> of this mail thread, and people suggested methods to reduce this 
> overhead, such as end-station probing or reporting.
> I think dynamic state update without optimization is no better idea.

See above - I don't think the situtation you describe causes problems.

>>>>>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. 
>>
>>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.
> 
> suppose that rbridges are spreading ARP in a systematic way that 
> duplicates of ARPs are forwarded via SPF tree rooted at source rbridge. 
> intermediate rbridges remember upstream node. 
> 
> when the destination terminal replies ARP reply, the rbridges install MAC 
> forwarding state using the information contained in ARP message. 

You don't need to peek inside the ARP to figure anything out. The MAC 
addresses at issue (that might have changed) are in the source address 
of the ARP packet.

> the rbridge passes the ARP reply to upstream node, as a result, MAC forwarding 
> path is established between source and destination terminal. 

OK - how does that work for the first ARP? The routing tables are empty. 
So you distribute the arp via SPF - SPF isn't a broadcast tree. You need 
to use broadcast on the first ARP, or it will never reach the dest.

The return ARP goes directly to the source of the original ARP. But you 
didn't add anything to the routing tables yet, because you describe 
doing this only for ARP replies. The return ARP has no way to get back!

---

Alternately if you install the source MAC along the broadcast tree when 
the first ARP goes through (leaving breadcrumbs to get home), then the 
return ARP will go back same broadcast tree. So all routes will be 
installed on the same broadcast tree.

That's basically how a learning bridge works, and what we're trying to 
avoid - use of only a single broadcast tree for all traffic.

> there's no need for MAC learning, no need for propagation of MAC info. 
> in summary, ARP is used for distribution of MAC info as well as for 
> shortest path establishment in a integrated, lightweight method. 
> isn't it simple than broadcasting link-status update separately?
> 
> you may read http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal- 
> 00.txt 
> for detail of my idea, although the draft wasn't written for rbridge in mind. 
> I'm thinking to submit edited version for rbridge, if people are not so negative 
> on my idea.

It doesn't appear to help, because it appears to behave like existing 
learning bridges... (or please correct the above conclusions).

  >>>>>"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. 
>>
>>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. 
> 
> I see no difference of your definition and my concept of hybrid switch 
> except the *encapsulation* part that you still insist.

Agreed.

> my proposal makes use of L3 information (i.e. IP subnet) internally configured 
> in control plane. the subnet info is used for controlling range of ARP 
> broadcast and for imposing policy between group of terminals. 
> it is in effect a L2 forwarding machine because MAC forwarding state 
> is stored on data plane using ARP.

Agreed, and I disagree that this is either what an rbridge is or what 
would be useful.

> this is just a different way of using ARP than your design of rbridge. 
> you have no reason to call your rbridge is the only pure hybrid and others are 
> kind of router solution.

The encapsulation part _is_ the reason.

>>>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.... 
>>
>>It is different, and not what I think we're talking about. 
> 
> yes, it is not the way you are thinking. 
> however the objective and scope of work are exactly matching to 
> what is described in drafted charter, except the *encapsulation* part.

Definitely agreed.

>>>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, 
>>
>>It is to replace the role of existing bridges. It is not to provide L3 
>>services. 
> 
> do you mean that rbridge will never replace in-campus routers? 

I think it will replace them only where they are used relucantly because 
a bridge system didn't scale. I don't think they will replace all uses 
of routers.

> note that routers are heavily used in campus network. 
> typical configuration of campus network are mesh or ring of 
> local backbone routers and there are only one or two levels of bridged 
> trees under the backbone cloud. there's not much room for routing at the 
> bridged trees, because most traffic go through local backbone. 
> this typical configuration is basically same in metro-Ethernet. 
> hence, not much practical benefit is expected from 
> replacing the low-cost bridges to rbridges. 
> furthermore, unless you remove the local routers, you'll not 
> achieve the advantage of no-renumbering in migration. 

Agreed. In that case, we want to replace the routers. But it is because 
we could have tried to use bridges but they would have had spanning 
trees that slowly converted.

> I think right target of rbridge is local backbone routers 
> and metro-backbone L3 switches.

OK - I agree with that too, but I don't agree that we will expect L3 
services at rbridges.

>>>I am wondering, somehow, you think one whole rbridge domain 
>>>should be one IP subnet. 
>>
>>It might have overlapping non-interacting IP subnets (vlans), but yes, 
>>IMO IP subnets map to L2 nets. 
> 
> .......
>  
> 
>>>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. 
>>
>>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). 
> 
> For your information, the goal of Pbridge is briefly stated in section 
> 1.1 Scope of 802.1ad as following;

You are forwarding proprietary specs of the IEEE. Please check copyright 
issues before doing so again (it would be useful for this list not to 
get into trouble with the IEEE)...

> "......  this standard specifies the operation of *MAC Bridges* 
> that support VLANs. To this end it ....  to enable a Service Provider 
> to use a Virtual Bridged Local Area Network to provide separate 
> instances of the 802 MAC Service, ...., to multiple independent customers, 
> in a manner that does not require cooperation among the users and that 
> requires a minimum of cooperation between the users and the provider 
> of MAC service, this standard further specifies the operation of 
> Provider Bridges. ..."
> 
> IEEE does not replace spanning tree, but uses it more structured, 
> systematic and efficient way.  multiple-spanning trees inside the provider
> network provides near-shortest paths between customer networks. 
> furthermore, the scale of pbridged network can be up to metro-Etherent size. 
> I think it is necessary for TRILL people keep in mind of 802.1ad closely.

So using separate spanning trees for different VLANs is what makes 
802.1ad scale? But you need to use L3 routers to get between VLANs. This 
doesn't help a single L2 scale, it just means you can share hardware. 
This doesn't help what an rbridge is trying to do.

>>>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. 
>>
>>I think you have that backwards; I would have rbridges of groups of 
>>10,000 and IP routers between the groups. 
> 
> you misunderstand the nature of market requirement. 
> it's not just a matter of scalability but matter of management and policy. 
> network managers need a tool to group people and control 
> privilege of accessing a group.

Describe how that works on a set of learning bridges.

> if you rely on routers for this function, rbridge will never make 
> any bit of market share. because network managers will still be using routers. 

If that is what they are using routers for, I agree. I don't agree that 
is the case of router use rbridges are trying to address.

> you may think you can do it using VLAN, however, you'll see 
> lots of enemy once you start touching VLAN because 
> VLAN function and space is seriously limited, but many people 
> want to do lots of different things using VLAN.
> 
> on the contrary, IETF has developed far scalable and flexible 
> concept of IP hierarchy. I don't understand why you don't 
> make use of this superior tool of IP subnetting for rbridge. 

Because it's not an rbridge anymore; it's a router.

> IP subnet is friendly to router. it can be used for controlling 
> range of broadcast. it is a convenient tool for imposing internal policy and security.

And it doesn't support mobility nearly as well as a single L2 subnet.

> BTW, you may think 10,000 terminals is a good scale limit of rbridge, 
> however, it is no good figure at all. 
> one, single broadcast network of 10,000 terminal is unacceptable thing 
> to network managers. 

I disagree.

> two, IEEE pbridge will scale better. 
> three, processing overhead at that scale will seriously be heavy.

If you think a pbridge is a better solution, why are you here? If we 
change rbridge enough to make it look like a pbridge, we're done - just 
go to the IEEE ;-)

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/20050317/ab83f0d2/signature.bin