> On Apr 8, 2016, at 8:22 PM, Alexander Clemm (alex) <[email protected]> wrote: > > Hi Carl, > > to follow up on the earlier points in the discussion: > - How can we provide more clarification > - How could M.3010 provide something useful
What I was going after was if you find we deviate (or lack) concepts or useful features from M.3010 that would make the classification more useful. Hoping you could review the draft with M.3010 goggles on and see if we’re missing something useful! > FWIW, a line of argument to reflect in the draft might go as follows: > > Given that the history in IETF has been to not look at things beyond the > device boundary, perhaps it would be useful to state somewhere that this > restriction no longer holds and needs to be relaxed - given that devices can > be virtualized, controllers may reside on devices, that applications may > become more network-aware and networks more service / application aware, etc. > So, the boundaries are getting more blurry. This to me seems to be a generally useful reflection, but I believe it to be out of scope for this draft. > At the same time, a foundational concept is still the need for function > hierarchies (regardless of details of where and how those functions are > instantiated): elementary functions / building blocks (formerly equivalent to > devices), functions that deal with the connection of those functions / > building blocks (formerly equivalent to "network management" in the narrower > sense), then functions that build higher-level services on top of > connectivity already being provided. Function hierarchies imply information > / data hierachies. There is no reason why YANG could not be used to define > models at different levels of that hierarchy, which provides various > advantages such as consistency across the "model stack" as well as the > ability to make aspects of models at different levels of abstraction > accessible to other models and be used together where layering is not > "strict" (in the sense that upper layers may build on top of models from > multiple lower layers, not just the layer immediately below it, so that lower > layers are not completely hidden). So, YANG models apply to different > layers, and there are advantages in doing so. I’ve tried to cover this topic (or at least one instance of it) in section 2. I’ll re-review with the above in mind. > The concept of model hierarchies is not new. One example of a hierarchical > classification that has proved very useful over the years is the hierarchy > spelled out in M.3010. So, we are not proposing anything "radical" here; > there is precedence. As M.3010 layering concepts are in essence applicable > also here, yet the need for data model hierarchies has not been spelled out > before in the context of the YANG/Netconf framework, this is an attempt to > fill that gap. Exactly! > One reason why classification is useful in that sense is to know which types > of models might have dependencies on each other, and what other models a > model might build on when instantiated. Upper-layer models may have > dependencies on lower-layer models, and in many cases aggregate/abstract > multiple components from those lower layer models, but not the other way > around. This means that, upper-layer models may be instantiated in different > ways than lower-layer models in as far as they build on top of other > functions/models of the same framework (instead of functions outside that > framework). This distinction is one of the reasons why having a clear > classification is something that may be useful. > > Anyway, IMHO, what is currently not sufficiently clear from the draft is that > classification does not occur just for classification's sake, and this is an > attempt at articulating a case for it. I’m trying to strike a balance between providing arguments for why abstractions are useful (which is out of scope for the draft imho) and how to classify YANG modules. Almost to the contrary, the draft mentions that there are currently no specific requirements on, or well-defined best practices around the development of modules inside the boundaries of this classification. As the people and technologies around YANG matures, I believe we will see more granular patterns of use that we may want to capture in future drafts. > Cheers > --- Alex > > > -----Original Message----- > From: Carl Moberg (camoberg) > Sent: Friday, April 08, 2016 9:53 AM > To: Andy Bierman <[email protected]> > Cc: Alexander Clemm (alex) <[email protected]>; [email protected] > Subject: Re: [netmod] YANG model classification? > > >> On Apr 8, 2016, at 3:36 PM, Andy Bierman <[email protected]> wrote: >> >> >> >> On Fri, Apr 8, 2016 at 6:18 AM, Carl Moberg (camoberg) <[email protected]> >> wrote: >> >>> On Apr 8, 2016, at 3:10 PM, Andy Bierman <[email protected]> wrote: >>> >>> Hi, >>> >>> >>> It is not that clear how the different types of modules or layers >>> impact the task of designing a YANG module. It seems like vendor >>> vs. standard or device vs. service are somewhat arbitrary, >>> especially if virtualization is considered. >> >> >> The intent of the classification is (imho) not intended to have much impact >> on how to design a module. Rather to provide a taxonomy to classify models >> when they are done (or being developed). >> >> I don’t see how virtualization would have an impact, any suggestions? >> >> No suggestions other than the hierarchy of controller to device is not >> always static. >> Am I allowed to build a service layer on top of another service layer? >> (e.g, NMS --> EMS --> NE). Am I allowed to treat an entire data >> center as a device in a high level application? >> > > The draft is definitely not supposed to tell you what you are allowed to do, > but it does aspire to a useful classification of what people are doing :-) > > So, to your questions: > > 1. “...a service layer on top of another service layer?" > > From section 2.1: > > “””” > The component-based approach captures device-centric features (e.g. > the definition of a VRF, routing protocols, or packet filtering) in a > vendor-independent manner. The components are designed for reuse across many > services. The set of components required for a specific service is then > composed into the higher-level service. The component-based approach has the > advantages of modular development including a higher degree of reusability at > the expense of initial speed. > “”” > > > 2. “...to treat an entire data center as a device in a high level > application?" > > “”” > Network Element YANG Data Models describe the configuration, state data and > operations of a network device as defined by the vendor of that device. The > models are commonly structured around features of the device... > “”" > >>> The terminology would be more relevant if the differences in content >>> of each type of module were clear. >> >> The first paragraphs of the main sections (2.1, 2.2, 3.1-3.3) are meant(!) >> to explain this. Could you expand on what you think is missing? >> >> No -- this is an Informational draft. >> The content does not have to be actionable. It only has to be >> informative. >> >> For decades SNMP completely ignored anything above the NE as out of scope. >> We are making some progress just by considering the possibility of >> standard functionality at the controller layer. >> >> >>> Andy >> >>> >>> >>> On Fri, Apr 8, 2016 at 5:40 AM, Carl Moberg (camoberg) <[email protected]> >>> wrote: >>> >>>> On Apr 7, 2016, at 6:43 PM, Alexander Clemm (alex) <[email protected]> wrote: >>>> >>>> I am wondering what purpose the classification really serves. At the end >>>> of the day, it seems to me that we are trying to express a model >>>> hierarchy, and articulate what the layers in the hierarchy are. A device >>>> model is thus at a lower layer than a service model. An implementation of >>>> the service model may in turn have dependencies on the device model, but >>>> not the other way round. >>> >>> The abstract tries to express the purpose: >>> >>> “”” >>> A consistent terminology would help with the categorization of >>> models, assist in the analysis the YANG data modeling efforts in the >>> IETF and other organizations, and bring clarity to the YANG-related >>> discussions between the different groups. >>> “”" >>> >>> And I’ve then tried to expand a little further in section 1. >>> >>> Happy to take feedback on it! >>> >>>> Where the models are instantiated - on a controller, on a "device", etc - >>>> seems to be secondary and incidental. The boundaries are blurry, anyways. >>>> A controller is a device too; some devices may contain virtualized >>>> controllers, and so on. >>> >>> The assumption here is that the location is indeed useful and suggests the >>> classification of data models into two distinct abstraction layers. >>> Topology is the area where I had a sense that the device and service >>> classification may both apply to a single module. >>> >>>> One model that is relevant in this discussion seems to be the TMN model, >>>> as defined in ITU-T Recommendation M.3010. This model defines a set of >>>> management layers - network element (device), network, service, business - >>>> with well defined funcional scope of each layer. The layers / function >>>> hierarchy also imply an information and data model hierarchy. >>> >>> The classification is fairly well aligned with the concepts in >>> M.3010, covering the "Network management” and “Element management” >>> layers. At least that’s the intent :-) >>> >>>> Would it make sense to see if the layering in M.3010 could help guide YANG >>>> model classification, and reference those definitions? >>> >>> Would be very happy to hear if you find we deviate (or lack) concepts or >>> useful features from M.3010 that would make the classification more useful. >>> >>>> --- Alex >>>> >>>> -----Original Message----- >>>> From: netmod [mailto:[email protected]] On Behalf Of Carl >>>> Moberg (camoberg) >>>> Sent: Thursday, April 07, 2016 1:57 AM >>>> To: Scharf, Michael (Nokia - DE) <[email protected]> >>>> Cc: [email protected] >>>> Subject: Re: [netmod] YANG model classification? >>>> >>>> >>>> >>>> -- >>>> Carl Moberg >>>> Technology Director, CVG >>>> [email protected] >>>> >>>>> On Apr 7, 2016, at 10:55 AM, Scharf, Michael (Nokia - DE) >>>>> <[email protected]> wrote: >>>>> >>>>>> I come at this from the classification angle, so my interest is >>>>>> if the assumption that a YANG model can only be classified as a >>>>>> network service model XOR a network device model according to >>>>>> the definitions in draft-ietf-netmod-yang-model-classification >>>>>> (sections 2.1 and 2.2). Based on this discussion I take it that some >>>>>> models are intended to be able to serve in both roles. And we should >>>>>> make sure that it’s supported in our catalog structure. >>>>> >>>>> Regarding the XOR assumption for classification: >>>>> >>>>> You may also want to think about YANG models that are NEITHER device NOR >>>>> service models. For instance, what about RFC 6991? And I think other, >>>>> more technical models presented this week may fall into a similar >>>>> category ("generic"?). >>>> >>>> Very good point, thanks! That will need some additional thinking and >>>> writing. >>>> _______________________________________________ >>>> netmod mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
