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

[Lou Berger <[e-mail]>]

Martin,
	Sorry for the delayed response, was away for a bit.  Not sure if any of
this is OBE as just starting to catch up on mail.

On 08/20/2015 03:58 AM, Martin Bjorklund wrote:
> 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.
> 

Perhaps.  I'll defer to Dan on this as he's also a co-author/DT member.

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

This is really good/useful to hear.  If disagreement is limited to the
top level node, it's much easier (but not easy ;-) problem to solve.

> My point is that /device
> is insignificant.

I think the fundamental discussion here, is who get's to say what's
significant and we have (at least) two opposing views on this point.

>From my standpoint it comes down to how you view full set of models that
may be seen.  From the device view, you might only (or, more likely,
mostly) see models under /device -- so device doesn't add much value.
BUT from the controller/NMS/EMS (or whatever you want to call it) view,
you're likely to see all the models so /device plays a much more
significant role in identifying logical model
organization/understanding.  -- That said, I'm much more of a device
person than an NMS builder, so I'm also willing to trust the opinion of
folks who are clearly doing significant work on the controller/NMS side.

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

I'm equally unsure that having an argument of "I got there first" is a
compelling argument given the number of folks (including vendors) who
have stated willingness (or even support) for change.  I think having a
major class of users stand up and say this is important should garner
some notice.
-- In the end, this is largely a (I think) netmod WG decision.

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

I don't think this will always be the case for *all* devices, but it may
always be the case for *some*.  as previously answered:

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

If A (or B) has device-view=true, I think so.  If both have
device-view=false, I suspect this may be implementation specific, but am
not sure.

Lou

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