From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Sun Sep 12 2004 - 15:20:45 GMT-3
At 9:06 AM -0400 9/12/04, Scott Morris wrote:
>Ok, no worries. Now that I have had more sleep, it seems that we mostly
>agree on things, I just didn't read the entire thread, so missed some of the
>history of your remarks. :)
>
>No, the CCIE isn't an end to a journey but a beginning. Just like any
>collegiate degree. In fact, just like damned near anything!
>
>But, the exam/cert does meet its target which is to test topics within a
>pre-defined pool of technologies to demonstrate that the candidate has
>expert-level knowledge within those technologies and their implementation in
>the Cisco environment.
Of course, that always gets into the definition of expert. I
personally like to use compare-and-contrast discussions when teaching
various protocols, and often get into _why_ a particular protocol
design decision was made. By protocol design, I mean in the IETF or
elsewhere (with Cisco involvement, of course), as opposed to Cisco's
specific implementation.
As I say, this is my teaching style, but not something you tend to
see in courseware. A good example of this sort of thing, which CCIE
doesn't test but I feel is useful in getting true understanding of
the protocols, is to know some of the reasons that OSPF and ISIS have
quite a few differences in solving a similar problem.
At some level, it's a matter of style -- John Moy (OSPF) versus Radia
Perlman (ISIS). Protocol architects do have "signatures". Radia and
John are both very nice people that sort of intuitively do every
detailed thing a little differently. She used to give a one-day
tutorial at Interop on the theory of routing protocols -- take it if
you ever have the chance, and are willing to have most protocol
features explained in the best Jewish mother style. If she had her
way, she wouldn't have watchdog timers -- they'd nag instrad.
Seriously, she is a wonderful speaker.
But on a conscious basis, OSPF was optimized for performance on
relatively slow processors, which often very much preferred 16- and
32-bit alignment. That is why OSPF has fixed-length bit strings for
options.
ISIS, well before Integrated ISIS, was optimized for extensibility,
since it originally was seen as a research framework. That's why it
has variable TLV structures rather than bit strings -- it's much
easier to add a TLV, and unlikely you will run out of bits.
Serious question: is this sort of thing "expert" knowledge? Or,
perhaps, for what kind of expert? It's absolutely vital to know
things like this if you are proposing or evaluating changes to the
protocol itself. In contrast, to be an expert on network
implementation, you absolutely have to every nuance of how Cisco
coded OSPF over NBMA.
While I can't discuss specifics, I am currently on a project that
deals with another vendor's router implementation. One of the things
that I am doing is reviewing the engineering specifications, for
standards compliance as well as probable interoperability with Cisco
and Juniper. There's also an element of this that involves looking at
design documents for different components and picking up that choice
A is incompatible with choice B, or command format X is going to be
hard to remember.
This involves all sorts of knowledge -- let me not say "expertise" to
avoid confusion. As you suggest, a degree, a CCIE, etc., are starting
points. In all fairness, what I am doing draws both from practical
experience -- including the errors that real-world operators make --
as well as deep understanding of the protocols, to pick up
incompatibilities between protocols that aren't usually used with one
another. There's also verifying that things are written to the
correct version of the standard.
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:42 GMT-3