On 6/20/17, 1:50 PM, "Mahesh Jethanandani" <mjethanand...@gmail.com> wrote:
> >> On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee) <a...@cisco.com> wrote: >> >> 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. > >Let me work with Reshad to suggest what IGP could suggest to BFD in their >construct, and have BFP pick what it believes would be the right set of >parameters to be able to support most of the IGPs over the given BFD >session. Whether we add it in the current model or add it later as an >augmentation could then be decided separately. Given that the IGP models are more mature and will soon be ready for publication, I think it is a given that this will be done in an augmentation. Thanks, Acee > >> >> Thanks, >> Acee >> >> >>> >>> -- Jeff >> > >Mahesh Jethanandani >mjethanand...@gmail.com > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
