[email protected]
[Top] [All Lists]

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

Subject: Re: draft-zinin-microloop-analysis-01.txt - times
From: Alex Zinin
Date: Fri, 3 Jun 2005 12:09:14 -0700
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>