> On Jun 19, 2017, at 11:57 AM, Jeffrey Haas <[email protected]> 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 >> <[email protected]<mailto:[email protected]>> >> Date: Thursday, May 18, 2017 at 5:34 PM >> To: "Acee Lindem (acee)" <[email protected]<mailto:[email protected]>> >> Cc: Jeffrey Haas <[email protected]<mailto:[email protected]>>, OSPF WG List >> <[email protected]<mailto:[email protected]>>, >> "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>>, >> "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>>, >> "[email protected]<mailto:[email protected]>" >> <[email protected]<mailto:[email protected]>> >> Subject: Re: IETF OSPF YANG and BFD Configuration >> Resent-From: <[email protected]<mailto:[email protected]>> >> Resent-To: <[email protected]<mailto:[email protected]>>, Reshad >> <[email protected]<mailto:[email protected]>>, >> <[email protected]<mailto:[email protected]>>, >> <[email protected]<mailto:[email protected]>>, >> <[email protected]<mailto:[email protected]>> >> 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 >> <[email protected]<mailto:[email protected]>> 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) >> <[email protected]<mailto:[email protected]>> 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 >> [email protected]<mailto:[email protected]> >> >> >> >> >> Mahesh Jethanandani >> [email protected]<mailto:[email protected]> >> >> >> Mahesh Jethanandani [email protected] _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
