Re: IETF OSPF YANG and BFD Configuration

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

On 6/20/17, 1:50 PM, "Mahesh Jethanandani" <[e-mail]> wrote:

>
>> On Jun 20, 2017, at 8:40 AM, Acee Lindem (acee) <[e-mail]> wrote:
>> 
>> 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. 
>
>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
>[e-mail]
>