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

From: "sujay gupta" <[email-masked]>
Date: Thu, 8 Mar 2007 17:35:15 +0530

Hi,
Please find some comments inline.

On 2/26/07, Acee Lindem <[email-masked]> wrote:
>
>
> 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.
> >> Albeit I am work for no service provider, there are situations one
> already

being referred to by Abhay in a separate thread where a helper termination
could
be useful, I would like to have helper feature disabled by default on all
core routers for
example, perhaps even more on access routers to backbone.

Acee, modifying flooding to reach that one-shot signalling was not captured
in the draft
but then thanks for giving this thought :)

- 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).

>> While it is always better to have a conservative approach and 3623

does the same when  Strict LSA  Checking  is enabled.
But then the update has proposed a less conservative approach which also
happens to be in the wish list"

7.  Possible Future Work
   Devise a less conservative algorithm for graceful restart helper
   termination that provides a comparable level of black hole and
   routing loop avoidance."

A middle path approach that of avoiding some LSA's and using the SPF as a
means
of decision making should be optimum.
However the real need for an alternate mechanism, is best left to the WG.

Thanks,
Sujay

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

---

From: "Abhay D.S" <[email-masked]>
Date: Fri, 09 Mar 2007 14:16:49 +0800

Acee and Sujay,
Even Stub Router.
I am helper, but I am also stub router for a while. :-). this is something
we might have overlooked.
Best Regards,
Abhay

sujay gupta wrote:
> On 2/26/07, *Acee Lindem* <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>     >> Albeit I am work for no service provider, there are situations
>     one already
>
> being referred to by Abhay in a separate thread where a helper 
> termination could
> be useful, I would like to have helper feature disabled by default on 
> all core routers for
> Acee, modifying flooding to reach that one-shot signalling was not 
> captured in the draft
> A middle path approach that of avoiding some LSA's and using the SPF 
> as a means
>     [email-masked] <mailto:[email-masked]>
>     <https://www1.ietf.org/mailman/listinfo/ospf>
>
>
> ------------------------------------------------------------------------
>

---

From: Abhishek Bhalotia <[email-masked]>
Date: Tue, 13 Mar 2007 14:33:39 +0530

Hi,

Having implemented/worked on a prototype and been thru this draft, we do
find some value in the update draft. 

I have some comments inline.

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]] 
Sent: Monday, February 26, 2007 9:49 PM
To: OSPF List
Subject: [OSPF] draft-holla-ospf-update-graceful-restart-02.txt

>>(I would typically avoid a helper when my routers are running at a core
backbone network, where i would like the traffic to divert around the
restarting router on failures asap. Add to it the helper routers vendor ship
it with default helper enabled. If I disable one helper , and explicit
signaling is used (as in the update) , all helpers would be immediately out
of helping mode, which is of convenience to me ! 

w.r.t to mode of signaling , LLS signaling or the inconsistent LSA sending
is subject to WG discussion, a pointer here our prototype does not use

inconsistent lsa as a mode post the nbr relationship is FULL. for two valid
reasons first, the specs do not talk about it ;second, the restarting router
post becoming FULL with the nbr probably does a nbr count change and doesn't
expect anything odd from it , It just waits on for the timer to expire or
the nbr count to be the expected, if you do send any form of signaling post
the relationship being full, i don't expect it, i don't handle it. a
behavior could be defined.)

graceful restart.

does).

>>(Well yes and no!, the spf check methodology combined with the third
flavor *could* be less CPU intensive rather than the plain spf checks, while
i dont see a real requirement for this  there are some lsa's which can be
clearly skipped)

Thanks, 

Abhishek

Thanks,

Acee

OSPF mailing list

[email-masked]