Re: [netmod] Y34 - root node

[Robert Wilton <[e-mail]>]

On 18/08/2015 18:22, Andy Bierman wrote:
>
>
> On Tue, Aug 18, 2015 at 9:59 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 11/08/2015 08:38, Ladislav Lhotka wrote:
>
>             On 10 Aug 2015, at 22:15, Andy Bierman <[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>
>
>             On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee)
>             <[e-mail] <mailto:[e-mail]>> wrote:
>             I think there is agreement that there is a problem. The
>             YANG Routing Design Team is  addressing this with
>             https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt
>             (which has evolved from
>             https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt).
>             In essence, a place for everything and everything in its
>             place. However, there are those who feel that can’t
>             mandate a single model structure for network devices and
>             we need mechanisms to manage multiple models but allow for
>             different device structure (e.g.,
>             https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt).
>             I hope we can agree on an approach in the coming interim
>             meetings.
>
>
>             Do you expect "everything in its place" to apply to all
>             other SDOs and
>             all vendor modules? Or do you expect just the IETF routing
>             modules
>             to follow this subtree hierarchy? If the former, does this
>             mean the
>             YANG Routing Design Team is the "YANG data placement
>             authority"
>             or all YANG modules that ever get written? How long should
>             it take for all other SDOs and vendors to redo all their
>             existing
>             modules to re-root them in their assigned place in the
>             data tree?
>
>             IMO is is not a good idea to rely on rigid data node
>             placement,
>             and a single data placement authority. It is better and
>             use meta-data
>             built from the YANG modules (or YANG packages) instead.
>
>     I think that having fixed paths may end up being too restrictive.
>
>
>
> 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.

E.g. I had suggested that it might be good if the Diffserv QoS YANG 
model was located in some slightly more abstract QoS containers/choices 
(e.g. for queuing/shaping/policying/etc).

Mainly my reasoning for this was the observation that vendor specific 
extensions would probably fit better augmenting generic QoS containers 
rather than a DiffServ specific QoS model (e.g. if they were adding L2 
specific QoS features which wouldn't sit cleanly on top of a specific L3 
QoS model).  However, I think that Norman Finn also mentioned a 
requirement from Deterministic Networking where it may be necessary to 
interact with some abstract QoS parameters without having to know the 
precise details of the underlying QoS model.

One other observation is that if we do end up with some more hierarchy 
then the "can't augment with mandatory node" issue may become a much 
more widespread issue.  Today, top level models can introduce mandatory 
nodes, but if they were all augmentations of an existing container they 
would not be able to (without a P-container).


> Even if such a lake could be brought to a boil, I have no confidence
> that the hierarchy will be 100% stable.  It can certainly
> never be 100% complete.  If the IETF thinks it's a good idea
> to obsolete all YANG RFCs and start over now, who is to say
> the IETF won't do that again every few years?

My perception is that YANG models and how to fit them together are still 
somewhat in flux.  There are lots of drafts defining YANG models were 
folks (myself included) are trying to figure out how these models should 
all fit together, but relatively few published RFCs.  So, personally I 
think that there is still a potential opportunity to add some more 
structure at this time if the desire is strong enough.  But I'm new to 
IETF, and hence perhaps this is just my naivety of the IETF processes.  
Three years down the line and I doubt that will be the case - there will 
be too much inertia, and unless it is very broken it won't get changed.


>
>
>
>             The reason Linux uses packages to install/update functionality
>             is because managing 8000 packages is hard enough.
>             Managing 247,000 individual files would be insane.
>             The actual location of files is quite configurable and
>             different
>             across distros. We could learn something from the last decade
>             of Linux package management, and try to apply it to YANG.
>
>         That’s an interesting idea, could a YANG package also specify,
>         e.g. that the root node for the package is X/Y/Z? This could
>         solve some use cases for relocatability, and it would also be
>         relatively easy to modify all absolute XPath expressions
>         inside the package.
>
>     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.
>
>
>     Having YANG packages being able to control the relative paths of
>     the imported YANG modules would possibly allow for more
>     flexibility in how YANG modules fit together, and also give a more
>     pragmatic way for how these could be changed/upgraded in future if
>     necessary.
>
>
>
> YANG packages provide a way to describe a set of modules.
> They do not change the top-level data nodes of any objects.
> This would be very complicated and not really worth it.
>
>
> IMO the "tree of NP containers" should be a resource directory,
> meaning it contains links to the real resources.  Kind of like an
> index in a library.  They don't keep the contents of every book in the 
> index.
> They keep the location of every book in the index.  The index is stable.
> The resource location does not have to be stable.
What would the real resource location for 
"/network/device/<device-name>/interfaces/interface" be?  If the 
concrete location for all interfaces (regardless of device) was the flat 
list /interfaces/ then you would get clashes between the names of the 
interfaces on different devices.  Also, what if someone wanted two 
separate lists of interfaces in two separate parts of the resource 
hierarchy.  Would that be feasible?

