I'm pretty far away from the "purchasing lab scenarios or the time to practice them" point(so many printed words, only one lifetime), but one frustrating theme permeating all of the vendor-endorsed training I've been forced to attend (note: it was always the case that I would ask for training during my first 6-12 months of exposure to a technology, get denied, and then be required to attend the lowest possible level training a year later), is that they offer one or two solutions to a given troubleshooting/design problem. While they might come up with some acceptable reasons for their solution, wouldn't it be better to provide scenarios where multiple solutions exist for a given set of base requirements and the solutions manual outlines all acceptable options, comparing & contrasting them with one another, highlighting the merits of solutions that go above & beyond the original motives according to generally accepted principles of network design?
----- Original Message ----- From: "Lupi, Guy" To: Sent: Friday, April 19, 2002 6:07 PM Subject: RE: Scenario Design: Comments Invited [7:41955] > Exactly. A technology learning scenario might benefit from having hints and > suggestions there for you. A lab scenario should have no explanation > whatsoever in the scenario itself, it should be just as vague as the real > thing. At the end of the scenario though, in the solution, I would > definitely benefit from an explanation of why a particular method was used, > I believe others would too. > > ~-----Original Message----- > ~From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] > ~Sent: Friday, April 19, 2002 5:25 PM > ~To: [EMAIL PROTECTED] > ~Subject: RE: Scenario Design: Comments Invited [7:41955] > ~ > ~ > ~At 5:00 PM -0400 4/19/02, Lupi, Guy wrote: > ~>The biggest problem I have with scenarios out there is that > ~the solutions > ~>are not explained in enough detail. I suppose something > ~could be said about > ~>the requirement to then go look up a particular command and learn it > ~>yourself, but part of the reason you have the scenarios is so > ~that you can > ~>learn. Nothing irritates me more than to go through a lab, > ~look at the > ~>solution and find that the author solved it in a completely > ~different manner > ~>than you did, with no explanation. This is especially > ~important when there > ~>is more than one way to come to a working solution. A lot of > ~times there is > ~>a perfectly valid reason to use the method in the solution, > ~but the reasons > ~>are sometimes very hard to see, especially if you are not > ~well versed in the > ~>technology. Some scenarios could be significantly improved > ~if they gave the > ~>reason behind a particular method used. > ~ > ~Excellent point. There is utterly no question you are right for > ~technology learning scenarios. As far as lab practice scenarios, > ~however, there's been a tendency in commercial labs not to do so, > ~because Cisco doesn't do so. Perhaps more correctly, Cisco doesn't > ~do so any more, with the one-day format. > ~ > ~Would you agree that this sort of explanation should be done only at > ~the very end of the lab, as distinct from "hints" that may be > ~available during the scenario? > ~ > ~Let me throw out an example and see if it's a way of approaching it. > ~I've written three scenarios, each of which has the same first step: > ~establishing BGP connectivity to two POPs of the same ISP. > ~ > ~Next, you are directed to implement load sharing, with certain of the > ~address space preferring each POP. There are three variants, > ~deliberately being a bit vague in the instructions. > ~ > ~One says, for example,."you cannot use any method that adds addresses > ~or manipulates AS information." In other words, I expect the student > ~to know that a MED is the only general option remaining (ignoring > ~ISP-specific communities). > ~ > ~Another says "you may not manipulate addresses or metrics." It's > ~looking for AS path prepending. > ~ > ~The third is written to look for more-specific and summary addresses. > ~ > ~I've set up hints in each one, which really say the same thing...the > ~hints are multiple levels of questions, only giving a specific answer > ~at the end. By the time you are through the hints, you will have > ~reviewed the three possible options. > ~ > ~ From what you are saying, it sounds like a technology-learning > ~scenario would do well with the hints, but a lab-practice scenario > ~should simply consolidate these explanations at the end. Is that a > ~fair interpretation? > ~ > ~Thanks, > ~ > ~Howard > ~ > ~ > ~ > ~ > ~Report misconduct > ~and Nondisclosure violations to [EMAIL PROTECTED] > ~ Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=42036&t=41955 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
