> 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?
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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
