Hi Jeff, Mahesh, See a couple inlines.
On 6/20/17, 10:16 AM, "Jeffrey Haas" <jh...@pfrc.org> wrote: >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. I think the BFD model should support a wildcard for destination IP address to avoid this problem. > >> > 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. This could be supported with extensions to the BFD model. Thanks, Acee > >> > 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. > >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
