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

[Lou Berger <[e-mail]>]

[Adding authors and RTG WG.]

Hi Andy,
    I'm not sure who you are looking to hear from as you addressed this
mail to the netmod list. I'm happy to give my opinion as it seems you
might have been aiming this at the draft authors.  (but then again
perhaps not.) 

On 8/18/2015 8:01 PM, Andy Bierman wrote:
> Hi,
>
> I assume this draft is what we should be reviewing and not
> the obsolete openconfig draft?

My personal view / hope is that the openconfig draft will be revised to
cover requirements while the DT draft  leads to an agreed upon approach
to addressing those requirements.  Again, just stating my view, not the
view of the DT, co-authors or OC draft authors.

>
>
> https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00
>
>
> 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?
 
>
> 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. But again, this more of a requirements
discussion.

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

> The hierarchy seems quite router-centric.
It is intended to be network device centric, routers, switches,
firewalls, etc.

> Is the expectation that all YANG-based devices will use this
> data hierarchy, or only some devices?
The proposal is to provide a framework for any device that supports a
protocol or other mechanism defined within the routing area.  (Or at
least that's our understanding of what we were asked to do.)

>
> Is the expectation that all YANG modules will use this
> data hierarchy, or only some modules? 

I personally think there will be siblings to /device, e.g., /service -
but this is beyond the scope of this draft.

> Is it just
> for IETF routing modules or more than that?
>
I think this is the same question and answer as above.

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

Also not the text says:
        ... possible technology-specific augmentations  using example
technologies ..
and

   The interfaces container includes a number of commonly used
   components as examples:

> Q3) virtual devices
>
>    The model supports the potentially independent system management
>    functions and configuration per logical network element. This
>    permits, for example, different users to manage either the whole
>    device or just the associated logical network element. 
>
> Sec 2.2.1 shows the system management tree but it is wrong.

Yes, good catch of a cut-and-past bug. thankfully it is correct both
immediately before in the section intro and the details

> The following tree is what the YANG model defines:
>  +--rw device
>           +--rw logical-network-elements
>                -rw logical-network-element* [network-element-id]
>                    +--rw network-element-id                  uint8
>                    +--rw network-element-name?               string
>                    +--rw default-networking-instance-name?   string
>                    +--rw system-management
>                    |  +--rw device-view?                      boolean
>                    |  +--rw syslog
>                    |  +--rw dns
>                    |  +--rw ntp
>                    |  +--rw statistics-collection
>                    |  +--rw ssh
>                    |  +--rw tacacs
>                    |  +--rw snmp
>                    |  +--rw netconf
> What about devices that do not have logical network elements?
It would have only a single network-element-id

> This hierarchy may be appropriate for very large routers
> but nothing else.
The intent is to cover all implementations independent of vendors.  We
had a good range of view points both in the DT and in the RTGWG
discussion.  Not saying there was full agreement, just that we have a
proposed starting  point.

> How can this tree represent both the physical view and the virtual view?
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.

> It seems to assume this is the "root user physical view".
> Please explain how device-type=VIRTUAL is used.

This is a bit different and hasn't been a major point of discussion in
the WG -- we brought this over from the openconfig draft.  I read this
as being pretty uninteresting and simply set based on if the device is
running on dedicated special purpose h/w (e.g, a classic
"name-your-vendor" router) or as a VM (aka NFV).  I'll defer to the OC
or other DT folks if their opinion differs.

Thanks for the comments/discussion!

Lou

> Andy
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod