Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Jeffrey Haas <[e-mail]>]

Mahesh,

On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote:
> > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas <[e-mail]> wrote:
> > 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?

Potentially mode (async vs. echo) and authentication.  However, I believe
timer granularity is the biggest one.

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

Consider a broadcast network segment such as Ethernet.
Consider a few dozen routers on such a segment.

Is it your expectation that an IGP would require each of those routers to be
manually configured in the Yang module a priori?  That is, after all, much
of the point of an IGP: automatic discovery.

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

The distinguishing point is configuration vs. operational state.  The
current model doesn't permit more than one set of parameters to be
provisioned even if the implementation may choose to instantiate exactly one
session.

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

Please note that I raise this point mostly because of prior discussion.  I'm
well aware of the headaches this currently causes:

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.

But moving to what *is* rather than what should be, if there are two
different timing setups for the same endpoint: If you deprovision the more
aggressive timer, the session should likely renegotiate to the less
aggressive one rather than drop.

-- Jeff