Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00

[Martin Bjorklund <[e-mail]>]

Lou Berger <[e-mail]> wrote:
> Martin,
> 
> See below.
> On 08/19/2015 05:27 AM, Martin Bjorklund wrote:
> > Hi,
> > 
> > Lou Berger <[e-mail]> wrote:
> >> On 8/18/2015 8:01 PM, Andy Bierman wrote:
> >>> Q1) scope
> >>>
> >>>
> >>> sec 2:
> >>>
> >>>    The model organization can itself be thought of as a "meta-model",
> >>>    in that it describes the relationships between individual models.  We
> >>>    choose to represent it also as simple YANG model consisting of lists
> >>>    and containers to serve as anchor points for the corresponding
> >>>    individual models.
> >>>
> >>>    As shown below, our model is rooted at a "device", which represents a
> >>>    network router, switch, or similar network element.  
> >>>
> >>>
> >>> Why is this a meta-model?
> >> because the aim to to show how other models inter-relate rather than
> >> define the details of all models. As stated in the intro:
> >>
> >>    This document aims to provide an extensible structure that can be
> >>    used to tie together other models. It allows for existing, emerging,
> >>    and future models. The overall structure can be constructed using
> >>    YANG augmentation and imports.
> >>
> >>
> >>> It looks like a real YANG data model where ad-hoc classification is
> >>> being done
> >>> using container names.
> >>
> >> Sure, we're using YANG, or at least trying, to document our proposal. 
> >> Do you think there's a better way to formally document the work?
> > 
> > I can see two approaches:
> > 
> >   1) Define a YANG module with the structural hierarchy.  Then
> >      other modules augment this module at the correct place in the
> >      hierarchy.  This module will probably be updated pretty often,
> >      especially if the idea to have ONE module with the complete
> >      hierarchy for ALL types of devices.
> > 
> >      A variant is to define such a module for routing-specific modules
> >      only to augment.  Other areas can define similar "structural"
> >      modules.
> > 
> Or device additions can augment the base model.
> 
> >   2) Document the hierarchy as a guideline.  When it is time to work
> >      on a new module, lets say mpls, we look into this guideline and
> >      define the necessary hierarchy in the mpls module.
> > 
> 
> I think this is a good topic to discuss.  The second sounds lighter
> weight as long as it is followed while the first makes it hard to not
> follow. I see advantages in both.
> 
> > 
> >>> If vendors augment this tree with their own ad-hoc hierarchy, then how
> >>> is this
> >>> any better than what we have now?
> >>>
> >> This goes to requirements which is really in the scope of
> >> draft-openconfig-netmod-model-structure.  From my perspective it comes
> >> down to how much information is needed from an actual device in order to
> >> come up with its yang-based configuration, and the principle that there
> >> is benefit in this being minimized.  For example, consider the case
> >> where a config is generated before a specific device is fielded or
> >> perhaps even purchased/selected.
> > 
> > As long as the device implements standard data models, why does it
> > matter for pre-provisioning if the standard path to configure an
> > interface is /devices/interfaces/interface or /interfaces/interface?
> > 
> 
> I personally see the top level as more about logical separation of model
> types/classes

This then sounds like meta data about the model.  What kind of model
is it - see draft-bogdanovic-netmod-yang-model-classification.

I don't think it is a good idea to encode meta data into the data
hierarchy.  It would be better IMO to keep this either inline in the
module definition (yang-model-type device;) or externally in a
separate registry.


> like a top level directory structure.  So IMO it's a bit
> subjective and really about establish and agreeing upon conventions. --
> and there's a group of users who say they really like it one way.
> 
> Deeper in the hierarchy the path becomes more significant, but you
> weren't really questioning this.

I am all for significant nodes in the path!  My point is that /device
is insignificant.


