Re: [Rtg-yang-coord] Routing YANG Design Team Scope

[Mahesh Jethanandani <[e-mail]>]

Acee,

The boiler plate goals and approach does not answer what I thought was a very specific question. Let me reiterate:

What was thought behind defining a mpls feature in the devices model, vs say defining networking-instance as a 'type identityref’ which would form a base identity, and from which specific networking-instance types such as mpls would be derived? 

The latter in my mind lays the framework for how models could augment the base devices model without defining each and every feature, while the former has to define at least a basic model for each feature which then would have to be augmented anyway to realize the full feature.

Mahesh Jethanandani
[e-mail]

> On Jul 27, 2015, at 7:14 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> Is the idea that the device model is trying to define everything under a device tree? I would have thought that the device model would define networking-instance as a 'type identityref’ which would form a base identity, and from which specific networking-instance types would be derived, such as mpls - much like what the interfaces model does for all types of interfaces. That will allow the device model to be a fairly compact model, leaving the feature specific models to be developed elsewhere.
> 
> 
> The design team started with https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt and went through several iterations. The motivation excerpted from this draft is: 
> 
> 1.1.  Goals and approach
> 
>    In this document, we describe a structure for organizing YANG
>    [RFC6020] models that is broadly applicable to physical and virtual
>    devices.  Individual models are composed such that the data they
>    define can be accessed in a predictable and operationally intuitive
>    way that is common across implementations.  This organization enables
>    several important capabilities:
> 
>    o  a common schema to access data related to all aspects of a device
> 
>    o  an extensible structure that makes it clear where additional
>       models or data should be fit (e.g., using YANG augmentation or
>       imports)
> 
>    o  a place for including metadata that provides useful information
>       about the corresponding individual models, such as which
>       organization provides them, which vendors support them, or which
>       version of the model is deployed
> 
>    o  a common infrastructure model layer on which higher layer service
>       models can be built, for example by specifying which models are
>       needed to provide the service
> 
>    o  an ability to express an instance of the structure consisting of
>       models that have been validated to work together (i.e., with
>       information about sources of the models, their versions, etc.), so
>       that operators can easily identify a set of models that is known
>       to be mutually consistent
> 
>    Our approach is to organize the models describing various aspects of
>    network infrastructure, including devices and their subsystems, and
>    relevant protocols operating at the link and network layers.  The
>    proposal does not consider a common model for higher level network
>    services, nor does it specify details of how hardware-related data
>    should be organized.  Both of these are challenging to standardize --
>    services are subject to operational and business considerations that
>    vary across network operators, and hardware models are necessarily
>    dependent on specific platform features and architecture -- and are
>    thus out of scope of this document.  We instead consider the set of
>    models that are commonly used by network operators, and suggest a
>    corresponding organization.
> 
>    As with other models developed from an operator perspective, the
>    intent is not to be exhaustive by including all possible models in
>    the overall structure, whether currently available or not.  We focus
>    on components that are deemed most useful for network operators
>    across a variety of use cases.  We recognize, however, that
>    additional models will be needed in some cases, and this structure is
>    useful for describing how new models can be fit into the overall
>    structure.