Russ White published an interesting story explaining why we’re using IP and not CLNS to build today’s Internet.
Let’s start with a few minor details he missed that I feel obliged to point out (apologies to Russ for being too pedantic, but you know me…):
Two weeks ago I replied to a battle-scar reaction to 7-layer OSI model, this time I’ll address a much more nuanced view from Russ White. Please read his article first (as always, it’s well worth reading) and when you come back we’ll focus on this claim:
The OSI Model does not accurately describe networks.
Like with any tool in your toolbox, you can view the 7-layer OSI model in a number of ways. In the case of OSI model, it can be used:
Every now and then I stumble upon a blog post saying “OSI 7-layer model sucks” or “OSI 7-layer model is a lie”, most recent one coming from Robert Graham.
Before going into the details, let’s agree on the fundamentals.
Most everyone who ever tried to build a network spanning more than one transmission technology and including intermediate nodes came to the conclusion that layered approach to networking makes sense.
Whether you have three, four, five, or seven layers in your model doesn’t matter. What really matters is that your model contains all the functionality you need to implement host-to-host networking in target environment.
Isn’t IS-IS a better fit for building L3-only networks than BGP, particularly considering that IS-IS already has a protocol to communicate with the end systems (ES-IS)?
In theory, he’s correct (see also this blog post).
One of my readers sent me this question after listening to the podcast with Douglas Comer:
Professor Comer mentioned that IP choose a network attachment address model over an endpoint model because of scalability. He said if you did endpoint addressing it wouldn’t scale. I remember reading a bunch of your blog posts about CNLP (I hope I’m remembering the right acronym) and I believe you liked endpoint addressing better than network attachment point addressing.
As always, the answer is “it depends” (aka “we’re both right” ;).
With the advent of layer-3 leaf-and-spine data center fabrics, it became (almost) possible to build pure layer-3-only data center networks… if only the networking vendors would do the very last step and make every server-to-ToR interface a layer-3 interface. Cumulus decided to do just that.
Hank left a lovely comment on my Rearchitecting L3-Only Networks blog post:
What you describe is literally intra-area routing in CLNS.
He’s absolutely right (and I admitted as much during my IPv6 Microsegmentation presentations @ Troopers 15).
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).
Paulie, a frustrated enterprise IPv6 early adopter summarized his pains in a comment to my “Small-site multihoming in IPv6: mission impossible?” post saying “[IPv6/IPv6 support] is a mess and depressing” and asked “Is it too late to go to CLNS?”
Quite a few old-timers (I’m definitely one of them) lament the glory days of VMS, DECnet Phase V and CLNP, but while CLNP was a viable alternative for the next-generation IP in 1993, it would fare worse than IPv6 today.
The OSI protocol stack has a major advantage over the TCP/IP stack: it defines both the protocols and the APIs between the layers. CLNS (Connection-less network Service) is the API (the function calls that allow transport layers to exchange datagrams across the network) while CLNP (Connection-less network Protocol) is the layer-3 protocol that implements CLNS. In my diagram, CLNS would be a thin line above CLNP between L3 and L4 boxes.
IOS developers did not escape the confusion between CLNS and CLNP. The clns routing command does not make sense; you cannot route an API. The command should have been called clnp routing.
A while ago I’ve received an interesting question from someone studying for the CCNP certification: “I know it’s not necessary to configure clns routing if I’m running IS-IS for IP only, but isn’t IS-IS running over CLNS?”
I’ve always “known” that IS-IS uses a separate layer-3 protocol, not CLNP (unlike IP routing protocols that always ride on top of IP), but I wanted to confirm it. I took a few traces, inspected them with Wireshark and tried to figure out what’s going on.
You might be confused by the mixture of CLNS and CLNP acronyms. From the OSI perspective, a protocol (CLNP) is providing a service (CLNS) to upper layers. When a router is configured with clns routing it forwards CLNP datagrams and does not provide a CLNS service to a transport protocol. The IOS configuration syntax is clearly misleading.
It turns out the whole OSI protocol suite uses the same layer-2 protocol ID (unlike IP protocol suite where IP and ARP use different layer-2 ethertypes) and the first byte (NLPID) in the layer-3 header to indicate the actual layer-3 protocol. I was not able to find any table of layer-3 OSI protocol types, so I had to experiment with Wireshark to figure out the values for CLNP, ES-IS and IS-IS (yes, these three are distinct L3 protocols).
ISO makes a fine semantic distinction between the service offered to higher layers (CLNS) and the protocol used to implement it (CLNP). There is no such distinction in the IP world.CLNS (and CLNP) uses long variable-length addresses, making it a viable successor to IPv4. At the time when the IETF community started to design the next-generation IP (before IPv6 appeared on the drawing board), the proposals to use CLNS were taken pretty seriously even though they used interesting acronyms like TUBA (TCP and UDP over Big Addresses) and FOOBAR (FTP Operation Over Big Address Records).
Follow the links in the previous paragraph, they point to actual RFCs.In the end, IETF decided to invent yet another protocol (IPv6), effectively quadrupling the IPv4 address size while retaining most of the benefits and drawbacks of IPv4. If I remember correctly, the technical explanation for this decision was the variable-length of the CLNS addresses (which make the hardware implementation of layer 3 forwarding pretty complex), while one of the real reasons was probably also the "not-invented-here" syndrome (and the lack of total control over a new protocol inherited from another organization).
CLNS was widely used in early large IP networks primarily due to the multi-protocol implementation of IS-IS (the CLNS routing protocol that is roughly equivalent to OSPF), which came from DECnet phase V(anyone remember DEC, the maker of great minicomputers and probably the best operating system ever written?). Several very large networks used IS-IS at that time, forcing Cisco to optimize IS-IS code before they managed to fix the OSPF code. This led to an interesting phenomenon: the best-performing IP routing protocol was a protocol endorsed by ISO that was never designed (initially) to carry IP prefixes.
When network engineers claim that they use CLNS in their networks, they usually want to say that the use IS-IS, which uses CLNS addresses to identify routers (similar to IPv4 addresses used by OSPF as the Router ID). The actual forwarding of CLNP datagrams (what I would consider the real usage of CLNS) is very rare today; the last time I've seen it, CLNP was used in the management networks to manage Sonet/SDH devices. According to one of the comments to my initial post, most of these devices support IP as the transport protocol today, making CLNP mostly obsolete.
Anyhow, I've recently discovered that Cisco supports CLNS routing over BGP and wanted to write about it … obviously, based on the poll results, that would be a purely academic exercise.