Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Mahesh Jethanandani]

> 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 +, 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.

> 
> Thanks,
> Acee 
> 
> 
>> 
>> -- Jeff
> 

Mahesh Jethanandani
mjethanand...@gmail.com

___
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Mahesh Jethanandani]

> On Jun 19, 2017, at 11:57 AM, Jeffrey Haas <jh...@pfrc.org> wrote:
> 
> [Long delayed response.]
> 
> Reshad picked up the key points: Some things may make sense in the
> per-client (protocol) users of BFD, some things perhaps do not.  And some
> come down to questions for timer granularity.
> 
> The OSPF and ISIS models both make use of BFD simply by providing a boolean
> that says "I'm using BFD or not".
> 
> Where we run into some issues are the cases highlighted: when the sessions
> don't share common properties, how should the protocol pick what BFD session
> to use?  

The issue that I hear most is the timer granularity. Is there something else?

> 
> The current BFD yang model only permits a single IP single-hop session
> to be configured.  (Key is interface/dst-ip)  This means that if different
> parameters *were* desired, the BFD model won't permit it today.  However,
> BFD sessions for many protocols tend not to be configured, but may spring
> forth from protocol state, such as IGP adjacencies.  Thus, it's not
> "configured" - it's solely operational state.  However, the BFD yang model
> doesn't really make good provision for that as an "on”.

The idea is that a BFD session is configured a priori and before a IGP session 
is configured with the most aggressive timer. IGP sessions then refer to the 
BGP session configured. If a IGP session is added that requires a more 
aggressive timer, we would have to renegotiate the more aggressive timer value.
 
> 
> Where all endpoint state is known a priori, config state makes better sense.
> 
> To pick the example of Juniper's configuration, if OSPF and eBGP were using
> BFD, both can choose differing timers.  This represents two pieces of
> configuration state for the same endpoints.  Additionally, only one BFD
> session is formed using the most aggressive timers.

That is what we are suggesting also.

> 
> I partially point out the situation of multiple timers since there have been
> prior list discussions on the situation where clients have different timing
> requirements.  I don't think we handle this operationally in the BFD
> protocol in the cleanest fashion right now - the session will go to Down
> when the aggressive timers fail and there's no clean way to renegotiate to
> the less aggressive timers.

A BFD session would fail more likely because there is a real network failure 
than because the timer was more aggressive than what IGP had requested. 

> 
> -- Jeff
> 
> 
> 
> 
> 
> 
> On Fri, May 19, 2017 at 02:31:38AM +, Reshad Rahman (rrahman) wrote:
>> We started off with the intent of having BFD parameters in the 
>> applications/protocols which make use of BFD. For timer/multiplier this is 
>> pretty straight-forward, although the discussion of what to do when not all 
>> applications have the same BFD parameters for the same session (e.g. Go with 
>> most aggressive etc). Then we started looking at authentication parameters 
>> and having BFD authentication parms in OSPF/ISIS etc is not intuitive. And 
>> what do we do if applications have different BFD authentication parms. We 
>> concluded that the BFD authentication parms were better off in BFD. And once 
>> we did that, the timer/multiplier followed
>> 
>> I may not recall all the details/discussons, but I do recall that we went 
>> back and forth on this and it took some time to make the decision.
>> 
>> Regards,
>> Reshad (as individual contributor).
>> 
>> From: Mahesh Jethanandani 
>> <mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>>
>> Date: Thursday, May 18, 2017 at 5:34 PM
>> To: "Acee Lindem (acee)" <a...@cisco.com<mailto:a...@cisco.com>>
>> Cc: Jeffrey Haas <jh...@juniper.net<mailto:jh...@juniper.net>>, OSPF WG List 
>> <ospf@ietf.org<mailto:ospf@ietf.org>>, 
>> "draft-ietf-bfd-y...@ietf.org<mailto:draft-ietf-bfd-y...@ietf.org>" 
>> <draft-ietf-bfd-y...@ietf.org<mailto:draft-ietf-bfd-y...@ietf.org>>, 
>> "draft-ietf-ospf-y...@ietf.org<mailto:draft-ietf-ospf-y...@ietf.org>" 
>> <draft-ietf-ospf-y...@ietf.org<mailto:draft-ietf-ospf-y...@ietf.org>>, 
>> "rtg-...@ietf.org<mailto:rtg-...@ietf.org>" 
>> <rtg-...@ietf.org<mailto:rtg-...@ietf.org>>
>> Subject: Re: IETF OSPF YANG and BFD Configuration
>> Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>>
>> Resent-To: <vero.zh...@huawei.com<mailto:vero.zh...@huawei.com>>, Reshad 
>> <rrah...@cisco.com<mailto:rrah...@cisco.com>>, 
>> <mjethanand...@gmail.com<