Thanks,
Rob


>
>
>     Cheers,
>     Rob
>
>
> Andy
>
>
>
>
>         Lada
>
>
>
>
>
>             Thanks,
>             Acee
>
>
>             Andy
>
>
>
>             From: netmod <[e-mail]
>             <mailto:[e-mail]>> on behalf of "Einar
>             Nilsen-Nygaard (einarnn)" <[e-mail]
>             <mailto:[e-mail]>>
>             Date: Monday, August 10, 2015 at 5:29 AM
>             To: Jonathan Hansford <[e-mail]
>             <mailto:[e-mail]>>
>             Cc: NETMOD Working Group <[e-mail]
>             <mailto:[e-mail]>>
>             Subject: Re: [netmod] Y34 - root node
>
>             As someone sharing responsibilities for guiding a number
>             of development teams both defining new models and
>             implementing to some already defined models in this area,
>             I can only agree with this addition to what I said earlier.
>
>             Cheers,
>
>             Einar
>
>                 On Aug 10, 2015, at 9:46 AM, Jonathan Hansford
>                 <[e-mail]
>                 <mailto:[e-mail]>> wrote:
>
>                   And it is not just end users who need help to better
>                 understand YANG models and how to use them. For those
>                 still on the edge, looking to finally take the plunge
>                 and use NETCONF/YANG to configure their devices, help
>                 is also required to determine how best to structure
>                 their YANG models, make use of the existing ones, etc.
>                 For those who have "grown up" with the developments in
>                 NETCONF and YANG, much of this is probably second
>                 nature. But coming to it cold (in the sense of
>                 compiling/writing a first set of YANG models for a
>                 device; I've been following the netconf/netmod WGs for
>                 3+ years), it still feels very much like a dark art!
>                 It is not just the individual modules, it is how to
>                 put them together to best manage a device (let alone a
>                 system).
>
>                 Jonathan
>
>
>
>                 ----- Original Message -----
>                 From:
>                 "Einar Nilsen-Nygaard (einarnn)" <[e-mail]
>                 <mailto:[e-mail]>>
>
>                 To:
>                 "Andy Bierman" <[e-mail]
>                 <mailto:[e-mail]>>
>                 Cc:
>                 "NETMOD Working Group" <[e-mail]
>                 <mailto:[e-mail]>>
>                 Sent:
>                 Sat, 8 Aug 2015 11:10:15 +0000
>                 Subject:
>                 Re: [netmod] Y34 - root node
>
>
>                 Andy,
>
>                 I agree that there is a need for organization of
>                 models, but I don’t have a firm position on
>                 draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model
>                 or draft-bierman-netmod-yang-package. But we
>                 absolutely need *something* to help end-users of the
>                 models comprehend the overall structure of models,
>                 their relationship and how to use them.
>
>                 Cheers,
>
>                 Einar
>
>                 On Aug 4, 2015, at 5:16 PM, Andy Bierman
>                 <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>
>                 On Tue, Aug 4, 2015 at 2:34 AM, t.petch
>                 <[e-mail] <mailto:[e-mail]>> wrote:
>                 ----- Original Message -----
>                 From: "Andy Bierman" <[e-mail]
>                 <mailto:[e-mail]>>
>                 To: "t.petch" <[e-mail]
>                 <mailto:[e-mail]>>
>                 Sent: Monday, August 03, 2015 5:17 PM
>
>                     ----- Original Message -----
>                     From: "Andy Bierman" <andy@yumaworkscom>
>                     To: "t.petch" <[e-mail]
>                     <mailto:[e-mail]>>
>                     Sent: Monday, August 03, 2015 4:10 PM
>
>                         ----- Original Message -----
>                         From: "Andy Bierman" [e-mail]
>                         <mailto:[e-mail]>
>                         Sent: Saturday, August 01, 2015 7:05 PM
>                         On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem
>                         (acee) <[e-mail] <mailto:[e-mail]>>
>
>                             On 8/1/15, 2:51 AM,
>                             [e-mail]
>                             <mailto:[e-mail]>>
>                             wrote:
>
>                             Section 1.1 in
>
>                     https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
>
>                             lists the goals of a generic model
>                             structure that will accommodate
>
>                         most
>
>                             modern network devices. I guess you don’t
>                             agree that these are
>
>                         desirable?
>
>                         The only objection I have to this draft is the
>                         insertion of a
>
>                 top-level
>
>                         root
>                         called "device".  (Might as well be called
>                         "self").
>                         There are no sibling nodes planned or intended for
>                         this node, so it serves as an extra document root.
>
>                         <tp>
>                         One aspect of YANG I have never grasped is
>                         what a root means, if
>                         anything.
>
>                         I understand that it is needed for NETCONF
>                         (filters) and for YANG
>                         (augments, constraints) and so must be
>                         somewhere and must be
>
>                     relatively
>
>                         stable, but has it any other significance in
>                         the data model?
>
>                         As you may recall, I was involved with SMI
>                         first, where the root is
>                         somewhere up in the sky and life only becomes
>                         interesting some six
>                         levels down the hierarchy and that may colour
>                         my thinking.
>
>                     YANG does a poor job of defining the root for YANG
>                     data nodes.
>                     It is sometimes called a datastore (in the abstract).
>                     Technically, YANG borrows the definition from XPath.
>                     YANG just defines top-level data nodes and the
>                     parent of
>                     these nodes is the document root
>
>                     There is no protocol or encoding neutral definition,
>                     only an XML-specific definition.
>
>                     <tp>
>
>                     Thanks for that.
>
>                     It seems to me that much of the extensive
>                     discussion on Y34 (all of
>                     which I have read) is as much political as
>                     technical, that is SMI is
>                     hierarchical, top down, perhaps befitting its
>                     origins in ISO, whereas
>                     YANG is bottom up. IETF-like.  YANG could have had
>                     a single tree, but
>                     doesn't.  So when I read
>
>                     https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
>
>                     I see a plea for a more hierarchical organisation,
>                     and when I read
>
>                     draft-bjorklund-netmod-openconfig-reply-00
>
>                     I see a response that says we are not like that.
>
>                     If so, I doubt that there ever will be a technical
>                     solution.
>
>                     And I am mindful that when I configure routing in
>                     a (Cisco) router, I
>                     have to do some of it under the interface
>                     definitions and some of it
>                     under the definition of the routing protocol.
>                     Which is life, never
>                     wholy interface-centric and never wholy routing
>                     protocol-centric!
>
>                 Are you saying the job would be easier if the
>                 path was /device/interfaces/interface instead
>                 of just /interfaces/interface?  Are you saying
>                 that /protocols/routing could not also be defined?
>                 Clearly edit-config and copy-config allow both
>                 subtrees to be accessed in the same operation,
>                 so I don't understand your concern.
>
>                 I have been trying to get the root node to be better
>                 defined
>                 in the protocols that use YANG (i.e., ncx:root, Y34-04).
>                 IMO this is a better approach than defining a YANG module
>                 with a special container that all other modules are
>                 expected
>                 to augment.  YANG is designed such that each vendor or SDO
>                 is not dependent on other vendors or SDOs in order to
>                 define data nodes.
>
>                 <tp>
>
>                 Andy
>
>                 I am agreeing with you that adding 'device' brings no
>                 technical benefit,
>                 rather that the motivation is the opposite of
>                 technical (which I
>                 referred to as political). I am also agreeing with the
>                 current declared
>                 consensus on Y34.
>
>                 And yes, YANG is going to give us a large number of
>                 modules, some
>                 tightly coupled (augments) some loosely so (how many
>                 do you need to
>                 configure OSPF?) and work in this area will be of
>                 benefit now and
>                 probably essential in a few years time.  That said, I
>                 am unsure what
>                 such work would be like; I am looking (in despair) at
>                 50 routing area
>                 YANG models and wondering how a user will ever get a
>                 coherent picture of
>                 how to do what they want to do.
>
>
>
>                 The "YANG Land Grab" gives a false sense of progress.
>                 Reaching WG consensus on every single leaf is hard work.
>
>                 I don't think a collection of 100s of YANG modules is ever
>                 going to to be easy to understand.  Operators will not
>                 examine
>                 a NETCONF <hello> message, look at 150 module URIs,
>                 and say "I know exactly what this device supports".
>                 I guess it is up to client tools to do that
>
>                 I wrote a draft that defines YANG Packages, which can
>                 provide
>                 a higher level of organization for YANG modules.
>
>                 http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
>
>                 You and I are apparently in the minority, since the
>                 official status
>                 is that there is no problem with the current approach,
>                 and no need
>                 to organize individual YANG modules into any larger
>                 abstractions.
>
>
>
>                   Tom Petch
>
>
>
>                 Andy
>                   Andy
>
>                     Andy
>
>                         The well-specified XPath and YANG root (/) can be
>                         accessed by all protocol operations, exactly
>                         the same
>                         as a node called 'device'.  The actual node
>                         name will
>                         depend on the RPC function (e.g. 'data' or
>                         'config').
>
>                         This is more than redundant however.  It
>                         introduces a "super-module"
>                         into YANG that every other module is expected
>                         to augment.
>                         YANG is intended to be more loosely coupled
>                         than that.
>                         This introduces an extra node and namespace
>                         declaration
>                         in all protocol messages, increasing message
>                         sizes.
>
>                         It also assumes all existing YANG models will
>                         get rewritten to
>                         account for "/device" in all path and XPath
>                         expressions.
>                         This is highly disruptive to existing deployments.
>                         Also, multiple data models to edit the same
>                         thing causes lots
>                         of extra complexity in the server (supporting
>                         both old
>                         location and new location).
>
>                         IMO a resource directory approach is much more
>                         realistic.
>                         The /device tree can contain all the organized
>                         NP containers.
>                         Instead of all the actual data nodes, this
>                         tree just has pointers
>                         to the real location of the resource. (like
>                         301 Moved Permanently)
>
>                             Acee
>
>                         Andy
>
>
>                 ** Solution Y34-02
>
>                    Keep 'anyxml'.  Introduce 'anydata' as above but
>                 without the
>                    'format' substatement.
>
>                    'anyxml' would still be used to represent
>                 unrestricted XML, as is
>                    done in NETCONF.
>
>                    'anydata' would be an unknown chunk of data that
>                 can be modelled
>                    with YANG.  Can be encoded as xml or json.
>
>                    For example:
>
>                      #+BEGIN_EXAMPLE
>                      anydata data;
>                      #+END_EXAMPLE
>
>                 ** Solution Y34-05
>
>                     Same as Y34-02 plus two guidelines adopted from
>                 Y34-04:
>
>                     - Keep 'anyxml' unchanged as it is defined in YANG
>                 1.0. This
>                       ensures backward compatibility.
>                     - Introduce a new 'anydata' statement that
>                 represents an unknown
>                       chunk of data that can be modeled with YANG
>                     - Document that implementations MAY have
>                 restrictions for anyxml and
>                       that anyxml is not necessarily interoperable;
>                 data model writers
>                       should use anydata whenever possible.
>                     - The guidelines document should say that YANG
>                 Doctors will review
>                       each use of anyxml in IETF modules when YANG 1.1
>                 is adopted to
>                       avoid its use whenever possible.
>
>
>
>                 _______________________________________________
>                 netmod mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/netmod
>
>
>             _______________________________________________
>             netmod mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/netmod
>
>
>             _______________________________________________
>             netmod mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/netmod
>
>         --
>         Ladislav Lhotka, CZ.NIC Labs
>         PGP Key ID: E74E8C0C
>
>
>
>
>         _______________________________________________
>         netmod mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/netmod
>
>
>