[email protected]
[Top] [All Lists]

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

Subject: Re: draft-zinin-microloop-analysis-01.txt - times
From: Alia Atlas
Date: Fri, 03 Jun 2005 17:06:33 -0400
I like the former as well.  The latter makes me a bit nervous.

Alia

At 03:09 PM 6/3/2005, Alex Zinin wrote:
Stewart, et al-

 Do you guys mean

  - announcing values of configurable delays that are only changed
    by an admin action OR

  - announcing results of router's dynamic delay measurements?

 I would rather we not go in the latter direction.

--
Alex
http://www.psg.com/~zinin

Friday, June 3, 2005, 10:42:22 AM, Stewart Bryant wrote:


> Alia Atlas wrote:

>> At 12:05 PM 6/3/2005, mike shand wrote:
>>
>>> At 11:36 03/06/2005 -0400, Alia Atlas wrote:
>>>
>>>> Stewart,
>>>>
>>>> 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
>>>> DELAY_TYPEC and DELAY_TYPEB.
>>>
>>>
>>> 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
>>> statement
>>>
>>> "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.

> Stewart

>>
>> 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
>> ASAP.
>>
>> Alia
>>
>>
>> _______________________________________________
>> Rtgwg mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rtgwg
>>
>>


_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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