Marc, On Wed, Nov 04, 2015 at 01:20:17AM -0800, Marc Binderberger wrote: > I'm not too deep into YANG et al., so I apologize upfront for this email :-) > . I understand YANG is about configuration but are we trying to find a common > way to reflect the various (CLI-)configurations that are out in the market? > Isn't this, well, a bit restricting?
Generally, Yang modules in IETF have focused more on configuration at the start, but Yang and netconf also cover operational state as well, including notifications. > Should a generic "configuration" of a BFD session not contain all the > variables of the particular layers? E.g. for the BFD packet itself not just > timer and multiplier but "my" and "your" discriminator too? For the IP layer > src/dst IP and egress interface? For operational state, absolutely. For configuration state, reflecting constraints for provisioning the existing mechanisms is probably where we want to start. It could be easily argued that we could simply provide for completely abstract configuration of sessions, but that means that the model would fail to enforce constraints that real implementations have. The current example of this is multiple sessions between the same pair of endpoints. > The various RFCs 5881, 5883, ... would be special cases that could be > incorporated. E.g. a "your" discriminator of zero (or lack of this parameter) > for a single-hop IP-based BFD session would mean to follow RFC5881 and it's > bootstrapping mechanism. > > > Maybe this is too generic to start the YANG endeavor. But in these days of > "programmability" I would expect more than an API that replaces my CLI 1:1. Arguably, we're more at "generic CLI" than full-out API. However, this is mostly my somewhat tainted opinion as i2rs chair. :-) -- Jeff (speaking as an individual contributor)
