Subject: [OSPF] draft-holla-ospf-update-graceful-restart-02.txt

From: Acee Lindem <[email-masked]>
Date: Mon, 26 Feb 2007 11:18:33 -0500

I don't think we've reached resolution on this draft. Here is my take:

  - Explicit helper refusal to participate in graceful restart

There are situations where an explicit notification would be faster  
than the RFC 3623 case of the helper originating an inconsistent  
LSA.  The updated draft lists alternatives for this that are  
acceptable (IMHO, modifying LSA flooding to support one shot  
signaling was not :^). I'm not really sure the scenario where the  
helper is configured not to help makes that much sense (other than in  
a test lab). An OSPF routing domain is under a single administrative  
domain and why would someone configure OSPF routers to attempt to  
restart gracefully while configuring their neighbor not to help.

- Classification of LSA changes as to whether or not they terminate  
graceful restart.

Right now we have two levels  1) LSA changes that would be flooded to  
the restarting router will terminate graceful restart and, 2) LSA  
changes do not terminate graceful restart. Irrespective of the RFC  
3623 default, most implementations default to the latter. This drafts  
proposes a third flavor that attempts to classify changes and  
terminate graceful restart in the presence of changes to previously  
advertised links and prefixes but not new information. I think this  
is broken since new information can cause a routing loop as well.  
Furthermore, I don't see a real requirement for an alternate flavor.  
And, if there was to be a third flavor, it should be the the  
variation Vishwas Manral suggested even though it is quite CPU  
intensive (determine whether the new LSA information changes a route  
to the restarting router and terminate graceful restart only when it  
does).

Thanks,
Acee

_______________________________________________
OSPF mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf

---

From: "Abhay D.S" <[email-masked]>
Date: Wed, 28 Feb 2007 11:25:16 +0800

hello acee,
The scenario where in helper router is configured not to support even if 
they belong to the same administrative domain
is when we are using critical real-time traffic which is on-demand.

1) Except in controlled conditions, almost all graceful re-starts are 
partial re-starts.

2) If router was using more than just IP forwarding, towards re-starter 
and also had level 2 or mpls forwarding on backup peer
    it can refuse helping re-starter.

Here refusal has two meanings:
1) Refusal to use the black holing and route looping behavior of 
re-starter (which is ofcourse temporary)

2) Allow the other peers of the re-starter to avoid the non-helper 
router via the re-starter such that traffic can still flow around the 
re-starter
    to the non-helper.

Explicit notification is quicker to accomplish refusal meaning 1 and 2.

In simpler words, if I am helper, I would say, I have lots of bursty 
on-demand traffic, there are lots of users dialing in becoming my peers 
for sometime
and then hanging up. I have backup paths towards same destinations 
(probably switched paths). I want less delay variation on my traffic.I 
dont want
to be busy helping re-starter give back routing information and updating 
my caches, when I have already had working backup caches. Also as a policy
after your first re-start I will not use re-starter for quite sometime 
as my next hop till I become stable with my topologies.

With Regards,
Abhay

Acee Lindem wrote:
> than the RFC 3623 case of the helper originating an inconsistent LSA.  
> The updated draft lists alternatives for this that are acceptable 
> (IMHO, modifying LSA flooding to support one shot signaling was not 
> :^). I'm not really sure the scenario where the helper is configured 
> not to help makes that much sense (other than in a test lab). An OSPF 
> routing domain is under a single administrative domain and why would 
> someone configure OSPF routers to attempt to restart gracefully while 
> configuring their neighbor not to help.
>
>
> advertised links and prefixes but not new information. I think this is 
> broken since new information can cause a routing loop as well. 
> And, if there was to be a third flavor, it should be the the variation 
> Vishwas Manral suggested even though it is quite CPU intensive 
> (determine whether the new LSA information changes a route to the 
> restarting router and terminate graceful restart only when it does).
>
>
> Thanks,
> Acee
>
>
>

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 Feb 2007 14:57:05 -0500

Hi Abhay,

On Feb 27, 2007, at 10:25 PM, Abhay D.S wrote:

>
> hello acee,
> The scenario where in helper router is configured not to support  
> even if they belong to the same administrative domain
> 1) Except in controlled conditions, almost all graceful re-starts  
> are partial re-starts.

This is not the case with the widely deployed implementations. Most  
implementations default to ignoring LSA changes and the restarts  
occur very quickly.

