Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On 08/26/2015 03:48 PM, Andy Bierman wrote: On Wed, Aug 26, 2015 at 12:33 PM, Lou Berger lber...@labn.net mailto:lber...@labn.net wrote: Tom, On 8/26/2015 9:34 AM, Nadeau Thomas wrote: ... This is exactly what I want to get on the table. So taking a step back, perhaps there is a YANG language question at the heart of this discussion. I think we're seeing cases where the same data model is useful in multiple cases/places. The example I like to use (although I know others disagree with the example) is the case of PE/CE config information, where some of the exact same information may end up on the CE and PE devices as well as the L3 service model. In this case we'd like a core model to be included (or linked) into two larger models. Importantly, I'm referring to doing this as part of model definition - not at server/device run time. This is important for the pre-provisioning case. It is my understanding that there is no way to really do this in a general and extensible way (including allowing for augmentations) today. If there was such support, I do think we'd be saying that we'd like the existing models to support this mechanism rather than our current proposal of being relocated . If you are talking about schema reuse, then YANG has groupings as the solution. My understanding is that the usage scope of groupings is pretty limited and not really suitable for complex (sub)tree/module representation. Also groupings can't be augmented But it seems you are talking about YANG Mount -- the ability to have a subtree on server X represent a different subtree on server Y. On the controller the 'mount point' is not the actual data root (as Martin has explained). On the NE, the data models are in their real location On the controller they are not. This can be done with an 'anyxml' hack today. It would be better to have real YANG support for this very basic use-case I think finding a yang-based solution (to reuse) would be helpful. Lou for YANG Mount. Lou (BTW this is my opinion, not speaking for the DT.) Andy ___ netmod mailing list netmod@ietf.org mailto:netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Tom, On 8/26/2015 9:34 AM, Nadeau Thomas wrote: ... This is exactly what I want to get on the table. So taking a step back, perhaps there is a YANG language question at the heart of this discussion. I think we're seeing cases where the same data model is useful in multiple cases/places. The example I like to use (although I know others disagree with the example) is the case of PE/CE config information, where some of the exact same information may end up on the CE and PE devices as well as the L3 service model. In this case we'd like a core model to be included (or linked) into two larger models. Importantly, I'm referring to doing this as part of model definition - not at server/device run time. This is important for the pre-provisioning case. It is my understanding that there is no way to really do this in a general and extensible way (including allowing for augmentations) today. If there was such support, I do think we'd be saying that we'd like the existing models to support this mechanism rather than our current proposal of being relocated . Lou (BTW this is my opinion, not speaking for the DT.) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Wed, Aug 26, 2015 at 12:33 PM, Lou Berger lber...@labn.net wrote: Tom, On 8/26/2015 9:34 AM, Nadeau Thomas wrote: ... This is exactly what I want to get on the table. So taking a step back, perhaps there is a YANG language question at the heart of this discussion. I think we're seeing cases where the same data model is useful in multiple cases/places. The example I like to use (although I know others disagree with the example) is the case of PE/CE config information, where some of the exact same information may end up on the CE and PE devices as well as the L3 service model. In this case we'd like a core model to be included (or linked) into two larger models. Importantly, I'm referring to doing this as part of model definition - not at server/device run time. This is important for the pre-provisioning case. It is my understanding that there is no way to really do this in a general and extensible way (including allowing for augmentations) today. If there was such support, I do think we'd be saying that we'd like the existing models to support this mechanism rather than our current proposal of being relocated . If you are talking about schema reuse, then YANG has groupings as the solution. But it seems you are talking about YANG Mount -- the ability to have a subtree on server X represent a different subtree on server Y. On the controller the 'mount point' is not the actual data root (as Martin has explained). On the NE, the data models are in their real location On the controller they are not. This can be done with an 'anyxml' hack today. It would be better to have real YANG support for this very basic use-case for YANG Mount. Lou (BTW this is my opinion, not speaking for the DT.) 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
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Martin,
On 8/26/2015 6:41 AM, Martin Bjorklund wrote:
Lou Berger lber...@labn.net wrote:
Martin,
Sorry for the delayed response, was away for a bit. Not sure if any of
this is OBE as just starting to catch up on mail.
On 08/20/2015 03:58 AM, Martin Bjorklund wrote:
Lou Berger lber...@labn.net wrote:
Martin,
See below.
On 08/19/2015 05:27 AM, Martin Bjorklund wrote:
Hi,
Lou Berger lber...@labn.net wrote:
[...]
Deeper in the hierarchy the path becomes more significant, but you
weren't really questioning this.
I am all for significant nodes in the path!
This is really good/useful to hear. If disagreement is limited to the
top level node, it's much easier (but not easy ;-) problem to solve.
My point is that /device
is insignificant.
I think the fundamental discussion here, is who get's to say what's
significant and we have (at least) two opposing views on this point.
From my standpoint it comes down to how you view full set of models that
may be seen. From the device view, you might only (or, more likely,
mostly) see models under /device -- so device doesn't add much value.
BUT from the controller/NMS/EMS (or whatever you want to call it) view,
you're likely to see all the models
Agreed, but see below.
so /device plays a much more
significant role in identifying logical model
organization/understanding. -- That said, I'm much more of a device
person than an NMS builder, so I'm also willing to trust the opinion of
folks who are clearly doing significant work on the controller/NMS
side.
[This was briefly discussed in another mail thread, and I'll repeat it
here.]
Thanks.
On the controller, you probably have a list of devices you control
(this is how our NCS works, and how ODL works (I have been told)):
container devices {
list device {
key name;
// meta-info about the device goes here, things like
// ip-address, port, auth info...
container data {
// all models supported by the devices are mounted here
}
}
}
So on the controller, the path to interface eth0 on device foo
would be:
/devices/device[name='foo']/data/interfaces/interface[name='eth0']
if we also have a top-level /device container we'd have:
/devices/device[name='foo']/data/device/interfaces/interface[name='eth0']
(here you again can see that the device node in the device model
doesn't make much sense)
if there are siblings, it could still make sense...
The path is scoped in the system you work with; in the controller it
might be as I illustrated above, in the device it starts with
/interfaces. But then you might also have a
controller-of-controllers. where the path might be:
/domains/domain[name='bar']/devices/device[name='foo']/data
/interfaces/interface[name='eth0']
Pushing all these concepts down into the device model clearly doesn't
help...
So, I think it would be good to hear from the openconfig folks on this
point. Perhaps they'll respond via e-mail, perhaps it'll have to wait
for the interim...
Thanks,
Lou
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Wed, Aug 26, 2015 at 09:41:26AM +, Acee Lindem (acee) wrote: On 8/26/15, 2:40 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people really like it some other way. I'm equally unsure that having an argument of I got there first is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. Other than adding /device at the top, we are not obsoleting RFC 7223. The current device model keeps the interfaces configuration silo and merely augments it with a binding to the logical-networking-element. For the sake of clarity, these are the YANG data models that are published as Proposed Standard RFCs: - RFC 6022 NETCONF Monitoring - RFC 6536 NETCONF Access Control Model - RFC 7223 Interface Management - RFC 7277 IP Management - RFC 7317 System Management - RFC 7407 SNMP Configuration I see text in draft-rtgyangdt-rtgwg-device-model-00 that seems to affect pretty much all of them. I also do not see augments it (RFC 7223) with a binding to the logical-networking-element in the YANG fragment in draft-rtgyangdt-rtgwg-device-model-00. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On 8/26/15, 2:40 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people really like it some other way. I'm equally unsure that having an argument of I got there first is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. Other than adding /device at the top, we are not obsoleting RFC 7223. The current device model keeps the interfaces configuration silo and merely augments it with a binding to the logical-networking-element. Thanks, Acee /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Aug 26, 2015:5:51 AM, at 5:51 AM, Lou Berger lber...@labn.net wrote: On August 26, 2015 2:42:26 AM Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people really like it some other way. I'm equally unsure that having an argument of I got there first is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. As Acee says, we have been trying very hard to minimize any impact to existing work even when the result is suboptimal. I also agree that changing PS RFCs should not be done without serious consideration. That said, the IETF process does permit updates and replacements based on WG and IETF consensus -- which is not quite the same as your last statement. Lou [Speaking for myself] Is the resistance to this proposal because of the actual changes to structure, or is it a resistance to churn/change? And if we solved the latter by say relaxing the rules around how we progress models to PS, would this alleviate the concerns for the former? The meta question I will ask is: is the existing RFC process adequate/sufficient for us to move forward on such a large scale with Yang models at the IETF? Other organizations currently iterate on models using certain revision conventions (that are consistent with the rules we put out here) yet produce multiple versions of the same model within the same year. As a matter of fact, multiple versions are allowed to coexist within a single implementation. In stark contrast, the M.O. at the IETF has been to treat Yang models much like we did SNMP MIBs (or any other document here) thereby assuming that once it becomes an RFC, that it is largely set in concrete for many years to come. —tom /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ rtgwg mailing list rt...@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund m...@tail-f.com wrote: Acee Lindem (acee) a...@cisco.com wrote: On 8/26/15, 2:40 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people really like it some other way. I'm equally unsure that having an argument of I got there first is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. Other than adding /device at the top, we are not obsoleting RFC 7223. This doesn't make sense. The YANG model is the contract. You are proposing changing the contract. The fact is that you will be obsoleting 7223 (and the other RFCs). Existing devices and applications will have to change in order to handle this new top-level node (which will be in some other namespace I presume, unless your proposal is one gigantic monolithic model). /martin Again I will ask: why is this bad? Obviously the implementation will have to evolve to the new models, but is this relatively static model where we really want to get to simply because some device vendors/server vendors find it a pain to iterate models to support the latest versions? Again, others have figured out how to do this much more rapidly. In the past we have seen what happens to things that cannot evolve fast enough... —Tom ___ 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
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Nadeau Thomas tnad...@lucidvision.com wrote: [Speaking for myself] Is the resistance to this proposal because of the actual changes to structure, or is it a resistance to churn/change? The former. IMO this is technically not a good proposal, as I have tried to explain several times. And if we solved the latter by say relaxing the rules around how we progress models to PS, would this alleviate the concerns for the former? The meta question I will ask is: is the existing RFC process adequate/sufficient for us to move forward on such a large scale with Yang models at the IETF? Other organizations currently iterate on models using certain revision conventions (that are consistent with the rules we put out here) yet produce multiple versions of the same model within the same year. As a matter of fact, multiple versions are allowed to coexist within a single implementation. In stark contrast, the M.O. at the IETF has been to treat Yang models much like we did SNMP MIBs (or any other document here) thereby assuming that once it becomes an RFC, that it is largely set in concrete for many years to come. In this specific case the change is cosmetic but has disastrous effects on other standard modules, other vendor-specific modules, existing server code and existing client code. I think people expect IETF standards to be a bit more stable than that. /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On August 26, 2015 6:24:19 AM Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Wed, Aug 26, 2015 at 09:41:26AM +, Acee Lindem (acee) wrote: On 8/26/15, 2:40 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people really like it some other way. I'm equally unsure that having an argument of I got there first is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. Other than adding /device at the top, we are not obsoleting RFC 7223. The current device model keeps the interfaces configuration silo and merely augments it with a binding to the logical-networking-element. For the sake of clarity, these are the YANG data models that are published as Proposed Standard RFCs: - RFC 6022 NETCONF Monitoring - RFC 6536 NETCONF Access Control Model - RFC 7223 Interface Management - RFC 7277 IP Management - RFC 7317 System Management - RFC 7407 SNMP Configuration I see text in draft-rtgyangdt-rtgwg-device-model-00 that seems to affect pretty much all of them. Agreed. Although we're proposing reusing / rehoming them. I also do not see augments it (RFC 7223) with a binding to the logical-networking-element in the YANG fragment in draft-rtgyangdt-rtgwg-device-model-00. This omission has been pointed out before. We need to fix that. Lou /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 http://www.jacobs-university.de/ ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) a...@cisco.com wrote: On 8/26/15, 8:09 AM, Martin Bjorklund m...@tail-f.com wrote: Nadeau Thomas tnad...@lucidvision.com wrote: On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund m...@tail-f.com wrote: Acee Lindem (acee) a...@cisco.com wrote: On 8/26/15, 2:40 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people really like it some other way. I'm equally unsure that having an argument of I got there first is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. Other than adding /device at the top, we are not obsoleting RFC 7223. This doesn't make sense. The YANG model is the contract. You are proposing changing the contract. The fact is that you will be obsoleting 7223 (and the other RFCs). Existing devices and applications will have to change in order to handle this new top-level node (which will be in some other namespace I presume, unless your proposal is one gigantic monolithic model). /martin Again I will ask: why is this bad? My point above was in reply to the statement that we are not obsoleting RFC 7223 [because the change is so small?] - you would in fact be obsoleting the model in 7223. There have been other mechanisms discussed to relocate YANG models. Perhaps, one of these could be employed in lieu of obsoleting the existing models. Thanks, Acee This is exactly what I want to get on the table. If we can agree on a mechanism/s to do relocate modules, then this might alleviate the resistance to evolve models. The current issue aside, if you step back and look at the wider IETF situation around all the Yang models being created and are RFCs, and the dependency graph that is created. You can then imagine a time after that point when others come along that evolve parts or entire modules. We currently refer to this as “obsoleting” all of the modules that it depends on, which is a very big problem using the current RFC process. Not only does it require a revision of all those RFCs (due to obsoleting the previous ones) - and thus all the procedural/management overhead that will incur - but the time lag from start to finish. And this might happen for any new module. This is not scaleable going forward. —Tom /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Wed, Aug 26, 2015 at 6:34 AM, Nadeau Thomas tnad...@lucidvision.com wrote: On Aug 26, 2015:9:09 AM, at 9:09 AM, Acee Lindem (acee) a...@cisco.com wrote: On 8/26/15, 8:09 AM, Martin Bjorklund m...@tail-f.com wrote: Nadeau Thomas tnad...@lucidvision.com wrote: On Aug 26, 2015:6:26 AM, at 6:26 AM, Martin Bjorklund m...@tail-f.com wrote: Acee Lindem (acee) a...@cisco.com wrote: On 8/26/15, 2:40 AM, Juergen Schoenwaelder j.schoenwael...@jacobs-university.de wrote: On Tue, Aug 25, 2015 at 10:53:55PM -0400, Lou Berger wrote: Hopefully, a decision to change all existing models (including vendor models!) will be based on something more technical than the fact that a group of people really like it some other way. I'm equally unsure that having an argument of I got there first is a compelling argument given the number of folks (including vendors) who have stated willingness (or even support) for change. I think having a major class of users stand up and say this is important should garner some notice. Please keep in mind that we are talking about several published proposed standards that have been implemented and deployed. I think there must be convincing technical reasons to declare them broken and to redo them. Other than adding /device at the top, we are not obsoleting RFC 7223. This shows a rather diminished understanding of how YANG works. YANG defines data at a specified location /some/path/from/root. Protocols like HTTP can deal with moved resources (e.g., 301). This doesn't make sense. The YANG model is the contract. You are proposing changing the contract. The fact is that you will be obsoleting 7223 (and the other RFCs). Existing devices and applications will have to change in order to handle this new top-level node (which will be in some other namespace I presume, unless your proposal is one gigantic monolithic model). /martin Again I will ask: why is this bad? My point above was in reply to the statement that we are not obsoleting RFC 7223 [because the change is so small?] - you would in fact be obsoleting the model in 7223. There have been other mechanisms discussed to relocate YANG models. Perhaps, one of these could be employed in lieu of obsoleting the existing models. Thanks, Acee This is exactly what I want to get on the table. If we can agree on a mechanism/s to do relocate modules, then this might alleviate the resistance to evolve models. The current issue aside, if you step back and look at the wider IETF situation around all the Yang models being created and are RFCs, and the dependency graph that is created. You can then imagine a time after that point when others come along that evolve parts or entire modules. We currently refer to this as “obsoleting” all of the modules that it depends on, which is a very big problem using the current RFC process. Not only does it require a revision of all those RFCs (due to obsoleting the previous ones) - and thus all the procedural/management overhead that will incur - but the time lag from start to finish. And this might happen for any new module. This is not scaleable going forward. So we would just need to retrofit all the clients and servers with complicated code to relocate YANG modules and adjust all the validation tests? Another approach is to not rely so heavily on one giant uber-tree that MUST be correct on the first try and never change. Resource directories and other flexible approaches have been developed for this purpose. —Tom Andy /martin ___ 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
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Aug 26, 2015:10:51 AM, at 10:51 AM, Kent Watsen kwat...@juniper.net wrote: Another approach is to not rely so heavily on one giant uber-tree that MUST be correct on the first try and never change. I agree that an uber tree stands to make things worse. This seems to be the case the more we think through this. Distinct modules have distinct namespaces and no collisions concerns. But even better than that, distinct modules promote competition. Or simply multiple versions of the same modules at the same time. ODL lets you do this, for example, and happily works. But the other more IETF-related situation is as you say, if there are two draft models for the same features. One could and should be able to run them together, for at least experimental purposes. I have no issues with there existing modules with overlapping concerns, even when implemented simultaneously by the same server. I'm projecting, but it seems that the uber tree approach would put a freeze to such experimentation, which is fine for a specific project to hoist onto itself, but seems inappropriate for a standards organization. Again, I like the idea of relocatable modules, as it seems to allow coexistence of both options. I agree. Tom (as individual). Kent // as a contributor ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
On Aug 19, 2015:10:31 PM, at 10:31 PM, Lou Berger lber...@labn.net wrote: 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 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
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
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 |
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
Hi, Lou Berger lber...@labn.net wrote: On 8/18/2015 8:01 PM, Andy Bierman wrote: 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? I can see two approaches: 1) Define a YANG module with the structural hierarchy. Then other modules augment this module at the correct place in the hierarchy. This module will probably be updated pretty often, especially if the idea to have ONE module with the complete hierarchy for ALL types of devices. A variant is to define such a module for routing-specific modules only to augment. Other areas can define similar structural modules. 2) Document the hierarchy as a guideline. When it is time to work on a new module, lets say mpls, we look into this guideline and define the necessary hierarchy in the mpls module. 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. As long as the device implements standard data models, why does it matter for pre-provisioning if the standard path to configure an interface is /devices/interfaces/interface or /interfaces/interface? 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” But the design you propose has huge impact on all models, also models from other areas. 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? As long as you want to have /device/interfaces, you need to obsolete the model in RFC 7223 (and all other published YANG models) and rewrite them. However, if we get rid of the /device container, the
Re: [netmod] questions about draft-rtgyangdt-rtgwg-device-model-00
[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
