Re: IETF OSPF YANG and BFD Configuration

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

Hi Jeff, 

I don’t really feel there is a strong requirement to support different
timers values per protocol even though several implementations allow
different protocol specific values to be configured (with varying
behaviors). 

If there were such a requirement, I would think it would be better
satisfied by extending the BFD model session key with an additional
identifier, e.g., <interface/dst-ip/instance>. IMO, this would be
preferable to allowing the details of BFD to permeate into all the other
protocol models. This would require configuration of the instance rather
than a boolean in the protocols.

Thanks,
Acee 




On 6/19/17, 2: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:[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]>
>> 
>> 
>>