From: Peter van Oene (pvo@usermail.com)
Date: Tue Feb 04 2003 - 20:15:45 GMT-3
At 10:26 PM 2/4/2003 +0000, Matthew Poole wrote:
>Thanks folks,
>I'm a toh-MAH-toes man myself being from good old blighty, my next attempt
>is also my first (and hopefully last) attempt.
>
>Obviously, Parnas did not say all information hiding is good, nor did he say
>that all information hiding techniques are equally useful. He was
>identifying a particularly pragmatic approach to information hiding. (sorry
>couldn't resist)! I'd never even heard of Parnas before today, something
>else I've learnt!
>
>One tip which I got privately was that if the question mentions having no
>type 5 LSA's then they're hinting that stub is necessary, but this wasn't
>the case on this lab. It did have a statement specifying to allow for
>redistribution within a stub network for another area, so obviously I went
>for NSSA.
>
>Peter - I'd like to know when more LSA's are a good thing? I'm only
>thinking of scenarios where the area only has one exit point, could you give
>me an example please?
With one exit point there isn't any benefit.
>Thanks again everybody for taking the time to reply.
>
>Mat.
>----- Original Message -----
>From: "Joe Chang" <changjoe@earthlink.net>
>To: <ccielab@groupstudy.com>
>Sent: Tuesday, February 04, 2003 5:41 PM
>Subject: Re: OSPF stub areas
>
>
> > Well, you say toh-MAH-toes and I say toh-MAY-toes. I hope we've confused
>Mr.
> > Poole sufficiently for his next attempt.
> >
> > ----- Original Message -----
> > From: "Howard C. Berkowitz" <>
> > To: <ccielab@groupstudy.com>
> > Sent: Tuesday, February 04, 2003 1:37 PM
> > Subject: Re: OSPF stub areas
> >
> >
> > > At 11:30 AM -0400 2/4/03, Joe Chang wrote:
> > > >For my own lab attempts I didn't follow such an approach. In
>programming,
> > > >over-designing something can lead to unforseen side-effects. I think
>this
> > > >applies to configuring routers as well.
> > >
> > >
> > > There's over-designing, but there's also designing for avoiding
> > > errors and enhancing troubleshooting and maintainability. In
> > > programming, the key concept of "information hiding" came from DL
> > > Parnas in 1968. The idea is to hide as much information from lower
> > > levels as possible -- less to get them confused and less overhead.
> > >
> > > Most good routing architects practice significant information hiding,
> > > although this doesn't always seem to be the CCIE Way, which freely
> > > admits it doesn't reflect best current practices. In the real world,
> > > stubbiness, defaults, aggregation, etc., all make things more
> > > scalable and reliable.
> > >
> > > It might be an interesting thing to put to the proctor -- "since
> > > there is no requirement for externals or virtual links in this area,
> > > is it acceptable for me to make it stubby to simplify its databases
> > > and make troubleshooting easier?"
> > >
> > > "Since this area either has only one ABR, or if there are no
> > > requirements to do end-to-end route optimization (i.e., closest exit
> > > is adequate), is it acceptable for me to make the area totally
> > > stubby?"
> > >
> > > >
> > > >----- Original Message -----
> > > >From: "Matthew Poole" <matthew.poole@blueyonder.co.uk>
> > > >To: <ccielab@groupstudy.com>
> > > >Sent: Tuesday, February 04, 2003 10:27 AM
> > > >Subject: OSPF stub areas
> > > >
> > > >
> > > >> More assumptions!
> > > >>
> > > >> Should I assume that OSPF areas should be configured as stubs if
> > eligible
> > > >to
> > > >> be so, although the lab doesn't specifically request it?
> > > >>
> > > >> I've just completed a lab and in the solution they did this - why
>not
> > take
> > > >it
> > > > > one step further and make it totally stubby?
> > > .
> > .
.
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:09 GMT-3