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

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

Mahesh,


From: Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>
Date: Monday, July 27, 2015 at 4:18 AM
To: Acee Lindem <[e-mail]<mailto:[e-mail]>>
Cc: Lou Berger <[e-mail]<mailto:[e-mail]>>, Routing YANG <[e-mail]<mailto:[e-mail]>>, YANG Doctors <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>>
Subject: Re: Routing YANG Design Team Scope

Acee,

Juergen’s concerns aside, I am curious about the intent of the design. I see the device model as a abstract model that allows for plenty of extensions. Since the discussion started with MPLS, I am going to focus on that part for now.

BTW, the TOC in the html version of the draft have no hyper links.

I see that the mpls model in the draft to be very similar to the one in the OC MPLS draft.

Yes - the OC MPLS model was a starting point.

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.

Thanks,
Acee



Thanks.

On Jul 26, 2015, at 1:49 PM, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> wrote:

Acee,

you pointed to a document that seems to go out of the scope of this
routing yang design team and since this document is called
draft-rtgyangdt-rtgwg-* so I felt it is necessary to react.

/js

On Sun, Jul 26, 2015 at 07:50:40PM +0000, Acee Lindem (acee) wrote:
Juergen,

Since this E-mail thread is about the hierarchy and granularity of MPLS
models, I’m somewhat confused by your response. Nevertheless, I’ve updated
the subject line to correspond to your concern.

Our assumption is that the Routing YANG design team will attempt to use
the existing models but will not be constrained by them. However, I agree
that any changes or augmentations to the existing NETMOD RFCs would need
to be reviewed in the NETMOD WG.

Thanks,
Acee

On 7/26/15, 3:24 PM, "Juergen Schoenwaelder"
<[e-mail]<mailto:[e-mail]>> wrote:

Dear Acee,

please note that the interfaces model plus the IP model plus the core
system model plus the SNMP configuration model the IETF agreed on are
defined in RFC 7223, RFC 7277, RFC 7317, and RFC 7407. All these RFCs
were produced by the NETMOD working group.  Work is starting in other
SDOs to extend these models. Hence, I think any attempts to replace
them with something different should not only be discussed on the
NETMOD list but also seek support from the NETMOD working group.

Note that https://www.ietf.org/mailman/listinfo/rtg-yang-coord says:

  The rtg-yang-coord mailing list will provide a forum for
  coordination of the development of YANG models being worked on for
  Routing, in order to provide a consistent view to the NMS.

It seems some of the content of draft-rtgyangdt-rtgwg-device-model-00
seems to leave the routing scope.

/js

On Sun, Jul 26, 2015 at 06:48:10PM +0000, Acee Lindem (acee) wrote:
Hi Mahesh,

Please comment on
https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/ as
this is the latest view of the design team.

Thanks,
Acee

From: Rtg-yang-coord
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
on behalf of Mahesh Jethanandani
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Date: Sunday, July 26, 2015 at 4:31 PM
To: Lou Berger <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Cc: Routing YANG
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>, YANG Doctors
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>, Loa Andersson
<[e-mail]<mailto:[e-mail]><mailto:[e-mail]>>
Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg

Lou,

I like the approach taken in the draft
draft-openconfig-mpls-consolidated-model. In particular, the approach
represented in this tree model makes sense to me.


  +--rw mpls!
        +--rw global
        |     ...
        +--rw te-global-attributes
        |     ...
        +--rw signaling-protocols
        |     ...
        +--rw lsps
              ...


However, by its own admission, the draft says:


This model does not aim to be feature complete (i.e., cover all
  possible aspects or features of MPLS).

My suggestion would be for the MPLS WG to take up the model structure
as represented above and to do a more complete work of including all
features of MPLS, e.g. GMPLS.

Thanks.

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]><mailto:[e-mail]>






_______________________________________________
Rtg-yang-coord mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtg-yang-coord


--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>


--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>