Kireeti, Zafer:
I think that Zafer picked up on my earlier point that just because routing
is gracefully restarting an implementation may have an independent
LSP system that can function just fine so why be forced to penalize
it? On the other hand, you may have an LSP system that is linked
to routing such it must restart as well and then I would agree that
zeroing bandwidth may well be necessary( but somewhat less "graceful").
I'm not convinced changing Metrics is required at all.
So I would agree with Zafer the wording should be such that either
case is allowed,
Don
-----Original Message-----
>From: Zafar Ali [mailto:zali@cisco.com]
>Sent: Sunday, April 28, 2002 1:53 AM
>To: Kireeti Kompella
>Cc: ccamp@ops.ietf.org
>Subject: RE: TE metric and graceful restart
>
>
>Dear Kireeti,
>
>Thanks for the reply; Please see comments in-lined.
>
>At 10:01 PM 4/27/2002 -0700, Kireeti Kompella wrote:
>
>
>On Sat, 27 Apr 2002, Zafar Ali wrote:
>
>> The reason that I understood this as a MAY case is that a node that saves
>> bandwidth usage state information locally is able to determine (or
>> estimate) the amount of unreserved resources immediately upon start-up. In
>> which case it MAY advertise the saved (projected) value(s) during the
>> graceful restart period.
>
>Attractive as that may be, life is not so simple. The process of
>recovery for signaling is complex enough without having new LSPs set
>up during recovery. The idea of discouraging LSPs during recovery is
>not just that the recovering node doesn't know its unreserved bandwidth,
>but that it wants to complete recovery before setting up new LSPs.
>
>A simple example is that the recovering node X uses per-box labels,
>gets a new LSP request while recovering, and allocates label L to that
>request. But L is already in use for an existing LSP ....
>One can
>work around this particular example, but keeping it simple seems like
>a good initial goal.
>
>Agreed! As I also mentioned that in doing so the node looses the charm
>of discouraging other nodes in the network
>in using it, during the restart period. This opens doors for some
>potential race conditions and >scenarios like the one you mentioned
>in the email. Of course, a node that may choose to do so >has to deal
>with kind of scenarios that you mentioned in the email. I see that
>there are some tradeoffs involved and the standard should leave a
>room for exercising such options. Hence, IMO this should be a local
>(vendor specific) decision.
>
>In short, while I am agreeing with the recommendation, I think the
>"SHOULD" part should be >>removed and the standard should leave it as
>part of the local decision.
>
>Thanks
>
>Regards... Zafar
>
>>
>>
>>At least, that's my take.
>>
>>Kireeti.