I agree that CID should include a product catalog. Teaching CID was so much
easier if a few students had a catalog with them (or access to the online
one). We should have made sure it was part of the bill of materials for the
class.
When I developed Designing Cisco Networks, I introduced the idea of job
aids. Job aids include product information, capacity planning data and
tools, scalability constraints for various technologies, etc. The original
DCN had lots of charts for this purpose. They were separate from the
reading material and were meant to be something a designer could reference
when needed. Over the years, someone has been merging the job aids into the
course and even testing on the minutiae in the job aids on the DCN test.
This is ridiculous. Why should anyone in their right mind memorize the size
of a RIP header, for example? Anyway, don't get me started.
I think testing design skills is possible, even though it is an art as well
as a science. I haven't heard why the CCIE design test fell apart. It
seemed like a good idea and reasonable implementation. It would probably
take a Howard-level person to get it right though, and that would be hard
to find. &;-)
Priscilla
At 04:21 PM 3/1/01, Howard C. Berkowitz wrote:
> >One skill required of designers, that can be measured in a lab
> >environment, is the ability to specify appropriate equipment for the
> >proposed technologies to be implemented. The designer needs to be
> >able to specify a product that supports the proposed design.
> >
> >Remember that the CCIE Design measures the candidates ability to
> >design *CISCO* networks - recommending technologies appropriate to
> >the scenario limitations and then recommending Cisco hardware
> >appropriate to the technologies.
>
>When I taught CID, I had a running argument with Cisco that it was
>far more important to put a current catalog and price list into the
>student kit than, say, a command reference. I was always told this
>was too expensive.
>
>But, to refer back to your point about *CISCO* networks, pricing
>(and, for that matter, relevant discounts and support costs) is more
>important, IMNSHO, than the ability to configure a representative
>system in the lab (if you can -- see below).
>
>In designing real networks (not solutions -- also see below), the
>cost-effective way to do things isn't necessarily the most elegant.
>For example, the conventional wisdom is to "pick the best box" to
>meet some set of requirements. But a single best box isn't
>necessarily the most cost-effective.
>
>This is going back a bit, but I remember several cases I had where
>there was a need to do assorted SNA stuff. It needed more token ring
>interfaces than were available on a small platform, so the school
>solution was to use a 7000.
>
>But the 7000 didn't have that fast a CPU, only a 68040. In contrast,
>a 2500 series has only a 68030, with a speed of 0.5 relative to the
>68040 in the 7000.
>
>But by stacking four 2500's, I could get 4 or 8 TR interfaces, with
>twice the CPU power of the 7000.
>
>In a different scenario, I had lots of RSRB circuits to be
>terminated. They were TCP encapsulated, so that took lots of CPU.
>There was a need to use an IBM channel interface, which only plugged
>into a 7x00 router. To get the necessary CPU power, the school
>solution was to use a 7500. But a better approach, for the specific
>customer, was to use a 7010 with a CIP card and a Fast Ethernet card,
>using the FE card to link to a 4700 that handled the TCP sessions.
>
> >
> >Can technology X be implemented on Cisco platform Y? If so, how? Are
> >there caveats, tradeoffs, or flaming hoops to jump through in order
> >to get product Z to effectively run feature A, B, and C at the same
> >time?
> >
> >I think that this is the approach that Cisco is taking with the CCIE
> >Design track. Certainly designers are not expected to be responsible
> >for implementing and maintaining hardware, but they need to be
> >certain that their designs CAN be implemented on the hardware
> >available (in this case, Cisco's), and one good way to determine if
> >a person knows this is to have them do it, at least once, in the lab.
>
>But in a practical amount of time in the lab, how many devices can
>you configure? Even a relatively small network might have dozens of
>access routers, several distribution points with distribution routers
>plus switches for regional servers, and a core. At what point is a
>lab setup using a lesser number of devices going to validate both
>functionality AND WORKLOAD/PERFORMANCE?
>
>If I were going to require anything along a lab, as opposed to, say,
>a presentation before qualified designers, I'd much rather the
>demonstration use a block-level simulator such as BONES. Netsys is
>at too fine a level, because it depends on configurations.
>
>
> >
> >With this in mind, I think that Cisco is right on track.
> >
> >Z
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
________________________
Priscilla Oppenheimer
http://www.priscilla.com
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
