Re: [netmod] Y34 - root node

[t.petch <[e-mail]>]

----- 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?

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