>what's more amazing to me is the disproportional importance the
>certification materials place on this kind of stuff. We all read the ad hoc
>statement in Lammle or other guides that EIGRP is a hybrid protocol with
>characteristics of both DV and LS. Of course nowhere in the materials we
>read are there the kind of detailed explanations, detailed foundations,
>which support these ad hoc statements.
The only way I can rationalize some of this is that misinformation
has crept into Cisco course materials, Cisco exams are based on the
courses, and some of the certification review authors are (without
violating NDA) trying to put out the Cisco correct answer.
I'm often amazed when I get an argument about something in a review
book, when my source on the subject might be John Moy on OSPF (more
below), or Tony Li or Sue Hares on BGP, etc. Hey--I really do go to
IETF meetings, comment on and write RFCs, monitor the lists, and
often know the person who writes the code -- or in the case of
Nortel, can go look at the code.
That's not to say the primary sources always are clear. I'm involved
in a team writing Internet-Drafts for single-router BGP convergence
terminology and methodology. (before people ask, they will be
available, probably a few days after July 13th, as
http://www.ietf.org/draft-ietf-bmwg-
I'm the lead author, but I have very close collaborators: Alvaro
Retana from Cisco's scalability lab, Sue Hares (vice-chair of the BGP
working group) and Padma Krishnaswamy from Nexthop (the source of
GateD) and Marianne Lepp from Juniper. Others are reviewing the
material as well. We are finding that a fair number of terms (e.g.,
RIB and FIB) aren't rigorously defined in any document. We are also
filling in the detail on EXACTLY how certain BGP exchanges take place
-- not so much what the individual events are, but how streams of
updates get constructed. Things aren't as black-and-white as we
might wish. People that write RFCs and implement code often have to
stop and think, and that level of knowledge isn't necessarily
available to a review book writer.
>
>
>Fact is, Cisco promulgates a certain outlook, most of which is accurate
>enough that it makes little difference for all practical purposes. Cisco
>isn't the only one, either. As a result of an argument elsewhere, I had
>reason to delve into the esoterics of OSPF virtual links, and the nature of
>tunneling. My research and resulting opinion have put me square in
>opposition to statements made in Doyle, Moy, and the RFC itself.
Several suggestions here. One, if Cisco is behaving differently from
the RFC, I think the developers would like to know. Unless you know
the individual people and have name recognition with them, the best
thing is to write up the concern and send it to [EMAIL PROTECTED] This
is an intelligent mail exploder that will route the message to
relevant developers, testers, etc. It is NOT a support channel and
may or may not get a response. On the other hand, when I had a
specific RFC interpretation question in OSPF, I happened to know the
lead developer at the time, and I got very quick responses and
explanations on how and why Cisco didn't implement the letter of the
RFC.
If you feel the RFC itself has an error, send in your observation to
the OSPF working group. As long as people aren't asking
vendor-specific support questions, it's a pretty friendly mailing
list.
>I continue
>to believe that certain comments were made to provide a conceptual
>framework, not to state truth about how things really work. I also learned
>that Moy himself, while using the term tunnel in his 1998 book, makes no
>such reference in his 2001 book, leading me to believe others may have
>suggested to him that there was misunderstanding due to his earlier
>statement. But that debate continues because after all, there it is in print
>from an expert.
I've talked to Moy about the history of VLs. He invented the idea to
solve the problem of an area with no physical connection to area
0.0.0.0. The technique of healing a backbone partition by using a VL
with both ends in area 0.0.0.0 came later.
The early documentation and implementation of VLs were buggy, so
people tended to avoid them. As a consequence, the VL code was
exercised less frequently, and simply wasn't understood as well.
When we were doing the 11.2 revision of ACRC, I argued quite
forcefully that VLs should not be added to the OSPF chapter. In CID,
we were advising people not to use them; that there are usually
better ways. The TAC insisted that VLs be included in ACRC, on the
basis that they got lots of support calls about them. Of course, by
putting them into ACRC, more people tried to use them. For the TAC,
this may have been a case of "be careful what you wish for--you might
get it."
>
>I believe there are more important things to know than which protocols are
>link state and which protocols are distance vector.
In my day job, I actually do look at choices in routing algorithms
and protocol design. When I taught Cisco classes, if someone would
ask "well, what if OSPF did X rather than Y," my usual answer would
be "it wouldn't be OSPF any more, and thus is outside the scope of
this class." Now, when I wear my IETF hat, I can look at
changes--but even there, they are primarily incremental and
operational (most often in BGP).
The focus in the Cisco certification programs -- both design and
support -- should be on how to work with the protocols as they are,
and only have enough detail of the internals to understand their
functionality, and know things useful in troubleshooting.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=11387&t=11273
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
