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

[Nadeau Thomas <[e-mail]>]

> On Aug 18, 2015:11:04 PM, at 11:04 PM, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Tue, Aug 18, 2015 at 6:38 PM, Lou Berger <[e-mail] <mailto:[e-mail]>> wrote:
> [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.)
> 
> 
> Tom sent the meeting invite to netmod so I figured that was where we were
> supposed to discuss drafts.

	The meeting invite was to get peoples’ attention and ask that people start planning ahead.
However, please discuss here ahead of time. 

> 
> 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.
> 
> 
> Sort of confusing because this draft says it is based on the other draft,
> so one assumes it is meant to replace it.
> 
> 
>  
> >
> >
> > https://tools.ietf.org/html/draft-rtgyangdt-rtgwg-device-model-00 <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.
> 
> 
> OK -- the YANG modules themselves should say how they
> relate to each other.  I guess you mean the logical-network-element
> and other framework nodes.
> 
> 
> 
> > 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?
> 
> 
> 
> So this document is not the actual set of NP containers
> that all YANG modules are supposed to augment?
> It would help to understand how the tree will be managed
> and maintained over time.
> 
> 
> >
> > 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.
> 
> If a vendor has their own proprietary protocol or HW type,
> where does it go in the tree?  The set of modules used for some
> function may not be coupled to one node in the data tree. 

	Its useful if these sorts of things are added to the requirements.

> But it is OK if this is out of scope.
> It is no different than any other standard module that a vendor
> could augment with proprietary data.
> 
>  
> > What is the scope of this work?
> see slide 7 of
> https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf <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.
> 
> So what is the plan for YANG modules that are not specific to these devices?
> For example, some modules like interfaces and NACM could be
> implemented on any platform, even constrained devices 
> (maybe running CoMI over CoAP). 

	Again, good to add to the requirements document.  Backwards compatability is something
we must address; we are unlikely to go forward with a plan that obsoletes everything
that exists today - or at least without a plan to move those things forward.

> > 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.)
> 
> 
> 
> I understand the value of finding data via familiar keywords.
> (The CLI never went away -- it just grew angle brackets ;-)
> It is useful to be able to debug with nothing more than a
> WEB browser and URLs typed by hand. I could never remember
> a single SNMP OID but YANG data is easy to remember.
> 
> From the start, the NETCONF and NETMOD WGs rejected
> attempts at data organization because it should not matter
> to a programmatic API.

	It does not matter technically speaking, but I think the thing the operators
are saying here is that if its organized in this specific way, it not only makes
their lives easier, it allows them to do things better/less expensively.  That
seems important.

> 
> >
> > 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 <https://tools.ietf.org/html/rfc7223>>] and includes possible
> >    technology-specific augmentations using example technologies defined
> >    in [RFC7277 <https://tools.ietf.org/html/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?
> 
> 
>  I did not find any augment statements in model-structure.yang.
> 
> You have to augment /interfaces, not /device/interfaces,
> if you are using RFC 7223.
> 
> 
> 
> 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 <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.
> 
> 
> 
> IMO this logical structure should not be part of data hierarchy itself,
> since it does not apply to all devices.

	This is an important issue to get to the bottom of.  Is this in the
requirements?

> YANG does not provide a way for the hierarchy to be
> one way for the physical view and another for
> a virtual view. The same /path/to/data is seen by both.
> Is this really what you want?

	Please add (or not) to the requirements.

> 
>  
> > 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.
> 
> Each virtual view sees its own slice of the physical device as an
> entire device, not as 1 entry in a more complex model.
> 
> IMO it would be better to define a separate data structure and
> tag it as a special nested datastore root.  (e.g. YANG mount).
> 
> Maybe this would work:
> 
>   container virtual-devices {
>      list virtual-device {
>         key device-id;
>         ...
>         container device {
>             // same data models as the /device contents
>          }
>      }
>   }
> 
>   container device { ... }
> 
> 
> 
> Thanks for the comments/discussion!
> 
> Lou
> 
> > Andy
> >
> 
> 
> Andy

	It seems there are a number of things that should be teased out here as issues that we can come to a
consensus on.  Some of these things do not appear in the requirements. Can we get those in there
if we agree on them?  The others we could track as issues.

	—Tom


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