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. |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. | |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. Also RFC-2328 assumes hello & dead intervals are symmetric especially in broadcast interfaces (wait-timer). -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
