Madhukar Please see inline
On 2013-03-21 8:28 PM, "Madhukar Anand (anandmkr)" <[email protected]> wrote: >Hi Minto, > Please find our comments inline. > >Thanks, >Madhukar > > >On 3/21/13 11:51 AM, "Minto Jeyananth" <[email protected]> wrote: > >>Madhukar, >> >> Thanks for response. Please see inline. >> >>|-----Original Message----- >>|From: Madhukar Anand (anandmkr) [mailto:[email protected]] >>|Sent: Thursday, March 21, 2013 10:43 AM >>|To: Minto Jeyananth; Hasmit Grover (hasmit); Abhay Roy (akr); >>|[email protected] >>|Subject: Re: Asymmetric OSPF Hold Timer draft >>| >>|Hi Minto, >>| >>| Thanks for your feedback and comments. Let me try to address your >>|concerns here. >>| >>|Firstly, OSPF HELLOs cannot be eliminated with BFD as they are used for >>|neighbor discover and carrying bits of information for OSPF's peers. >> >>Agreed OSPF HELLOs cannot be eliminated. But comment was about aggressive >>hello(/dead) interval. OSPF could be configured with high interval for >>discovery and uses BFD for failure detection. > >Yes, this is true. Please note that we are not advocating one solution >over other, which we believe is best left to the customer requirements and > >Design, and not really related to any particular implementation issue. Although you are not advocating one solution over the other, you are proposing to add a complication to an existing protocol to do something that can be easily achieved with longer OSPF hello timer and short BFD timer, that can be dynamically adapted during cases like ISSU for example. So what is the value of introducing yet another thing to solve exactly the same problem? > > >> >>|There are use-cases (for e.g., with aggressive HELLO timers) where the >>|recovery window may not be sufficient however efficient the >>|implementation may be. Even with the default HELLO/dead timer, there is >>|possibly a breaking point depending on the scale of OSPF configuration >>|on the router. >> >>Again, user could configure a higher interval so that system could handle >>it. > > >Yes, we agree that a BFD based approach could be used address some of the >concerns here. Again, please note that we are not advocating one solution >over other, which we believe is best left to the customer requirements >and design, and not really related to any particular implementation issue. > > >> >> >>| >>|Secondly, we envision that the proposed solution complements BFD. BFD >>|could Be used for fast link down detection, and the asymmetric hold >>|timer can be used to manage OSPF neighbor down detection. >> >>OSPF Hello and BFD are for an adjacency. How OSPF asymmetric hello timers >>help here to detect neighbor down but not BFD? >> >>| >>|Thirdly, asymmetric hold timers have use-cases beyond the upgrade >>|scenario highlighted here (for instance, with OSPFv3 >>|autoconfiguration/HOMENET). >>|We are working on adding this use-case to the draft also. >> >>OK. The uses cases mention in current draft seems implementation issues. > > >We have other use-cases too. For instance, with the hub-and-spoke >topology, >It may be desirable to have different hold timers on either side. Another >Example is with the HOMENET/OSPFv3 auto configuration where it may also >be desirable to allow asymmetric hold timers. Why would you need different timers here, the only reason would be sub-quality implementation or router deployed in a hub place that cannot handle the deployment scale. I do not think we should be creating protocol extensions for cases like that. > > > >> >> >>Also RFC-2328 assumes hello & dead intervals are symmetric especially in >>broadcast interfaces (wait-timer). > > >This is precisely the main thrust of this proposal. We want to relax that >assumption for a number of use-cases. To summarize, we do not believe >this >is driven by any particular implementation need, but by the need to allow >OSPF to function with many different customer deployments and use-cases. > I believe we need to have a use case that clearly demonstrates a need for a new mechanism. Just because we can do something in a protocol, does not mean we should do it. Andrew > > >> >>-minto >> >>| >>|There is some discussion in Sec 4 of the draft along the lines I've just >>|highlighted. >>|Please let us know if there are more questions. >>| >>|Thanks, >>|Madhukar >>| >>| >>| >>|On 3/20/13 1:29 PM, "Minto Jeyananth" <[email protected]> wrote: >>| >>|>Hi Authors, >>|> >>|>Expert from the draft >>|> >>|> "One of the implications of such busy periods of state restoration >>|in >>|> a process is that, the process may not be able to sustain the rate >>|of >>|> sending HELLOs across all its interfaces. In a controlled restart >>|> scenario (such as OSPF Graceful restart), the router is able to ask >>|> for a grace period by flooding out opaque LSAs indicating that it is >>|> restarting. In case of upgrades and restarts with state >>|restoration, >>|> (i.e., not involving a graceful restart), this is not possible." >>|> >>|>Does not it a pure implementation issue? Implementation could simply >>|>prevent such an unsupported configuration. >>|>With BFD does OSPF needs aggressive interval? >>|> >>|>Thanks >>|>-minto >>|> >>| > >_______________________________________________ >OSPF mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
