Subject: [OSPF] Asymmetric OSPF Hold Timer draft

From: Minto Jeyananth <[email-masked]>
Date: Wed, 20 Mar 2013 20:29:51 +0000

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

---

From: Acee Lindem <[email-masked]>
Date: Thu, 21 Mar 2013 17:28:38 +0000

Speaking as a WG member,

On 3/20/13 1:29 PM, "Minto Jeyananth" <[email-masked]> wrote:

>Does not it a pure implementation issue? Implementation could simply
>prevent such an unsupported configuration.

Normally, BFD is used for sub-second convergence. If there is some control
plane switchover, the new active OSPF process must be able to send a hello
on all interfaces before the dead interval expires.

I feel this draft is more useful for OSPFv3 auto configuration.

Thanks,
Acee

> 
>
>Thanks 
>-minto 
>
>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf

---

From: "Madhukar Anand (anandmkr)" <[email-masked]>
Date: Thu, 21 Mar 2013 17:52:12 +0000

[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

---

From: Minto Jeyananth <[email-masked]>
Date: Thu, 21 Mar 2013 18:51:40 +0000

Madhukar, 

  Thanks for response. Please see inline. 

|-----Original Message-----
|From: Madhukar Anand (anandmkr) [mailto:[email-masked]]
|Sent: Thursday, March 21, 2013 10:43 AM
|To: Minto Jeyananth; Hasmit Grover (hasmit); Abhay Roy (akr);
[email-masked]
|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-masked]> 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
|>
|

---

From: "Madhukar Anand (anandmkr)" <[email-masked]>
Date: Thu, 21 Mar 2013 19:28:01 +0000

Hi Minto, 
 Please find our comments inline.

Thanks,
Madhukar

On 3/21/13 11:51 AM, "Minto Jeyananth" <[email-masked]> wrote:

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

>Again, user could configure a higher interval so that system could handle

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.

>OSPF Hello and BFD are for an adjacency. How OSPF asymmetric hello timers
>help here to detect neighbor down but not BFD?
>
>|

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.

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

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Fri, 22 Mar 2013 08:59:15 +0000

Madhukar

Please see inline

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

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

>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

---

From: Russ White <[email-masked]>
Date: Sat, 23 Mar 2013 10:52:42 -0400

> So what is the value of introducing yet another thing to solve  exactly

I'm not certain about this, actually... Are there no use cases where:

1. BFD wouldn't be used anyway (just to take BFD out of the picture)
2. It's more important for one side to know about a down condition
faster than the other side
3. It's important to reduce hello traffic and possible false negatives
to a minimal amount?

I keep thinking there's a possible use case in large scale hub and spoke
networks around this work, specifically in cases where there is more
traffic up towards the hub than down towards the spoke --so it's really
important for the remote to know about a hub failure fast, but the
timing on a hub knowing about a spoke failure can be relaxed.

Not positing that this is an absolutely perfect case, just throwing the
thought out there as a possibility.

Another way to look at the problem is on the neighbor discovery side,
rather than the failure side of things. Are there any instances where
it's important for one OSPF router to learn about a bunch of other OSPF
routers before launching into sending its own hellos on the link? Again,
an example might be a large scale hub and spoke, or even some mobile ad
hoc environments --and here you might actually be using BFD for fast
down, combined with lazy asymmetric OSPF timers for what turns out to be
more efficient and faster discovery.

Again, I don't know for certain, just throwing it out as a discussion item.

:-)

Russ

---

From: "Dolganow, Andrew (Andrew)" <[email-masked]>
Date: Sun, 24 Mar 2013 10:04:54 +0000

Russ

Inline

Andrew

Sent from my iPhone

> 1. BFD wouldn't be used anyway (just to take BFD out of the picture)

BFD was, among others, design for that. Removing it is bot an option in my opinion. Operators tell us vendors to make cost-effective solutions, then request functionality extensions that make control plane more complex because they try yo support today's best functionality without the tools invented for this. I think expanding OSPF to support what we can do already is not the right thing to do. 

> timing on a hub knowing about a spoke failure can be relaxed.
Or you can just have a hub router with enough power to handle a deployment at scale needed. 

Andrew

---

From: Russ White <[email-masked]>
Date: Sun, 24 Mar 2013 08:31:04 -0400

> BFD was, among others, design for that. Removing it is bot an option in my opinion. Operators tell us vendors to make cost-effective solutions, then request functionality extensions that make contr…

My impression of this draft is that it's not about fast down detection
(as BFD is), but asymmetric discovery speed to improve efficiency. Can
you point me to the place in the BFD draft that covers this capability?

The question isn't whether or not BFD can do this particular thing --the
questions are:

1. Is this a reasonable thing to want to do?
2. Should we extend OSPF to do it?

This isn't the BFD working group (?).

:-)

Russ

---

From: Anton Smirnov <[email-masked]>
Date: Sun, 24 Mar 2013 16:17:40 +0100

Hi Russ,
    there is no harm in sending Hellos more frequently than advertised 
Hello interval.
    In other words, if you look at the problem from neighbor discovery 
angle alone (i.e. state that neighbor liveliness detection is offloaded 
from Hellos) then it is best to set Hello and Dead intervals to [near] 
infinity and send Hellos as dictated by other requirements. OSPF could 
send Hellos as fast or as infrequent as needed for neighbor discovery 
and efficiency; symmetric, asymmetric; behavior the same on connected 
routers or different etc.
    If implementation wants to do asymmetric neighbor discovery then 
this is doable within the scope of 2328.

Anton