>
> 2) If router was using more than just IP forwarding, towards re- 
> starter and also had level 2 or mpls forwarding on backup peer
> 1) Refusal to use the black holing and route looping behavior of re- 
> starter (which is ofcourse temporary)
>
> router via the re-starter such that traffic can still flow around  
> the re-starter
>    to the non-helper.

Graceful restart is not designed to work with some FULL neighbors but  
not others. So, if you have cases where it won't work, you simply  
don't use it.

> Explicit notification is quicker to accomplish refusal meaning 1  

There is an explicit mechanism today - it is just dependent on the  
database exchange having started so, dependent on other factors,  
using an empty hello LLS could be quicker.

>
> In simpler words, if I am helper, I would say, I have lots of  
> bursty on-demand traffic, there are lots of users dialing in  
> becoming my peers for sometime
> (probably switched paths). I want less delay variation on my  
> traffic.I dont want
> to be busy helping re-starter give back routing information and  
> updating my caches, when I have already had working backup caches.  
> Also as a policy
> after your first re-start I will not use re-starter for quite  
> sometime as my next hop till I become stable with my topologies.

If implementations have such policies then not requiring state >=  
EXCHANGE to notify the restarting router would be faster. Do you know  
of OSPF graceful restart implementations that offer this option?
Thanks,
Acee

>> There are situations where an explicit notification would be  
>> faster than the RFC 3623 case of the helper originating an  
>> inconsistent LSA.  The updated draft lists alternatives for this  
>> that are acceptable (IMHO, modifying LSA flooding to support one  
>> shot signaling was not :^). I'm not really sure the scenario where  
>> the helper is configured not to help makes that much sense (other  
>> than in a test lab). An OSPF routing domain is under a single  
>> administrative domain and why would someone configure OSPF routers  
>> to attempt to restart gracefully while configuring their neighbor  
>> not to help.
>>
>>
>> - Classification of LSA changes as to whether or not they  
>> terminate graceful restart.
>>
>> Right now we have two levels  1) LSA changes that would be flooded  
>> to the restarting router will terminate graceful restart and, 2)  
>> LSA changes do not terminate graceful restart. Irrespective of the  
>> RFC 3623 default, most implementations default to the latter. This  
>> drafts proposes a third flavor that attempts to classify changes  
>> and terminate graceful restart in the presence of changes to  
>> previously advertised links and prefixes but not new information.  
>> I think this is broken since new information can cause a routing  
>> loop as well. Furthermore, I don't see a real requirement for an  
>> alternate flavor. And, if there was to be a third flavor, it  
>> should be the the variation Vishwas Manral suggested even though  
>> it is quite CPU intensive (determine whether the new LSA  
>> information changes a route to the restarting router and terminate  
>> graceful restart only when it does).
>>
>>
>> Thanks,
>> Acee
>>
>>
>>
>> <abhayds.vcf>

---

From: "Abhay D.S" <[email-masked]>
Date: Thu, 01 Mar 2007 10:05:47 +0800

Hello Acee,
Agree that some widely deployed implementations have the default of 
ignoring lsa change and re-starts occur quickly which
is infact partial and transparent to most traffic watchers.

IMHO the  original implementation idea of Moy et al was to implement the 
policy on helper, the very reason the re-start reason was
included in the grace tlv.

The re-start reason given by the re-starter implements the policy on the 
helper.
1) Software Reset.
2) Unknown reason(probably hardware re-start) in this case I dont want 
to help re-starter.
3) Other reasons.

LLS Hello maybe used, but then you have to enable LLS processing and 
other configuration dependencies.
Grace LSA is anyway opaque.

With Regards,
Abhay

Acee Lindem wrote:
>> The scenario where in helper router is configured not to support even 
>> if they belong to the same administrative domain
> implementations default to ignoring LSA changes and the restarts occur 
> very quickly.
>
>
>>
>> 2) If router was using more than just IP forwarding, towards 
>> re-starter and also had level 2 or mpls forwarding on backup peer
> database exchange having started so, dependent on other factors, using 
> an empty hello LLS could be quicker.
>
>
>>
>> on-demand traffic, there are lots of users dialing in becoming my 
>> peers for sometime
>>> helper is configured not to help makes that much sense (other than 
>>> in a test lab). An OSPF routing domain is under a single 
>>> to the restarting router will terminate graceful restart and, 2) LSA 
>>> 3623 default, most implementations default to the latter. This 
>>> drafts proposes a third flavor that attempts to classify changes and