[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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod