Uma – I think I have addressed this in my previous reply on this thread, but just to be sure nothing is left unaddressed…
The bis document is introducing planned restart signaling – so the helper router now has the opportunity to react to topology changes while waiting for the restarting router to come back to life. We have chosen to leave the decision of when to bring down the adjacency to implementations for a number of reasons: 1. There is no interoperability issue if different helpers use different policies 2. Specifying an optimal behavior that applies to all scenarios would be difficult and unnecessarily constraining 3. With Acee’s feedback that at least some implementations of OSPF GR have chosen not to follow a prescriptive behavior I think we have validation of this choice Les From: Uma Chunduri <[email protected]> Sent: Wednesday, May 29, 2019 7:12 PM To: Acee Lindem (acee) <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; [email protected] Subject: Re: [Lsr] draft-ietf-lsr-isis-rfc5306bis-01 Hi Acee, On Wed, May 29, 2019 at 7:06 AM Acee Lindem (acee) <[email protected]<mailto:[email protected]>> wrote: Hi Les, Uma, Excuse the top-post but Outlook doesn’t do well with inline response for messages such as this one. AFAIK, no implementation defaulted to aborting graceful restart due to any topology change as recommended by RFC 3623. Np. For IS-IS/RFC 5306 (base) yes no implementation defaulted to aborting GR due to topology changes. If one wants to capture topology changes during restart yes they have to do beyond GR(NSR?). However, in the bis document with planned restart indication this is being introduced (i.e., exiting GR if "any" topology change is detected by the neighbor of restating router). Thank you! -- Uma C.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
