Re: [netmod] Y34 - root node

[Andy Bierman <[e-mail]>]

On Wed, Aug 19, 2015 at 9:24 AM, t.petch <[e-mail]> wrote:

> ----- Original Message -----
> From: "Martin Bjorklund" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>
> Sent: Wednesday, August 19, 2015 12:25 PM
> > Robert Wilton <[e-mail]> wrote:
> > >
> > > On 18/08/2015 18:22, Andy Bierman wrote:
> > > > This is how languages like SMIv2 and YANG work.
> > > > A conceptual object is given a permanent "home" within the tree of
> > > > object identifiers.
> > > > Moving data is very expensive, since any clients working with the
> old
> > > > data
> > > > will break as soon as the data is moved.
> > > >
> > > >  I am not convinced the IETF can or should come up with a set of
> > > >  containers
> > > > that covers every possible topic that can be modeled in YANG.
> > >
> > > I mostly agree, but having some more structure/advice as to where to
> > > place YANG modules may be helpful.  I'm thinking more along the
> lines
> > > of broad categories rather than precise locations.
> >
> > +1
>
> Martin
>
> If I were able to choose someone to ask for advice on this question,
> well, your name would be joint top of my list.  If you are not going to
> write it, then who is?
>
> The current model is a flat architecture of hundreds (or thousands) of
> modules each with their own top level nodes, namespace, namespace name,
> prefix etc.  (This is quite different to SMI with its hierarchy but that
> probably is only significant to those who have spent 20 years with SMI).
>
> So, is this flat architecture a problem?  Does it matter that we have
> hundreds (or thousands) of top level nodes?  I know that top level nodes
> are different w.r.t the rules of YANG but cannot foresee whether or not
> that is an issue for model writers or model users because I cannot get
> my mind around just what the rules are in this regard?
>
>

But this is not what we have.
Many times a YANG module augments another on (such as ietf-interfaces).

As for 100s maybe 1000s...;

Here is the datastore contents that the IETF has defined so far:
[not sure if I am leaving out other WGs]

    Yr        RFC      root                     comments

   2008    5277     /netconf               Notification streams (XSD, no
YANG at all)
   2010    6022     /netconf-state      NETCONF monitoring
   2012    6536     /nacm                  NETCONF access control
   2012    6728     /ipfix                    IPFIX and PSAMP configuration
   2014    7223     /interfaces            Interface management
                            /interfaces-state
   2014   7277    augment /interfaces/interface   IP management
   2014   7317     /system                   Host system management
   2014   7407     /snmp                     SNMP configuration



Maybe 1000s, maybe 8.

I would hardly say that this represents a problem that is out of control.
I also would not call 7 RFCs in 5 years with YANG data in them as much
progress.
At this rate it will take 150 years to fill in the tree of NP containers
will real modules.


Andy


Equally, is it a problem to have hundreds (or thousands) of prefixes? or
> namespaces? or ...
>
> And what else is there that having a lot of might be an issue?
>
> I see the YANG architecture as reflecting the IETF 'architecture' of
> hundreds of working groups loosely federated, sometimes collaborating,
> mostly not, and so is the right way to develop YANG modules.  But are
> there technical dangers lurking there that in a few years time we will
> wish we had taken more notice of.
>
> Tom Petch
>
> > > >     If someone wants to builds a YANG controller node that is
> managing
> > > >     the configuration for a network of devices then wouldn't they
> want
> > > >     a particular device's interface configuration to be located
> > > >     somewhere like
> /network/device/<device-name>/interfaces/interface?
> > > >     Ideally, they would be able to use the same YANG definitions
> that
> > > >     are defined for /interfaces/ but root them relative to
> > > >     /network/device/<device-name>/.
> > > >
> > > >
> > > >
> > > > Yes -- some of us (like Martin) have pointed this out many times.
> > > > The "device" container on an NE does not help at all wrt/
> > > > aggregation on a controller. "/device" or "/" work the same for
> this
> > > > purpose.
> >
> > Actually, I would argue that / works better.  On the controller, you
> > probably have a list of devices you control (this is how our NCS
> > works, and how ODL works (I have been told)):
> >
> >   container devices {
> >     list device {
> >       key name;
> >       // meta-info about the device goes here, things like
> >       // ip-address, port, auth info...
> >       container data {
> >         // all models supported by the devices are "mounted" here
> >       }
> >     }
> >   }
> >
> > So on the controller, the path to interface "eth0" on device "foo"
> > would be:
> >
> >   /devices/device[name='foo']/data/interfaces/interface[name='eth0']
> >
> > if we also have a top-level "/device" container we'd have:
> >
> >
> /devices/device[name='foo']/data/device/interfaces/interface[name='eth0'
> ]
> >
> > > What would the real resource location for
> > > "/network/device/<device-name>/interfaces/interface" be?
> >
> > I don't think there is such a thing as a "real" location.  The path is
> > scoped in the system you work with; in the controller it might be as I
> > illustrated above, in the device it starts with /interfaces, but in a
> > controller-of-controllers it might be:
> >
> >   /domains/domain[name='bar']/devices/device[name='foo']/data
> >     /interfaces/interface[name='eth0']
> >
> > Currently we have a proprietary way of "relocating" YANG modules, and
> > ODL has its "mount", and I think Andy has some other mechanism.  Maybe
> > the time has come to standardize how mount works, and maybe then also
> > standardize the list of devices in a controller model.
> >
> >
> > /martin
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>