Re: [OSPF] Asymmetric OSPF Hold Timer draft

[Acee Lindem <[e-mail]>]

We were going to relax the constraint on hello/dead timers for OSPFv3
auto-configuration. However, we were just going to remove the checking for
routers supporting auto configuration rather than adding the additional
encoding. In other words, auto-configured routers would simply remove the
checking, ignore the hello interval, and use the neighbor's advertised
dead timer. This draft could also be used for autoconfiguration although
with additional complexity.
Thanks,
Acee


On 3/22/13 1:59 AM, "Dolganow, Andrew (Andrew)"
<[e-mail]> wrote:

>Madhukar
>
>Please see inline
>
>On 2013-03-21 8:28 PM, "Madhukar Anand (anandmkr)" <[e-mail]>
>wrote:
>
>>Hi Minto, 
>> Please find our comments inline.
>>
>>Thanks,
>>Madhukar
>>
>>
>>On 3/21/13 11:51 AM, "Minto Jeyananth" <[e-mail]> wrote:
>>
>>>Madhukar, 
>>>
>>>  Thanks for response. Please see inline.
>>>
>>>|-----Original Message-----
>>>|From: Madhukar Anand (anandmkr) [mailto:[e-mail]]
>>>|Sent: Thursday, March 21, 2013 10:43 AM
>>>|To: Minto Jeyananth; Hasmit Grover (hasmit); Abhay Roy (akr);
>>>|[e-mail]
>>>|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" <[e-mail]> 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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ospf
>
>_______________________________________________
>OSPF mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ospf