[Apologies if you have received multiple copies. I had trouble sending
that last email out]

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.
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.

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.

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.

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

Reply via email to