Hi Kent, NETMOD, On Fri, Aug 26, 2016 at 10:54 AM, Kent Watsen <[email protected]> wrote:
> > > > > Please indicate your support or concerns by Thursday September 9, 2016. > > > > We are not only interested in receiving defect reports, we are equally > interested in statements of the form: > > > > * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues > > * I have implemented the data model in draft-ietf-netmod-routing-cfg-23 > > * I am implementing the data model in draft-ietf-netmod-routing-cfg-23 > > * I am considering to implement the data model in > draft-ietf-netmod-routing-cfg-23 > I'd like to add a new category to this set of statements: * I have reviewed this draft, and will *not* be implementing the data model described within it. I have concerns with the contents of this model and their suitability as a base for the wider set of models that are intended to augment it. Indeed, I think the elements that it tackles (e.g., arrangement of protocols within a routing instance) are very much lowest common denominator, and none of the wider issues around multi-tenancy of routing instances (especially those that mix VSI and VRF type semantics) on an individual device, or the way that protocols map to RIBs, and how they then interact/interconnect are tackled within the model. Whilst I understand the difficulties that the authors have been through to try and find a solution, I'm afraid that consensus here has led to a model that actually is operationally a no-op -- even the configuration for static routing is not sufficient for most operator use cases that we have examined when working on a similar problem space. Based on this, and the lack of examination of real configurations of network elements to the model described within the draft, I would oppose progressing this model to RFC until such time as it has been proved to cover a operationally viable set of functionality, and there can be any level of confidence that further changes to the model will not be immediately needed to be able to accommodate the use cases that are required of it. Given the historical opposition to revising models once they have been cast as RFCs that we have seen within the IETF, then I feel that avoiding incomplete models going to RFC is the best course of action. Thanks, r. [0]: Please note: I am speaking as an individual here, not on behalf of any wider set of view points. [1]: Please further note: This opposition to publishing this document completely ignores the issue of operational state. I have made my thoughts clear on this previously, but these comments are entirely orthogonal to that opposition.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
