There are four different issues with IB vs OOB signalling & control, actually -- 1) isolation of control traffic from payload traffic to eliminate possible security breaches. 2) isolation of control traffic from payload traffic to prevent starvation of control traffic by (possibly misbehaving) payload traffic. 3) having an alternative, isolated, routing infrastructure for control traffic which can function even when primary routing is hosed. 4) having a physically separate network for control traffic which can concievably survive when primary network is broken. On #1, Internet routing protocols are notoriously weak. Using globally routable frames to carry neighbour-to-neighbour routing information is a recipe for disaster (i think everyone on this list can think of few not-yet-plugged holes arising from this approach). In most IGPs and eBGP there's simply no need to use routable IP packets, period. The only exception is iBGP hack (and consequent route-reflector kludgery), and this can only be cured by a better-designed IGP which can carry all exterior routing information. I hope someone's doing something to make it happen. Using non-IP packets does not always bring isolation; OSI stack is even more vulnerable. So a cheap fix would be to design routing hardware in a way forcing some reserved IP addresses to be non-routable. (127/8 seems to be a good candidate :). Even better is to start using non-IP frame types altogether. With all its weakness, outside attacks on ARP are unheard of. Another (weaker) option is to use cryptography. Besides inevitable bugs (like numerous problems in SSH), crypto is slow and hard to do right. #2 is also a known pitfall (hello, OFRV :) Although, in theory, just jacking up priority on packets carrying routing protocols & network monitoring traffic could take care of this problem, the reality is quite hairier. Most hardware doesn't prioritize generation of ICMPs (so a lot of looped or misdirected packets can swamp the routing processor which is incidentally used to separate control traffic from transit traffic). Usually, there are cross-interface dependencies resulting from shared buffer memory, the supposedly "non-blocking" switching fabrics being anything but, confusion between queueing and drop priorities, plain broken design of packet classifiers (hard to do it right at high speeds :), and simply network admins being lazy to configure interface ToS processing appropriately (and/or failing to filter out packets with ToS similar to the routing protocols' at all ingress points!) Given the practical problems of getting ToS for control traffic being set up properly, the option of guaranteeing bandwidth and processing capacity to control traffic by using separate, non-configurable forwarding/queueing for non-IP traffic seems to be quite reasonable. Problems arising from control traffic starvation are numerous and can easily lead to prolonged network-wide failures. Therefore, making control traffic "OOB" is definitely worth-while. #3 is somewhat muddled by the fact that having valid routing information while having no functioning payload pathway is somewhat irrelevant (in theory, haiving such information may let network to use unidirectionally-broken paths, or allow faster recovery from network fractures by eliminating the need to send updates about _working_ parts of the split-off networks). In practice, the only real gain from a redundant control network is the ability to better diagnose problems, particularly routing problems in the primary network (i.e. the "OOB" network is used to carry diagnostic traffic only). A dedicated OOB network for console access to various pieces of equipment is a lot more useful. The horrible weakness of SNMP makes separate control network somewhat more resistant to attacks; however, it also requires zealous filtering of SNMP and other control protocols (such as telnet :) packets coming to the router's control unit(s) from the primary network. If such filtering is broken or glossed over, there are no security gains. #4 is hardly useful in any situation (with the exception of diagnostic network). In fact, telco-issue "OOB" is usually muxed over the same wires. So, i would say i'm pro-OOB where it concerns clean confinement of control traffic into a non-routable, unconditionally-prioritized frames, and contra-OOB when it comes to making separate networks for control traffic. Your definition of "separate network" may vary :) --vadim