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" <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 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 >><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<mailto:mjethanand...@gmail.com>>, >><santosh.pallaga...@gmail.com<mailto:santosh.pallaga...@gmail.com>>, >><gregimir...@gmail.com<mailto:gregimir...@gmail.com>> >> 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 >><mjethanand...@gmail.com<mailto:mjethanand...@gmail.com>> 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) >><a...@cisco.com<mailto:a...@cisco.com>> 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 >> mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> >> >> >> >> >> Mahesh Jethanandani >> mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> >> >> >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
