Jeff, On 6/20/17, 10:20 AM, "Jeffrey Haas" <jh...@pfrc.org> wrote:
>Acee, > >On Mon, Jun 19, 2017 at 10:10:43PM +0000, Acee Lindem (acee) wrote: >> I don’t really feel there is a strong requirement to support different >> timers values per protocol even though several implementations allow >> different protocol specific values to be configured (with varying >> behaviors). >> >> If there were such a requirement, I would think it would be better >> satisfied by extending the BFD model session key with an additional >> identifier, e.g., <interface/dst-ip/instance>. > >I suspect multi-instancing may be where this conversation goes. > >> IMO, this would be >> preferable to allowing the details of BFD to permeate into all the other >> protocol models. This would require configuration of the instance rather >> than a boolean in the protocols. > >My lingering concern is whether the client protocol may have preferences >about what session to use when such multi-instancing is permitted. >Minimally this would require some sort of Yang reference to the specific >instance. Right - this is what I just said. > >As I'm noting in the other response, do we really expect BFD Yang model >users to pre-provision every single OSPF/ISIS adjacency in the config >stanza? Likely, no. Agreed. > >What I tend to expect is a template being used for a service profile. We >don't currently have such a thing. Agreed. My point is that the BFD specific parameters should in the BFD model rather than the protocol models. Acee > >-- Jeff _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
