> On Aug 19, 2015:10:31 PM, at 10:31 PM, Lou Berger <[email protected]> wrote:
>
> On 08/19/2015 08:48 AM, Nadeau Thomas wrote:
>>
>>> 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
>>
>
> 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
Fair enough.
—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