> >>> What is the scope of this work?
> >> see slide 7 of
> >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf
> >>
> >>> It appears to be only for "routers switches or similar network elements".
> >>>
> >> >From the slide:
> >>    From DT charter: An overall architecture for
> >>    “the protocols and functionality contained inside the Routing Area”
> > 
> > But the design you propose has huge impact on all models, also models
> > from other areas.
> 
> A very fair point and why it's important to discuss in this WG.  No
> discussion happened in the prague session largely due to multiple
> scheduling conflicts.
> 
> > 
> >>> Q2) interfaces
> >>>
> >>>    The interface model is taken from [RFC7223 <https://tools.ietf.org/html/rfc7223>] and includes possible
> >>>    technology-specific augmentations using example technologies defined
> >>>    in [RFC7277 <https://tools.ietf.org/html/rfc7277>].
> >>>   +--rw interfaces
> >>>       |  +--rw interface* [name]
> >>>       |     +--rw name                       string
> >>>       |     +--rw bind-network-element-id?   uint8
> >>>       |     +--rw ethernet
> >>>       |     |  +--rw bind-networking-instance-name?   string
> >>>       |     |  +--rw aggregates
> >>>       |     |  +--rw rstp
> >>>       |     |  +--rw lldp
> >>>       |     |  +--rw ptp
> >>>       |     +--rw vlans
> >>>       |     +--rw tunnels
> >>>       |     +--rw ipv4
> >>>       |     |  +--rw bind-networking-instance-name?   string
> >>>       |     |  +--rw arp
> >>>       |     |  +--rw icmp
> >>>       |     |  +--rw vrrp
> >>>       |     |  +--rw dhcp-client
> >>>       |     +--rw ipv6
> >>>       |        +--rw bind-networking-instance-name?   string
> >>>       |        +--rw vrrp
> >>>       |        +--rw icmpv6
> >>>       |        +--rw nd
> >>>       |        +--rw dhcpv6-client
> >>>
> >>>
> >>> Actually the interface model is quite different than the one in RFC 7223.
> >>> Seems rather ethernet-centric.  I notice the "type" leaf was removed,
> >>> along with everything else.  Is the plan to toss out RFC 7223,
> >>> recharter the interfaces work, and start over?
> >>>
> >>
> >> So this may be our/my inexperience at play here.  I didn't think it
> >> appropriate for a document that is augmenting an existing model to
> >> redefine the current model - I actually thought this was part of the
> >> power of YANG augmentation.  Are you saying we should have included the
> >> whole 7223 model to augment it, or something different?
> > 
> > As long as you want to have /device/interfaces, you need to obsolete
> > the model in RFC 7223 (and all other published YANG models) and
> > rewrite them.  However, if we get rid of the /device container, the
> > existing model in RFC 7223 fit in nicely in your hierarchy.
> 
> And this is certainly an important point, and I personally think we
> should have a full discussion of if it's worth preserving RFC 7223 or
> open the door for changing  it.  We had many discussions on this in the
> DT and while multiple wanted to do an even larger change, in the end the
> consensus was to try minimize impact to the this and other RFCs -- even
> if it meant using somewhat more cumbersome mechanisms.
> 
> > 
> > I think many of us have said this before, but the top-level container
> > /device doesn't really solve any problem.  Suppose we have a module
> > today with a top-level node /FOO.  Why would this module work better
> > if it augemented /device to give /device/FOO?
> > 
> 
> as mentioned above, I personally think this is about logical separation
> of model types/classes, like a top level directory structure.  So IMO
> it's a bit subjective and really about establish and agreeing upon
> conventions. -- and there's a group of users who say they really like it
> one way.

Hopefully, a decision to change all existing models (including vendor
models!) will be based on something more technical than the fact that
a group of people "really like it" some other way.

> > Maybe the problem you are trying to solve with "/device" is what is
> > written in section 3.1:
> > 
> >    One of the challenges in assembling existing YANG models is that they
> >    are generally written with the assumption that each model is at the
> >    root of the configuration or state tree.  Combining models then
> >    results in a multi-rooted tree that does not follow any logical
> >    construction and makes it difficult to work with operationally.  In
> >    some cases, models explicitly reference other models (e.g., via
> >    augmentation) to define a relationship, but this is the case for only
> >    a few existing models.
> > 
> > First of all I don't really agree with this.  We just have a few
> > module published, but for example ietf-ip augments ietf-interfaces,
> > and the idea with ietf-routing is that routing-specific modules
> > augment it.  In fact, I think the published modules follow your
> > proposed hierarchy (with some exception) - if it wasn't for the
> > /device node.
> > 
> > Second, if we want to be conservative with top-level nodes (I am not
> > convinced that this is a problem) we can solve that without going into
> > the extreme of having *one* top-level node.  
> 
> Why do you say only one top level node.  This isn't my exception, nor do
> I see this stated in the draft.  I do think we say one top level node
> dealing with device configuration.

In light of what you explained, I can rephrase this:  On any given
implementation there will always only be one top-level node.  For
example, on a device, the top-node is always /device.  Correct?

> > Instead of having N
> > top-level nodes, we would have N nodes under /device.  Why is this
> > better?
> 
> N would contain only device configuration related modules.  There could
> be others, e.g., /services has been mentioned by some.
> 
> > 
> >> Are you referring to section 2.3?  If so, I think we all agree (and said
> >> as much in Prague) that this section could be clearer.  We/I tried to
> >> explain it in the Prague slide 25 (for this you may want to see the
> >> animation in
> >> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pptx)
> >>
> >> Basically the amount of information provided depends on the
> >> logical-network-element context used to access this information.  So if
> >> a model is "retrieved" via an IP address associated with a
> >> network-element-id  with device-view=true (e.g., the left side of slide
> >> 25), then the device's full view is provided.  And when a model is
> >> "retrieved" via an IP address associated with a network-element-id  with
> >> device-view=false (e.g., the ride side of slide 25, either color) only
> >> information related to the network-element-id is provided.
> > 
> > Do you want the user from a particular IP address to have access to
> > just his part of the tree, or do you want that user to have his own
> > "sandbox" that he can control independently of other users?
> 
> The intent was multiple logical-network-elements and when
> device-view=false, any management operation taking place in the context
> of that LNE would only have visibility and ability to control that LNE.
>  This matches a pretty common feature set.

Ok, so this means that there is still just one configuration for all
logical-network-elements, right?  E.g., if a user from
logical-network-element A locks the datastore, he will lock out a
user from logical-network-element B; if user from A saves running to
startup changes for B will also be saved, etc?




/martin




> 
> > 
> > In the first case, you can use NACM to set up rules to give each user
> > proper access (based on user identity rather than IP address though).
> 
> I think this would be used too.  For example user1 would have ro access
> while user2 has rw.
> 
> > You don't need this "device-view" in order to do this.
> Agreed, but this is something different and matches how a multiple
> devices from multiple vendors function today.
> 
> > 
> > In the latter case, I don't think the proposed design works.  (I can
> > go into details if it turns out that this what you had in mind).
> I think we're interested in a form of the first.
> 
> Lou
> 
> > 
> > 
> > 
> > /martin
> > 
>