CCDE [7:125824]
Interesting article. Thinking out loud, I wonder if this will create another dimension to the age-old degree versus certification argument here. From my perspective, there’s another argument rarely brought out: what is “theory”, versus “principle of operation” (a classic IBM term) versus “implementation” (and, perhaps, testing).
Often, people here talk about theory as if it’s anything that you can’t type into the CLI. That approach to theory might break up routing protocols into link state, distance vector, path vector, and some things not yet generally seen. If you take that definition of theory, then, even more than “what are the differences between ISIS and OSPF”, what was the reason for some of those different choices? Going a step further, since there’s been considerable change since the first versions of each, what has changed and, more important, why?
To get into this level of discussion, I don’t see how you can avoid some things that I consider “theoretical”, but are more likely found in a computer science textbook than a vendor study guide or even design guide. For example, having a reasonable understanding of data structures applicable to routing tables, which, in turn, is going to get into theory of algorithms, graph theory, and perhaps group theory, is likely a prerequisite.
I’m comfortable with such subjects, although most of my background in them is not through a traditional academic route. Offhand, of several highly respected protocol designers I know, one has a PhD in computer science, two have them in unrelated aspects of physics, one in English literature, and a couple more were college dropouts that spent the necessary effort in reading the journals, research reports, texts, and participating in such things as IETF mailing lists.
Sooner or later, scalability becomes a very key issue in both real-world network design and next-generation concepts. Several years ago, I was a panelist at an Internet Society meeting, which essentially said “when is BGP not going to be enough?” It was something of a last-minute presentation. In fact, we had to change one speaker, and, when the moderator took the original presenter’s nametag out of the tabletop holder and put in another, I pointed out that was an example of label switching.
More seriously, I started talking about things like the performance hit from excessive iBGP meshing and where routing protocol implementations got in trouble. Another speaker talked about BGP extensions such as route reflectors and confederations to make iBGP more scalable, and ORF, route flap damping, new well-known communities (that limited propagation) and other approaches to eBGP scalability. A third speaker talked about research-level approaches, and we all agreed that it was completely unrealistic to assume that the global routing table would ever be completely converged — and global routing had to work in a condition of instability. Note that these were essentially “operational” design rather than internal design of protocols.
A bit later, when I was coauthoring RFC4098 on BGP control plane convergence measurement, the six of us, in the team, kept having to stop and say “what does this BGP concept really mean”? Our strongest mathematician, who, IIRC, took graduate studies in English literature, kept pointing out how certain parameters made lots of statistical assumptions. We needed to bring out these assumptions.
Both from inside the team and from reviewers, we learned some very interesting things about implementation. There are some very interesting interactions between the way a router stores the BGP table, and the order it sends out updates (picture a default-free router initializing). It turned out that one vendor’s implementation converged faster when given the same set of routes from a different vendor than another router identical to it. Essentially, this was a data structures issue, where different design choices internal to the router made it, relatively speaking, slower or faster to update the table given information in random address order, in strict prefix sorted order, or in order of prefix length.
—–Original Message—– From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] Sent: Friday, August 31, 2007 4:08 PM To: cisco@groupstudy.com Subject: RE: CCDE [7:125824]
Howard,
You were the first person that I thought of when hearing of the CCDE. I even wondered if you had had a hand in it, but I guess not. Very little has been made public. It’s been discussed on the CCIE list a few times recently. Here is one public article (IIRC, it’s a series of two or three articles) that has circulated:
http://www.networkworld.com/community/node/17929
Regards,
Scott
Howard C. Berkowitz wrote: > > This is the first I’ve heard of the CCDE, but I might note that > presentations skills of various sorts are critical. Nortel’s > architect > certification didn’t call for oral presentations, but, after > you’ve > established background skills, you next have to write up five > reasonably > complex networks you designed, explaining why choices were > made. The final > is an open-book exam where you design a network given to you by > the board, > and sent back to them with your assumptions and rationale. > > Long ago, I got tired of the CLI rather than the reasons for > it. It’s been > my very real-world experience to have to present designs with > thousands (or > more) of routers. Sometimes, this was a group effort where I > was called back > after giving an onsite CID. On other occasions, it was pure > consulting, or > subcontracting as the designer for a service provider’s > proposal. > > Before AT&T split into three pieces, I did one of those group > exercises. > They had 13 corporate divisions to put together as an internal > corporate > network, which was separate from the telephony operations > support systems. > > Some divisions (e.g., consumer products) had very little > in-house networking > experience, and had a relatively simple, not always optimal, > network. At the > other end of the spectrum, Bell Labs was one of the divisions. > > This was quite a few years ago, but, IIRC, there were about > 5000 routers, > many of which were branch offices. The departments ran a > mixture of RIP, > IGRP, and OSPF, and there were both Cisco and non-Cisco > routers. It was nice > to have a client that physically owned the transmission > facilities. This was > long enough ago that the core was mostly T3 on optical, with > Internet access > (other than for special groups like Bell Labs) from the core. > While the core > was initially OSPF, the growth plan (again before the corporate > split) was > to have a core-of-cores using BGP, both for complex > inter-divisional > policies and for access to the Internet. > > As I say, one example and a fairly old one. The requirements > were actually > much simpler than other enterprises I’ve done, such as a > worldwide shipping > company that had both IP and SNA on their network, with very > complex > failover policies and ISPs on several continents. > > I’d like to know more about CCDE. > > —–Original Message—– > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] > Sent: Friday, August 31, 2007 12:29 PM > To: cisco@groupstudy.com > Subject: RE: CCDE [7:125824] > > Well that’s all very interesting Steve! LOL, I guess now I > have to begin to > question whether or not I should believe everything I read on > the Internet! > > >From what I’ve read (back to that already), this thing is the > beast of all > beasts. On one level, it will devalue the CCIE (now there will > be > “non-CCDEs need not apply” job reqs, leaving out even CCIEs). > On the other, > you can’t expect expert-level folk to keep their hands on the > CLI their > whole lives, so there’s got to be some updward direction to > go. Also, as a > design guy, I like the idea of having an expert-level design > track. > > The practical sounds almost ridiculous, but I guess it has to > be. From what > I’ve read, you have to present and defend a design totaling > “thousands of > nodes” before an interactive board. So public presentation > skills will > evidently be a must! Or so I’ve read on the Internet…
Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=125904&t=125824 ————————————————– FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Category: CCIE Study
