Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Ladislav Lhotka <[e-mail]>]

Rob Shakir <[e-mail]> writes:

> Hi Kent, NETMOD,
>
> On Fri, Aug 26, 2016 at 10:54 AM, Kent Watsen <[e-mail]> 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.

Fair enough.

>
> 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.

Earlier revisions of the draft (such as -16) contained more stuff that
really implemented something (framework for route filters, explicit connection of
routing protocols to RIBs, fancy next-hops). All of them were removed,
mainly because they aren't the lowest common denominator.

Nonetheless, I don't think that what remains is a no-op. The core
routing model does define a framework in which multiple instances of
routing protocols can coexist. And it also implements an approach to
configuration versus state data analogical to RFC 7223 (which you
probably don't like).

As for static routing, I believe it perfectly suffices for hosts and
simpler router configurations. As a proof of concept, I myself wrote
XSLT stylesheets that were able to convert this data to CLI
configurations for Cisco IOS and BIRD routing daemon. It may not be
sufficient for all use cases, but then nothing prevents you or anybody
else from developing a data model for a new "static-on-steroids"
protocol, and fit it into the core routing model.

Lada

>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C