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 protected]
https://www1.ietf.org/mailman/listinfo/ospf
