Russ Inline
Andrew Sent from my iPhone On 2013-03-23, at 3:52 PM, "Russ White" <[email protected]> wrote: > >> 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) 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. > 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. > Or you can just have a hub router with enough power to handle a deployment at scale needed. Andrew > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
