CLNP and the Multihoming Myths
When IESG decided to adopt SIP, not TUBA (TCP/UDP over CLNP) as IPv6, a lot of people were mightily disappointed and some of them still propagate the myths how CLNP with its per-node addresses would fare better than IPv6 with its per-interface addresses (you might find the writings of John Day on this topic interesting and Petr Lapukhov is also advocating this view in his comments).
These views are correct when considering small-scale (intra-network) multihoming, but unfortunately wrong when it comes to Internet-scale multihoming, where CLNP with TCP on top of it would be as bad as IPv4 or IPv6 is (routing table explosion due to multihoming is also one of the topics of my Upcoming Internet Challenges webinar).
CLNP Background
CLNP addresses are assigned to nodes, not interfaces. In IPv4 terms, all interfaces (even multi-access interfaces like LAN) are unnumbered and each node has a “loopback” interface with a single address (/32 prefix in IPv4). While the concept was highly interesting and marginally more useful than subnet-based IP architecture, it also imposed additional burden on hosts and routers:
- Hosts and routers had to run ES-IS protocol which enabled routers to find adjacent hosts and helped hosts to find the nearest router (similar to what we do with RA in IPv6).
- Routers had to propagate host reachability information (host routes in IP terminology) throughout the area.
- Each router in the area had to know the location of all hosts within the same area.
CLNP intra-area forwarding has some elements superficially similar to bridging (packets are forwarded based on host ID) but works as true routing (layer-2 encapsulation is changed and TTL is decreased whenever a packet is forwarded by a CLNP router). The number of hosts within an area is obviously limited by the routers’ capabilities (and can be quite limited in some actual CLNP implementations); to scale, CLNP introduced a concept of areas, which are almost identical to IP summary routes.
IP undoubtedly scales much better, as its IP subnets present the first layer of summarization: even if the directly connected router has to know the location of every host in the subnet (its MAC address learned through ARP), that information is not propagated to any other router.
CLNP and Multihoming
Per-node addresses nicely solve intra-area multihoming. A host is always reachable through a single address, even if it has more than one interface. When an interface fails, the existing sessions are not disrupted (as they originate from an address that belongs to the box, not the failed interface).
CLNP behavior might have been marginally more useful for multihomed workstations, in particular to mission-critical applications that cannot afford to lose TCP sessions, but I doubt that most users have serious problems with the current IP-subnet-based approach.
Multihomed CLNP servers are undoubtedly easier to implement than their IP cousins (there is nothing to implement in the CLNP case), but the current tools (from NIC bonding to multi-chassis port channel) provide reasonably-good solution.
In any case, if you truly want to have CLNP-like behavior, you can always deploy loopback interfaces and RIP or OSPF on the servers (IBM used that approach to implement IP multihoming for the mainframes).
Larger-scale Multihoming
CLNP hosts could not be attached to more than one area or they’d have to use two CLNP addresses, one in each area (or become inter-area routers), so CLNP is no different from IP when you want to have a host attached to two widely separate subnets or areas.
The claims that node-based addresses could solve global routing table explosion are still misguided science fiction.
http://pouzin.pnanetworks.com/images/KoreaNamingFund100218.pdf
The fallacy you talk about here is the belief that hierarchical routing is the ONLY form of scalable routing and that all we should care about is better summarization. This "statement" has been widely accepted since the initial work published by Kleinrock and Kamoun.
However, hierarchical routing per-se has serious scaling limitations in self-similar (power-law) network graphs, though SOME approaches exist to help here, such as topology summarization, found for instance in PNNI or Nimrod or more recently in TARA. There is a lot of other, alternate approaches to scalable routing though: e.g. check out flat-space routing models such as found in ROFL or VRR.
The main problem with SIP/IPv6 was that it did not really attempt to solve anything but larger address pace problem. And that's for more that 15 years of "evolution"! Add the larger prefix size to the problems with scalable hierarchical routing in self-similar networks and you get more issues than we had with IPv4. At least CLNP was SOME step in the right direction, trying to resolve the "naming" problem.
Will check the alternative approaches (at the very least that will be a mind-challenging academic exercise), but based on current approach to scalable routing and forwarding (which CLNP shares with IP) ... and ignoring the fancy powerpoint architecture slides, the only solution lies in end-hosts as proven by SCTP.
The naming problem is much more fundamental that it may look like, as it defines the core properties of architecture, but that's a separate discussion topics, due to the abstract nature of the subject. It's not that it easy as it may look like though :D
As for OSI routing scalability using ISIS coupled with "some inter-domain" routing protocol (ECMA/BCP), it's the SAME as of IPv4 or IPv6, since they all use hierarchical routing. Unsummarizable System-IDs? Compare this to Host-ID in IPv6. But notice that with CLNP you do not have to advertise the "transit" link prefixes into routing protocols (okay you can do the same with IPv4 now using prefix suppression or unnumbered links kludge).
Furthermore, NSAP addresses could be structured the way you need to reflect a hierarchy and summarized at domain boundaries just the same way say IPv6 prefixes could be. I think there was an RFC adopting the use of NSAP for Internet addressing. Next, what we call "Ethernet VLANs with thousands of MACs" could have been implemented as ISIS Level1 domains with routed mobility - unless you're still using Ethernet hubs ;) The same scaling properties as IPv4 with "TRIL'ish" features ;)
I know there is no way back to CLNP or whatever we had in the past. I just wish there would more real work toward improving the existing architecture, rather than using band-aid solutions ;)
SCTP: never tracked its history, but it gets the job done. Not sure the ISO session layer would be able to run multiple connections between NSAPs in different areas (which would be needed).
OSI routing scalability: absolutely agree.
"Transit link prefixes": they give IP better scalability. If you insist on having host addresses, you can use link-local prefixes in IPv6 (the unnumbered kludge is gone).
"Ethernet VLANs with thousands of MACs" - we both know that's stupidity. Didn't want to go into this particular can of worms (but will do, don't worry), but yet again, if you love host routes, you can have them in IPv4 as well ... if only someone would dust off the LAM code base.
"More real work done on improving architectures" - as we both know, it's almost impossible to change anything beyond networking devices (and even these are hard to change). They had a window of opportunity 15+ years ago when they could have changed TCP as well, but that fell apart.