Paola Grosso wrote:

In essence, we have tried to define the basic classes that go into the NML-WG schema, and began to define each class in more detail. We will use this as starting point for tomorrow discussion.

This work was presumably done after the formal meeting? My compliments!!!! You seem to have been doing some real substantial work! I have a few random comments (well, not truly random). slide 2: Why this specific list of NDL basic classes? I personally would not say Service is a basic class, while Layer, AdaptationFunction and AdaptationProperty are. slide 4: Nice. I never imagined paths and domains as similar concepts. Paths are hard. It should be possible to refer to a path other than the explicit ordered sequence of links (i.e. but simply by its name). A path can also be an ordered sequence of other paths! Image a path through a network, another path through another network. Those in series form a new path as well. This is a useful to describe connections through domains without knowing the details. Note that this description of a path equals that of a "tandem connection" in ITU-T G.805 terminology, not of a "network connection" (which is a special form of a tandem connection). Paths as described here can only be used for "horizontal" grouping (on the same layer), as opposed to "vertical" grouping involving multiple layers -- see my comments at slide 7. slide 4: Another term I've seen is technology domain. (which is slightly different from the "Layer" concept, which I like to use). This is arguable distinct from a VLAN domain (while a technology domain is only a group of the same technology, a VLAN domain is a group of the same interface with the same technology AND the same label). -> Please refer to the Stitching Framework ([1] page 6): they have a nice list of definitions for all these things. slide 5: I recommend to distinguish between a device (the physical thing) and its (switching) capabilities. That would allow us to describe the (switching) capabilities of a domain without describing all details of each physical device (which IMHO is a scalability nightmare). I like to list that concept here. slide 6: Are we talking about logical or physical interfaces? I strongly argue for logical interfaces. slide 6: NOT every interface belongs to a node: it may also be useful to describe an interface of a domain, without telling the details of which devices it is connected to. (I'll knowingly skip other problems like the description of a port in a patch panel, which may not be considered a device -- for our purpose it's not relevant, although if you want to use this schema for inventory management, it may be important.) slide 6: I like a certain hierarchy in interfaces classes, from generic to technology specific. However, I think that using the OSI layer at the intermediate step is not a good idea. I prefer a "circuit switched interface" and a "packet switched" interface as intermediate, or no intermediate step. Also, I really oppose the term "Ethernet interface": I think Ethernet deserve two interface subclasses: one for the MAC-sublayer, and a different one for the VLAN-'sublayer'. But I'm willing to compromise, especially if we could have an easy mapping from our 'interfaces' / layers to GMPLS encodings. slide 6: I strongly recommend to put as MUCH information in the generic Interface class as possible, and only rely on subclassing if all else fails. This is important to keep the schema as technology-agnostic as possible. Do we really need to subclass Interfaces? Do we really need to subclass Devices? Do we really need to subclass Links? etc. etc. Perhaps the answer is yes to two of these questions, or perhaps to all three. But I like to remind people that in NDL we did NOT have to subclass ANY of the these! Still, we are able to find paths through nearly all technologies, including fiber, WDM, TDM, and VLANs. The only thing I needed subclasses for are for Ethernet MTU size, and for fiber physical properties (cladding of the fiber: multimode/singlemode, etc.). slide 6: Note that rather than subclassing interfaces, subclassing link, subclassing switch matrices (/devices) all to technology-specific subclasses, I tried to come up with the notion of some sort of mix-in class. E.g. WDMNetworkElement, with a WDMInterface a subclass of both Interface and WDMNetworkElement, and a WDMDevice a subclass of both Device and WDMNetworkElemenet, etc. My experience: while this idea sounded nice, it didn't really work in practice. But again, do we really need all subclasses? slide 7: I have a little preference for a generic type BroadcastSegment, with special case subclass Link. I have no strong preference for unidirectional/bidirectional links, but would suggest to make it easy to somehow group two unidirectional links to a bidirectional links. This is only easy since in the GLIF community, people are used to talking about bidirectional links. slide 7: I am inclined to rant about the hierarchy of links here. I really, really like to see a clear distinction between HORIZONTAL grouping of links: a path as a series of links (G.805 terminology: a tandem connection is a series of link connections and/or subnetwork connections), and VERTICAL grouping of links: a layer /n/ link is a "sum of" adaptations and a layer /n-1/ path. (G.805 terminology: a link connection at a server layer is composed an adaptation source and sink with a netwerk connection on the client layer; where a network connection is a *terminated* tandem connection). The logic between these two groupings is distinct, and I really like us to adopt the G.805 concepts (though I'm fine sticking to the current terminology). -> Please refer to the concept of VERTICAL hierarchies in NDL (using adaptation functions) [2] and refer to the concept of HORIZONTAL hierarchies in cNIS [3]. slide 8: what is a node? Is a device a node? Is a domain a node? If a domain can be a node, the second bullet is not true anymore. slide 9: I would recommend to the working group not to define services for the time being. That concept is part of the control plane, while I think our focus should be on the data plane for now. That said, by all means do include it if there are good counter arguments to do so. The same argument more or less holds for defining Locations: I'm not opposed to defining them (we did in NDL), but I much rather refer to work of other specialized groups, rather than reinventing the wheel here. slide 11: I very much applaud the choice for UML diagrams, with both an RDF and XML schema. The use of UML prevents me from suggesting some Really Neat Features of RDF, but for interoperability it would be a Good Thing if I'm restricted in that sense ;-). That said, I'll gladly battle for the use of opaque URI's as identifiers for all class instances! Regards, Freek [1] http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_T... [2] http://www.science.uva.nl/research/sne/ndl/?c=12-Layer-Schema [3] I got a file cnis_erdv0.14.png, but couldn't find a public reference yet.

