> On Aug 18, 2015:9:38 PM, at 9:38 PM, Lou Berger <[email protected]> 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
> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
