The use of RIPng

[michael.dillon at bt.com]

> Half a year later, and with absolutely no reason to fiddle around with
> OSPF since the network works, something breaks.  Not having touched
> any OSPF for months, they have forgotten much of what they've learned
> and the only chance they have to find and fix the problem is to dig
> out those old training manuscripts, trying to recall what the relevant
> details of have learned.  All this under significant time pressure.


> What's worse, situations that you could cope with in a relaxed lab
> environment tend to turn out much more difficult to handle when they
> happen in production, because that's usually at 03:00 when you are dog
> tired, the colleague you desperatley need at the other end of the line
> 5000 km (3000 sm) away is down with flu and you're so pumped with
> adrenaline that most of whatever intelligence it leaves you can barely
> keep the fight or flight reflex at bay.

That's why you should not rely on the information in some training 
manuscripts from several months ago. Make an internal wiki, and
write down anything that is important on that wiki. Then when you
are troubleshooting, you can use a search tool to help you find the
relevant info. Because it is your wiki, and you intend for it to
be a support resource, when you implement OSPFv3, you will add
notes to the wiki as you go, noting what you did differently and
why.

>From time to time, look for interesting recipes and troubleshooting
notes from other people on the net and add them to the wiki, i.e.
copy any good bits from ipv6-ops emails.

> If you are too optimistic about your skills when you set up things,
> then you are likely to learn about your limits and those of your
> colleagues and successors the hard way.

In fact, it may be your successors who are doing the troubleshooting.

--Michael Dillon