From: adeolu@sympatico.ca
Date: Mon Sep 13 2004 - 10:34:54 GMT-3
Hello everyone,
I usually just follow the threads here and do not post but this one is too intersting to pass up.
Obviously, the days of garnering certs or degrees for no particular cause are over. My personal belief is that whatever qualifications someone involved in this industry attains should depend on the path that you have chosen to take. A researcher needs different tools from a network engineer. Another reason would be gaining knowledge that is not necessarily in your core area but would be helpful in peforming your job better. For instance, I got my MSCE (in addition to my Cisco certs) because it helped me do my job as a network engineer better. I have never worked as a Sysadmin formally, but many of my clients would complain about problems that were not necessarily network-related but system related. Having a good grasp of Windows helped me solve problems more effectively.
Having said this, I think it is a good idea for anyone to pursue a CCIE if you are a core network engineer. Not only is Cisco the industry and market leader (at least in R & S), the firm is intrinsically involved in the development of many IETF standards. For instance, Cisco has been heavily involved from the start in the development of MPLS. As such, the certification will at least assert that the individual has a high level of competency in networking. If the network is based on Cisco technology, then the individual can be said to be an "expert".
Howard made a good point on the different "types" of knowledge. Both types are important, and one may be highlighted over the other as you move from project to project or job to job. Seeing that we are part of an industry that seems to be in constant flux, it would not do any harm to have both.
Just my two cents......
Adeolu Adeoye
>
> From: "Howard C. Berkowitz" <hcb@gettcomm.com>
> Date: 2004/09/12 Sun PM 02:20:45 EST
> To: <ccielab@groupstudy.com>
> Subject: RE: Failed RS lab [7:92677]
>
> 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.
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:42 GMT-3