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?
Regards, Greg On Mon, Jun 19, 2017 at 1: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- > b...@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
