Hi Jeff, On 6/20/17, 10:58 AM, "Jeffrey Haas" <jh...@pfrc.org> wrote:
>Les, > >On Tue, Jun 20, 2017 at 02:25:12PM +0000, Les Ginsberg (ginsberg) wrote: >> > Different protocols have different survivability requirements. An >>IGP may >> > very well want sub-second timers, potentially for repair behaviors. >>BGP may >> > want fast failover, but may be fine with second level granularity. >>This is >> > particularly true since the cost of too aggressively flapping BGP is >>of >> > significantly greater impact to the network and the router. >> > >> [Les:] The real issues here are false failures and proper use of >>dampening. No protocol - not even an IGP - wants to flap unnecessarily. >>If timers are set so aggressively that false failures are reported this >>is BAD. >> Even worse is failure to dampen so that we get multiple false failures >>in a short period of time. >> >> Arguing that the right way to solve this problem is to increase the >>number of sessions using different timer granularity seems likely to >>make any problems worse as you have now increased the number of BFD >>sessions with the associated costs. > >I'm mildly amused you seem to think I'm not considering the cost of >additional sessions in the scaling matrix. :-) > >I do think you're conflating the survivability requirements vs. timer >granularity. However, I agree that the most commonly deployed form is to >go >for single session with the most stable aggressive timer. > >Again, the reason I raise this is there has been discussion regarding >behavior for different client timing requirements. There are a few >options >for how this is likely to play out in terms of BFD protocol >implementation. >However, configuration and operational models tend to evolve much more >slowly. (And I certainly don't need to tell you that.) Thus, I'm >prodding >at this space a bit to attempt to do some future proofing. > >As we noted earlier in thread, this likely at least encourages >configuration >to be multi-instanced, even if the session instantiation is not currently. >Key changes aren't something we can readily do, so getting that part right >early is necessary. > >The likely impact on current IGP module BFD configuration may be a later >augmentation. Thus, as long as the likely implications are understood, >there may be no further action needed at this time. Determining that is >partially what this thread is attempting to shake out. In the IGPs, we have a separate BFD container in the interface configuration. Currently, it only contains the a boolean. This could easily be augmented to reference the appropriate construct in the BFD model. Thanks, Acee > >-- Jeff _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
