Howard C. Berkowitz wrote: > snip
> > 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. Hmmm. I would like you to get better sales, of course, but please don't fall for the dummy books mentality. :-} If it were economically feasible, I would like to see publishers of professional books show some backbone and market highly-technical books for smart people, not just books for newbies. snip > 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. Cisco instructors used to (may still) insist that the students keep their hands off the keyboard while the instructor was talking. I always thought that hindered learning, (well, unless the students were busy creating a horrible message of the day on other people's routers! ;-) I like your approach of structured do-along mini labs as you go, rather than (or in addition to) one major lab at the end of each section. By the way, another tangent: I think the instructors who insist on no hands-on while the instructor is talking are the type that probably don't make good course developers. One mistake that many companies and publishers make is to let instructors write. A lot of them can't. They excel at oral communication skills, but in some cases, not at written communication skills. A lot of them don't have the patience to do the analysis up front either. They think they can just put what they say in class down on paper and that will make a good book or course. Some instructos, like Clare Gough, for example, make great authors and developers. Some do not, though, which is one minor explanation for some of the bad material out there. Priscilla > > 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=60121&t=60111 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
