Re: [OSPF] IETF OSPF YANG and BFD Configuration

["Acee Lindem (acee)" <[e-mail]>]

Hi Jeff, 

On 6/20/17, 10:58 AM, "Jeffrey Haas" <[e-mail]> 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