Re: [netmod] Motivations for Structuring Models

[Ladislav Lhotka <[e-mail]>]

> On 27 Aug 2015, at 19:49, Rob Shakir <[e-mail]> wrote:
> 
> Lada,
> 
> 
> 
> On August 27, 2015 at 12:54:39, Ladislav Lhotka ([e-mail]) wrote:
> 
>> We certainly need *some* structure, and since there was a requirement to support multiple routing instances, a list of them seems natural. 
> Great, we agree that we need some structure like we have for routing elsewhere.
> 
> Can you point me towards any proposal other than draft-openconfig-netmod-model-structure or draft-rtgyangdt-rtgwg-device-model–00 for this structure?

The current structure was pretty much a direct consequence of the previous NETMOD charter:

http://datatracker.ietf.org/doc/charter-ietf-netmod/06/

And as I said, we did consider having some universal top-level structure but we rejected this idea, mainly because every other module would then have to be an augment.

> 
> Already, implementors are having problems with this - because existing modules that are pretty mature (ietf-bgp for example), need more functionality than is in ietf-routing to make usable multi-VRF systems, let alone multi-routing-instance. If there were some structure, we could understand how these models need to be augmented to support the use cases. I’ll come back to the case of how I configure something that is a L2 virtual forwarding instance, that uses has a L3 IP interface within it.

ietf-routing is still open for any changes, but I think it has nothing to do with the presence or absence of /device.

> 
> On the latter comments in your mail, I place little importance on obsoleting existing RFCs, I care about:

I would concur that the rules for updating published modules are too strict for this stage, and that more flexibility is needed atleast until the YANG landscape stabilises.

> 
> 	• Primarily: whether the existing models let me configure things that I need to on my network (or form a suitable base for doing so).
> 	• Secondary: impact to existing implementations where these models are actually usable to some external consumer.

What I and others don’t understand is how the /device container helps, or the current flat structure prevents, reaching these aims.

Cheers, Lada

> Kind regards,
> r.
> 
> 

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