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

["Acee Lindem (acee)" <[e-mail]>]

Mahesh,
The networking-instance is used to instantiate separate layer-3 or layer-2 domains as opposed to protocol domains. For example, in many implementations, a networking-instance would correspond to a VRF or a Virtual Switch Instance (VSI). Hence, it would not make sense to define a separate networking-instance for MPLS since it is only one piece of a layer-3 domain.
Thanks,
Acee

On Jul 27, 2015, at 11:49 AM, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>> wrote:

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]<mailto:[e-mail]>

On Jul 27, 2015, at 7:14 AM, Acee Lindem (acee) <[e-mail]<mailto:[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.
_______________________________________________
Rtg-yang-coord mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtg-yang-coord