[email protected]
[Top] [All Lists]

Re: draft-zinin-microloop-analysis-01.txt - times

Subject: Re: draft-zinin-microloop-analysis-01.txt - times
From: Stewart Bryant
Date: Fri, 03 Jun 2005 18:42:22 +0100

Alia Atlas wrote:

At 12:05 PM 6/3/2005, mike shand wrote:

At 11:36 03/06/2005 -0400, Alia Atlas wrote:


At 11:31 AM 6/3/2005, Stewart Bryant wrote:

I don't like the idea of requiring consistent configuration across the
network, because there is a strong chance that it will be wrong, and
it's always a problem when it has to be changed because of the inclusion
or removal of a particular router. There is also the issue that the
parameter is in some sence dynamic, being dependent on the size of the
network so it's going to need to be tuned as time goes by.

Nor do I much like the idea of requiring an NMS to se the parameter
because not all networks have an NMS that is responsible of the
configuration of the routers.

I suggest that each router includes it's max required time in its
LSP/LSAs and the network uses the max of the max. The parameter
can be extracted as part of the SPF calculation. Since, for the
topology calculation to be consistent, all routers have to be
using the same set of active links in their calculation we know that
they will all extract the same maximum value for delay. If the network
is unstable in such a way that not all routers are using the same links
to claculate the SPT, then we have bigger problems.

A standard concern is the inclusion of removal of large sections of the
network changin the parameter, but this comes out in the wash, provided
the algorithm (at least conceptually) is to find the max value during
the parsing of the active links.

A futher standard concern is what happens when a value changes. When a
router is re-configured it issues a new set of LSPs with the new timer
value. However this has a null effect on the topology, and we can
expressly prevent a transition taking place when a router issues an
LSP in which the only change is the ephoch time request.

There is the issue concerning inconsistency during the window where one
router has issued a time change LSP and concurrently a failure occurs.
This is probably better, and certainly no worse than a failure occuring
during a time in which the NMS is issuing a timer value change to
the routers in the net.

I think that this could be a very nice solution to the problem. I really like it :-)
If each router advertises its max compute-install time (which could
be configured or derived), then all routers could compute the max,
possibly add a small certainty factor and use that for the

Yes, I agree that such an automatic dynamic scheme would be very nice IF it were unconditionally stable. Stewart's arguments seem convincing, but I have been burnt too often in the past by such things to immediately accept that it will never cause any problems:-)
I don't THINK it will, but I think it needs a bit more analysis of
nasty cases to be sure that there aren't any situations where it could
make bad things happen, or in particular make more bad things happen
than if we hadn't done it.
I do agree that SOMETHING needs to be done, since the consequences of
getting it wrong manually are clearly pretty severe, and changing a
value manually is a real pain.
I think it all boils down the veracity (or otherwise) of Stewart's
"If the network
is unstable in such a way that not all routers are using the same links
to claculate the SPT, then we have bigger problems."

If indeed we do have bigger problems, then this is probably all OK. But if the problems introduced by an unsynchronized topology are actually much LESS than the problems caused by using inconsistent delay values (long persistence of loops), then maybe it is not such a good idea.

A good cautionary point and certainly we need to think about it a lot more, but it does seem like a very promising way of solving what we seem to agree is a problem.
Thinking it over a bit more, if the time advertised by a router
dynamically changed as a result of the number of routes to be installed,
I think I might be concerned - but I'm not sure if my concern is well
grounded. I think the concern would be because of the potentially
larger number of updates that might occur as a result of a single change.
When I said about dynamic, I was thinking on a very course, rarely changed
scale, as much dependent on the OS version, or the mix of vendors as the
gross size of the network.


I do think that because of the DELAY_SPF, all routers should have heard
the same updates before computing & so should be working on the same
exact topology with the same set of max-install-times.
Another interesting aspect might be the partial deployment scenarios
that could benefit from this. For instance, if a router doesn't
advertise its max-install-time, then that router can be presumed not to
support PLSN. Possibly at some point, one could even say that the
router could be presumed not to support IPFRR - so if the topology
change was a failure was local to that router, then revert to converge

Rtgwg mailing list
[email protected]

Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>