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

[Lou Berger <[e-mail]>]

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, 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.

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

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

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

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