Evangelos Chaniotakis wrote:

There is a slight advantage in not placing Interfaces under Domain (which is in my opinion the only other place you could conceivably put an Interface), and that is a stricter hierarchy that might be easier to work with and populate.

Would it be possible to place an Interface both under a device as well as under a domain? I guess we may have to do the same for switching capabilities: that may be "part of" either a device or a domain. (This is one of those Really Neat Features of RDF: those relations are so loose it is really trivial to allow this.) But your last point surely stands: a lot of flexibility makes it harder to work with a model. I think the flexibility is warranted here, but it has drawbacks.

Subclassing is neat on paper, but in practice turns out to be really awkward and difficult to work with. It's usually better to create composite objects, using "has-a" relationships rather than "is-a".

To continue the example above, a WDMDevice would have-a WDMNetworkElement aspect and have-a Device aspect rather than *be* both of those things.

Thank you for phrasing it so clearly! I hadn't thought of it in this way, but it certainly makes sense! (Chapter 1 of my design patterns book indeed says "has-a is better than is-a")

I think that both services and locations are quite useful and will not detract from the main effort as long as we don't try to do anything too fancy. Though in my opinion it would be best if we could reuse other established schemas for these,

That brings us to the natural question: are there already established (or not-so-established-yet) schemas out there? Or should we first establish what we mean with "service"? I think a good use case for services is the ability to point to other information or services required by the control plane. For example, NML may describe a topology, and technology restrictions, but there may be another service that describes (or negotiates) policies, or current reservations/usage. It may useful that these descriptions can refer to each other (though I may argue that only other services need to point to network elements, not the other way around). As for locations -- do we want to describe geographic coordinates (wgs84 = "GPS" coordinates, for network visualization) or organizational location (address, facility, room, rack, location - for inventory management)? Or both? Or are they the same thing? Again, are there established descriptions for this? If not, I would recommend two separate tables: one for wgs84 coordinates, and one for organizational coordinates ("location"), and the ability to say that a location is part of/inside another location. Thus location "rack 23E" and location "rack 45A" could be part of location "room 2.12". A side- advantage is that this would not force a certain hierarchy (one organization may describe "facility NetherLight" as part of "room 2.12", while another organization may describe "room 314" as part of "facility StarLight") Regards, Freek