Hi, Please find some comments inline. On 2/26/07, Acee Lindem <[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] https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
