> 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
