> On Jun 19, 2017, at 11:57 AM, 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 issue that I hear most is the timer granularity. Is there something else? > > 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. > > 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. > > 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. > > -- 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> >> >> >> Mahesh Jethanandani mjethanand...@gmail.com _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
