Reinventing CLNS with L3-only Forwarding

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).

You might want to read this first

This is the fifth blog post in this series. You might want to read the first three before starting this one.

Back to CLNS

Hank continued his analysis with comparison of routing protocols:

You need a protocol between routers. Some people seem to prefer BGP as the solution to any problem. But the most natural solution here, for IGP routing, would be to use an actual IGP. IS-IS would do a fine job. Not much worse than BGP. And less prone to configuration/network-design problems than BGP. You could advertise /32s. Or you could introduce a new TLV to make a proper destination.

IS-IS would probably be able to do the job in reasonably small environment. However, in a dense VLAN-based virtualization environment, a single L3 switch might need to insert several thousand routes into the physical routing domain, probably stretching IS-IS capabilities (and potentially killing OSPF with all those Type-5 LSAs).

It would be *minimal* work to actually implement this functionality into a proper IS-IS implementation. Just a small matter of programming.

The IS-IS implementation might not be an issue – carrying IPv4 host routes is a non-brainer; carrying host routes for multiple routing domains (VRFs) would require new TLVs. Anyone aware of an RFC/draft specifying such functionality (maybe Avaya documented what they’re doing with IS-IS in SPB deployments?)

You need a protocol for the routers to find out which EndStations are directly connected. In CLNS, that would be ESIS. In IPv4 you could indeed use ARP. In IPv6 you could use NDP. Or you could build a new proper host-router protocol (and use ARP until it catches on).

A proper host-to-router protocol, integrated with virtualization awareness (so that a VM re-advertises itself when it’s moved) would be ideal. In the meantime, implementations like Cisco DFA or Microsoft HNV (or VMware NSX for firewalling purposes) have to rely on all sorts of guesswork (listening to ARP/ND requests, DHCPv6 replies, or even gleaning source IP/IPv6 addresses).

Hank concluded his analysis with…

Of course all this will be impossible, because it reeks of CLNS. And therefore it must never ever be implemented in TCP/IP. Too bad, CLNS did it right.

Even worse, when IETF started designing next-generation IP protocol, a group of engineers actually suggested using TCP/UDP over CLNS (TUBA), but of course that idea never moved forward because the underlying protocol (and its “weird” concepts) had been designed in the wrong standardization body.

Regardless of its rejection in IETF, TUBA lives on – it’s been implemented in Cisco IOS and the last time I checked you were still able to telnet to a CLNS address.

To learn more about TUBA, read these RFCs:


  1. Hi Ivan,
    regarding this post and

    what if one used pppoe on the end hosts?
    It is probably supported everywhere (both on the OS and network side) and the router would need to redistribute the host connected on the other end.
    If the host moves, ppp would timeout and the route would be removed.

    PS. I'm not a ppp expert at all, so apologies if I am missing some important points that would not allow this to work!

    1. It __might__ work but (A) would require changes to host OS (which is a major showstopper in virtualized environments) and (B) would have severe performance limitations as opposed to doing the same L3 forwarding we always did with slightly modified control plane. I'm not aware of any reasonably-priced box that could do PPPoE at terabit speeds (as opposed to 10K$ 10GE switches which can do L3 forwarding at those speeds).

      Finally, there's the MTU issue - familiar to anyone who had to implement TCP MSS clamping on a DSL router.
    2. PPP is a bad solution, since it use a binary escaping from HDLC. This will result in making a constant bit rate workload into a variable bit rate transport. Bell Labs invented the generic framing procedure, that is an ITU standard (G.7041) and used in optical networks. This could replace all the various HDLC based framings and keep the characteristics of the bit rate. However, this requeries a hunting curcuit for fining the start of a frame, so it is not a good fit for software only implementations.
  2. > carrying host routes for multiple routing domains (VRFs) would require new TLVs. Anyone aware of an RFC/draft specifying such functionality

    Multi-Topology ISIS (RFC5120)?
Add comment