Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology Change LSAs and Helper Mode Exit

From: Vishwas Manral <[email-masked]>
Date: Thu, 15 Dec 2005 20:32:45 -0800

Hi,

> Vishwas, it would be nice if you could refresh the groups 
> memory with your suggestion. I am new to the group and have 
> missed out on the context and content of that discussion.
The discussion is around 4 years old, however let me try and summarize.
The idea is that only if the old or the new route went through the
restarting router and it changed from/ to the restarting router. Only in
such cases would we need to exit hitless restart. The above will cover
all cases of refresh LSA's etc. The exit from hitless restart should be
based on the change in the routing table and not just LSA matching.

Here is the link for details of proof: 
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0203&L=ospf&T=0&F=&S=&P
=1888

You could look at the thread as well as look at the previous discussion
on version-00 of the draft.

Thanks,
Vishwas
-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Ashok
Sent: Wednesday, December 14, 2005 8:37 AM
To: [email-masked]
Subject: Re: draft-holla-ospf-update-graceful-restart-00.txt - Topology
Change LSAs and Helper Mode Exit

Hi group,

The main objective of the topology change LSA definition is to achieve a
balance between unbroken forwarding and restricting the scope of false
GR exits.

The GR mechanism overrides the basic OSPF protocol behavior. All the
checks that have been put in place by OSPF are invalidated by the GR
protocol. GR thus necessitates some 'faith' on part of the routers in a
topology to adhere to the principle of reacting quickly to bad news. 
By disabling strict-lsa-checking, this 'faith' is lost. 
In several scenarios, disabling strict LSA checking will result in the
overall convergence time of OSPF routers being worse with graceful
restart mechanism than without it. This generally involves unstable
topologies and multiple failures. Perhaps, the service providers have
not had such scenarios occurring and as a result, have not asked for
such changes. 

However, the protocol must address this possibility. My concern with the
existing mechanism is that taking policy decisions like disabling strict
lsa checking is incorrect, since we cannot decide the significance of a
topology change apriori. It could lead to extended downtimes, which
would not have been the case if GR mechanism was not in place. 

While this is true, what is equally true is that in large networks, many
changes keep occurring. Links and routers toggle, policies changed and
new routes learnt. This problem is amplified when there are different
service providers operating in the same space. Clearly, many of these
changes may be irrelevant to the neighborhood of a gracefully restarting
router and must not play a part in forcing GR exit. By enabling
strict-lsa-checking, this objective is undermined.

Therefore I feel that there is a need to make the protocol less
conservative and more intelligent, while retaining the
strict-lsa-checking. 

The exact method of achieving this is perhaps still debatable. We have
suggested a method with a bias towards maintaining unbroken forwarding.

Vishwas, it would be nice if you could refresh the group's memory with
your suggestion. I am new to the group and have missed out on the
context and content of that discussion.

Regards,
Ashok

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Acee
Lindem
Sent: Wednesday, December 14, 2005 10:21 AM
To: [email-masked]
Subject: draft-holla-ospf-update-graceful-restart-00.txt - Topology
Change LSAs and Helper Mode Exit

<Speaking as WG member>

The draft proposes  sub-classification of  LSA changes for determining 
whether or
not a helper should terminate graceful restart. RFC 3623 currently has 2

modes:
        
           1. Strict LSA Checking - Any changed LSA which would be 
flooded to the restarting
                router will terminate graceful restart.
           2. Changed LSAs will not terminate graceful restart (the 
default for most vendors).

The draft further classifies LSA changes as constituting a topology 
change (in an effort to
reduce the cases where graceful restart must be terminated). For 
example, a new LSA or
new link added to a router LSA would not cause GR termination. I have 
the following
concerns:

        1. Are people asking for this? Most vendors default to #2.
        2. New LSAs can cause the same problems as topology changes to 
existing ones.
            Consider the installation of new more specific routes - the 
characterization of new LSAs
            or "good" news being innocuous and "bad" news terminating 
grace restart seems
            arbitrary.  The draft suggests monitoring all route changes 
involving next hops
            of the restarting router to avoid this problem.
        3. Although my memory is weak, it seems to me that Vishwas' 
previous proposal
            was more robust. If there is a requirement for some level of

LSA checking but less
            conservative than any LSA flooded to the restarting router 
than we should consider
            that one as well.

Thanks,
Acee