At 6:04 AM +0000 1/2/03, The Long and Winding Road wrote: >I picked up William Parkhurst's book Cisco OSPF Command and Configuration >Handbook for the sole reason that I own and have used with great success his >BGP book of similar title. BGP has been my most successful section in the >CCIE lab twice now, with my most recent result being perfect, due entirely, >IMHO, to my thorough study of the BGP book. I believe I have a pretty good >understanding of the fundamentals of OSPF, but the biggest room in the world >being the room for improvement, I thought I might find some merit in the >OSPF book as well. > >So far I have not been disappointed. I have gone through several of the >chapters now, and I am finding the format, the methodology, and the examples >extremely conducive to my learning process.
As you and Parkhurst suggest, different styles work for both authors and readers. I haven't read Parkhurst's OSPF, but I do have his BGP. There's also a commercial factor here. The market generally wants cookbook-style, command-oriented books. Personally, I don't think that's the best way to learn, but I'm now exploring that with a colleague simply in the interest of getting better sales. > >Some people can read RFC's and actually understand them. I struggle. Some >people can read the CCO configuration guides and comprehend. After a One of the real tricks is knowing which RFC to read first. For example, I didn't truly understand BGP until I read the RPSL documents, even before they were RFC's (e.g., RIPE-181). As you know from my own BGP-related tutorials and books, I start with the problem definition and then move to protocol mechanisms. Even in my current BGP performance Internet Drafts (of which I really _have_ to get the final editing done to reflect the IESG comments, so they can go to RFC), I tend to start with problem analysis. Even there, it's often useful to start with an "applicability document" before getting into the protocol RFC. The OSPF performance team, Manish Vishwas and Russ White, started with the technology draft but very quickly put out an applicability document. Whenever you find a protocol RFC also has an applicability document, read the latter first. Also, it's often a good idea, when reading a protocol RFC, to read the first few sections, and then, when it starts getting into the message formats and state machines, jump to the appendices. The appendices often contain tutorial information and examples. As far as getting into the guts of OSPF, this came in a galaxy long ago and far away, when I was getting my original CSSI directly from Cisco. During my "apprenticeship," it became clear I went more deeply into addressing than some of the other instructors, and also had the theoretical training to understand the Dijkstra algorithm. Before too long, I was passed along to the Cisco OSPF development lead, then got involved in the IETF mailing list and working group. Obviously, that isn't a scalable solution. For my way of learning, John Moy's first OSPF book goes nicely into some of the design assumptions, especially when contrasted with Radia Perlman's book and its ISIS design assumptions. John and Radia play very nicely in person, but, if there's a two-way choice in link state design, it is almost a given that they will each like a different chice. >couple >of years, I still have mixed results. Parkhurst himself says in the >introductions to both books that documentation is the one thing in common >among all who experience frustration during the learning process - >specifically amount, clarity, and completeness. His books are his way of >addressing those shortcomings. > >Now it can't be easy writing this kind of a book. It is the result of a lot >of boring setup and example creation, along with innumerable screen shots of >actual router output. The work had to have been a grind after a while. Every >command is listed, along with each switch to that command. An explanation of >the command is given, followed by a stated purpose for the command. Then lab >configuration examples are given, booth before the execution of the command, >and after, so that you can see the result. If you are following along in >your home lab you can compare your result to the book result. And that's where I differ. I want to be able to design using the functionality, then the commands, then testing the commands, rather than trying them one-by-one. In my live classes on advanced OSPF, I tried a compromise. As opposed to the regular Cisco approach of giving a configuration problem to individuals or a small group, I generally preferred to have the entire class do a configuration command or two at a time, then display various show and debug output until people realized the internal effects of those commands. Different strokes for different folks. > >the book is divided into chapters, each containing all the commands related >to a particular aspect of OSPF. For example, there are chapters on process >configuration, area commands, route filtering, timers, interface commands, >and summarization, to name a few. some chapters are obviously shorter or >longer than others. examples abound. many examples can be worked with only >two routers. no example I have seen as yet requires more than four routers, >although YMMV depending upon the numbers of interfaces of particular types. One of the tricks of practice labs is the incredible economy of scale that can come from a small number of route-generating, proctor-controlled routers that feed student pods. It might even be worth exploring a distributed approach to this, where the "route servers" connect to remote student pods via Internet tunneling. L2TPv3 would be ideal for this, but is not widely deployed, so it would probably need to be GRE. Still, you might be able to terminate the GRE on your local FR switch and fan out the VCs. > >I've even found a couple of interesting things as a result of using the book >that I am unable to confirm or deny as a result of reading the >documentation. I plan on providing a documented example maybe this weekend, >when I turn things back on again. it revolves around authentication. > >the only disappointment I have so far is the coverage of OSPF over frame >relay. The basics are covered quite well. It does not appear to go into the >many variations that are possible. I will be spending some router time with >this section over the weekend as well. I have tried to come up with an analogy for the behavior of routing protocols over frame relay, but I can only come up with limericks unsuitable for a Family Mailing List. :-) > >Howard attempted to get a discussion going earlier this week about practice >lab design assumptions, something that has so far drawn little attention ( >as opposed to the CCIE versus college degree thread that just won't die ) >I'd kinda like to see a discussion of book writing / training material >writing design as well. Well, consider this a start. >I personally believe the Parkhurst method, while >maybe not the be all and end all of study materials, packs a lot more into >it's pages than most others I have read. I wish there were more like the two >Parkhurst books. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=60111&t=60111 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
