On 08/19/2015 08:48 AM, Nadeau Thomas wrote: > >> On Aug 18, 2015:9:38 PM, at 9:38 PM, Lou Berger <lber...@labn.net> 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.) >> >> 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 > > Can you be specific about which requirements you feel are not covered ? > > —Tom >
I wasn't commenting on what's covered/not covered. I was saying that I don't think the openconfig draft should disappear, rather it should be revised to just focus on requirements. Lou > >> 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 > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
