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:
Hi,
Please find some comments inline.
On 2/26/07, *Acee Lindem* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
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 protected] <mailto:[email protected]>
https://www1.ietf.org/mailman/listinfo/ospf
<https://www1.ietf.org/mailman/listinfo/ospf>
------------------------------------------------------------------------
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
begin:vcard
fn:Abhay Rao
n:Rao;Abhay
email;internet:[EMAIL PROTECTED]
version:2.1
end:vcard
_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf
