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 PROTECTED] Sent: Monday, February 26, 2007 9:49 PM To: OSPF List Subject: [OSPF] draft-holla-ospf-update-graceful-restart-02.txt 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. >>(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.) - 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). >>(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 protected] https://www1.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ospf
