I’ve been in a hole working on a lot of other projects for a few months (hence my lack of posts!), but not so deep as to not notice that EIGRP has stated they will release a basic version of EIGRP, along with the intellectual property needed to implement that basic version of EIGRP. There have already been a few reactions to this move on the part of Cisco, but (given my deep involvement with the protocol over the years), its seems worthwhile to add my 2 cents. The primary complaint I’ve seen about this announcement is that Cisco isn’t releasing the more advanced features of EIGRP — specifically stubs. There are, on the other hand, several positive aspects to this announcement for the networking industry at large.
First, it opens the way for EIGRP to be applied to existing problems for which solutions are proving difficult to find. Two specific instances are small office/home office space (such as the IETF’s homenet working group), and mobile ad hoc networks (the IETF MANET working group). EIGRP is an almost ideal solution for smaller networks where configuration and troubleshooting skills are bound to be minimal. Given it’s low overhead, and ability to adapt to a large variety of network topology while providing optimal forwarding under a wide range of situations, EIGRP makes sense in this environment.
Second, it opens the way for distance vector protocols to again become a subject of serious study and thought in the larger community. For many years now almost all research in interior gateway protocols has been centered around link state protocols. There is a sense in which the routing world has been lopsided for a number of years; there is some chance that this will open research into distance vector protocols and ideas. The “right” solution to routing, in the longer term, is likely to be some combination of link state and distance vector ideas.
Third, I would guess this will only be the first step of what Cisco is planning for EIGRP; we should think of this as a first step, rather than a final step, in the progress of the protocol.
Finally, I would say this about the process of EIGRP within the IETF; Cisco doesn’t “keep control of the protocol,” by publishing this as an informational RFC. In fact, the opposite is true; Cisco has opened itself up to other parties making contributions to the protocol without Cisco playing a part. While this probably isn’t realistic — anyone who really wants to work in the EIGRP space would be much better off working with Cisco rather than against Cisco — there is still a bit of risk taking at this stage of the game on Cisco’s part. Only history will tell us whether or not this gamble plays out in Cisco’s favor, or not.
From my perspective, at least, I hope EIGRP wins through this, and through EIGRP, the larger networking world. If Cisco’s move in this space moves the theory and practice of network design and network protocol design forward, then I applaud the move.
Truth in Writing Note: I have been deeply involved in the development and support of EIGRP for many years, and may be listed as a co-author on the draft. As always, I try to stay objective in my thinking and writing.
About Russ White
