Re: IETF OSPF YANG and BFD Configuration

[Greg Mirsky <[e-mail]>]

Hi Jeff,
I'd like to hear from others who are familiar with implementations of BFD
that supports per protocol single-hop BFD multi-sessions between the same
pair of BFD systems. RFC 5881 does allow per protocol single-hop sessions
on the same interface, logical or physical, between the same pair of
systems. But it is not clear, in my opinion, how BFD does demultiplexing if
Your Discriminator == 0 per protocol (RFC 5881, section 3, last sentence)
if systems use the same IP addresses. And hence the question, Even though
it is allowed to have BFD single-hop sessions per application/protocol on
the same interface between the same pair of systems, is this real,
practical requirement?
Or am I missing the point completely?

Regards,
Greg

On Mon, Jun 19, 2017 at 1:57 PM, Jeffrey Haas <[e-mail]> 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 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".
>
> 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.
>
> 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.
>
> -- Jeff
>
>
>
>
>
>
> On Fri, May 19, 2017 at 02:31:38AM +0000, 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 <[e-mail]<mailto:
> [e-mail]>>
> > Date: Thursday, May 18, 2017 at 5:34 PM
> > To: "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>
> > Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>, OSPF WG
> List <[e-mail]<mailto:[e-mail]>>, "[e-mail]<
> mailto:[e-mail]>" <[e-mail]<
> mailto:[e-mail]>>, "[e-mail]
> <mailto:[e-mail]>" <[e-mail]
> <mailto:[e-mail]>>, "[e-mail]<mailto:rtg-
> [e-mail]>" <[e-mail]<mailto:[e-mail]>>
> > Subject: Re: IETF OSPF YANG and BFD Configuration
> > Resent-From: <[e-mail]<mailto:[e-mail]>>
> > Resent-To: <[e-mail]<mailto:[e-mail]>>,
> Reshad <[e-mail]<mailto:[e-mail]>>, <
> [e-mail]<mailto:[e-mail]>>, <
> [e-mail]<mailto:[e-mail]>>, <
> [e-mail]<mailto:[e-mail]>>
> > Resent-Date: Thursday, May 18, 2017 at 5:40 PM
> >
> > Resending with correct BFD WG address.
> >
> > On May 18, 2017, at 2:33 PM, Mahesh Jethanandani <
> [e-mail]<mailto:[e-mail]>> wrote:
> >
> > Agree with Acee's assessment. After much debate, we decided that we
> should leave BFD parameter configuration in the BFD model itself, and have
> any IGP protocol reference the BFD instance in BFD itself. This makes sense
> specially if multiple protocols fate-share the BFD session.
> >
> > Cheers.
> >
> > On May 18, 2017, at 12:27 PM, Acee Lindem (acee) <[e-mail]<mailto:
> [e-mail]>> wrote:
> >
> > Hi Jeff,
> >
> > At the OSPF WG Meeting in Chicago, you suggested that we may want to
> provide configuration of BFD parameters within the OSPF model
> (ietf-ospf.yang). We originally did have this configuration. However, after
> much discussion and coordination with the BFD YANG design team, we agreed
> to leave the BFD session parameters in BFD and only enable BFD within the
> OSPF and IS-IS models.
> >
> > We did discuss the fact that vendors (notably Cisco IOS-XR and Juniper
> JUNOS) do allow configuration within the IGPs. However, the consensus was
> to leave the BFD configuration in the BFD model. The heuristics to
> determine what parameters to use when the same BFD endpoint was configured
> with different parameters in different protocols were proprietary and
> somewhat of a hack.
> >
> > I may have not remembered all the details so I'd encourage others to
> chime in.
> >
> > Thanks,
> > Acee
> >
> > Mahesh Jethanandani
> > [e-mail]<mailto:[e-mail]>
> >
> >
> >
> >
> > Mahesh Jethanandani
> > [e-mail]<mailto:[e-mail]>
> >
> >
> >
>