Re: [OSPF] IETF OSPF YANG and BFD Configuration

[Greg Mirsky <[e-mail]>]

Hi Jeff,
thank you for the great summary of the discussion, helps me to catch the
wave.
I'm skeptical that there's realistic scenario where two BFD systems will be
requested to run multiple BFD single-hop session between them over the same
interfaces (logical or physical). I believe that we should try to make
models future proof but to the level that is reasonable, practical.
Approach "if we can think of it, then we need to support it" may not be the
one.
RE: RFC 5881. I've referred to the following:
... any BFD packet from the remote machine with a zero value of Your
Discriminator MUST be associated with the session bound to the remote
system, interface, and protocol.
Unless we add out-band bootstrapping of BFD sessions like with LSP Ping, I
don't see how received BFD control packet with zero value in Your
Discriminator may be bound to not just any one of several protocols that
are trying to run BFD session on the same interface to the same remote
system but to the right one, the one that corresponds to the protocol on
whose behalf remote BFD peer sent the control packet. Hence my question Do
we have implementation(s) that use this and are asking for BFD data model
to accommodate them? Or we are just doing interesting intellectual exercise?

Regards,
Greg

On Tue, Jun 20, 2017 at 2:00 PM, Jeffrey Haas <[e-mail]> wrote:

> Greg,
>
> On Tue, Jun 20, 2017 at 12:55:58PM -0500, Greg Mirsky wrote:
> > 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?
>
> Correct, 5881 procedures do not currently permit this.
> As I mentioned, we've had prior discussions about this being potentially
> problematic for clients that may have differing timing requirements.
>
> Part of the point of this exercise is to provide necessary future-proofing
> against the need to re-issue the Yang modules if such a mechanism is
> developed.  (Somewhat analogous to the instructions to the design team that
> MPLS-TP was out of scope for the module, but that its structure shouldn't
> prevent its implementation in the future.)
>
> Thus far, two points have sprung from the discussion that are likely
> actionable:
> - The single-hop configuration in the current BFD module isn't suitable for
>   use by the IGPs.  Some form of wildcard of templating behavior is
>   necessary.
> - Multiple clients that might desire to configure a session with different
>   parameters are unable to do so today.  This precludes some
> implementations
>   that permit such configuration, potentially at protocol scope.  It also
>   doesn't fit the future-proofing thought.
>
>
> -- Jeff
>
> >
> > 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]>
> > > >
> > > >
> > > >
> > >
>