Jeff - Inline.
> -----Original Message----- > From: Rtg-bfd [mailto:rtg-bfd-boun...@ietf.org] On Behalf Of Jeffrey Haas > Sent: Tuesday, June 20, 2017 7:17 AM > To: Mahesh Jethanandani > Cc: Jeffrey Haas; Reshad Rahman (rrahman); OSPF WG List; draft-ietf-ospf- > y...@ietf.org; rtg-...@ietf.org; draft-ietf-bfd-y...@ietf.org; Acee Lindem > (acee) > Subject: Re: IETF OSPF YANG and BFD Configuration > > Mahesh, > > On Mon, Jun 19, 2017 at 03:11:25PM -0700, Mahesh Jethanandani wrote: > > > On Jun 19, 2017, at 11:57 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > > > 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? > > Potentially mode (async vs. echo) and authentication. However, I believe > timer granularity is the biggest one. > > > > 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. > > Consider a broadcast network segment such as Ethernet. > Consider a few dozen routers on such a segment. > > Is it your expectation that an IGP would require each of those routers to be > manually configured in the Yang module a priori? That is, after all, much of > the point of an IGP: automatic discovery. > > > > 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. > > The distinguishing point is configuration vs. operational state. The current > model doesn't permit more than one set of parameters to be provisioned > even if the implementation may choose to instantiate exactly one session. > > > > 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. > > Please note that I raise this point mostly because of prior discussion. I'm > well > aware of the headaches this currently causes: > > Different protocols have different survivability requirements. An IGP may > very well want sub-second timers, potentially for repair behaviors. BGP may > want fast failover, but may be fine with second level granularity. This is > particularly true since the cost of too aggressively flapping BGP is of > significantly greater impact to the network and the router. > [Les:] The real issues here are false failures and proper use of dampening. No protocol - not even an IGP - wants to flap unnecessarily. If timers are set so aggressively that false failures are reported this is BAD. Even worse is failure to dampen so that we get multiple false failures in a short period of time. Arguing that the right way to solve this problem is to increase the number of sessions using different timer granularity seems likely to make any problems worse as you have now increased the number of BFD sessions with the associated costs. Les > But moving to what *is* rather than what should be, if there are two > different timing setups for the same endpoint: If you deprovision the more > aggressive timer, the session should likely renegotiate to the less aggressive > one rather than drop. > > -- Jeff _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
