Regarding the schema at http://forge.gridforum.org/sf/go/doc15481 During the last OGF meeting, the following changes have been proposed. - Martin: rename Port/Interface -> Port (Freek: make it clear in the description that this concerns a logical port, not a physical port) - Martin: rename Device/Node -> Node - Guy: rename Network Element -> Network Object (as "network element" has a well established but different meaning in other organisations, namely that what we call Node) - Freek: Port is unidirectional (not bidirectional. This suggestion is based on experience with multicast, and complex adaptation stacks, which were harder to describe using bidirectional Ports. Suggested by Guy) - Freek: Adaptation and Deadaptation are separate classes (to make it unidirectional, just like links) - Martin: Make transport processing functions (Adaptation, Deadaptation and Unidirectional Link) a subclass of Service (see separate email) - Freek: Change the hasPort relation Node-Link to Group-Link and make Node a subclass of Group. This allows a relation between Port and Topology (for describing edge interfaces of a domain, which was not possible with the current schema). - Martin: Add time-based information. Each network object can point to _multiple_ time intervals (with start time and end time). The meaning is that if "the network object is available" during these time interval(s). It was shortly discussed that time intervals can be used for both inventory management as well as reservation data, though it is not yet entirely clear if this can be described with the same type of relation from network object to time interval. Regards, Freek Dijkstra
Hello, We have certainly had a lively discussion again at this OGF, and it is now clear that we do not have consensus regarding the service and adaptation elements. Would it be an idea to leave service and adaptation out of the schema for now and try to make a first standard out of the rest? That is what we originally had in mind for the first deliverable anyway. Jeroen.
Could you describe the different views of service and adaptation? I also thought we had lively conversation but hoped that we would come out with consensus in the long run. Since the meeting I have attempted to lay out some use cases that are of interest to NSI at least, and almost all of them have adaptation as part of the case. This has changed my thinking some, in that it seems to me now adaptations are part of network topology, not just services. In particular, just as nodes and network groups might have ports, they might also have adaptations. The peculiar thing about adaptations as opposed to other services (it seems to me) is that they are required to stitch together a connection consisting of segments from different services. My preference for this would be to try to work it out before dropping it. It seems important to have it - at least adaptations - for defining network topology that can be used to create ete circuits. John On Jun 3, 2009, at 5:21 AM, Jeroen van der Ham wrote:
Hello,
We have certainly had a lively discussion again at this OGF, and it is now clear that we do not have consensus regarding the service and adaptation elements. Would it be an idea to leave service and adaptation out of the schema for now and try to make a first standard out of the rest? That is what we originally had in mind for the first deliverable anyway.
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
John Vollbrecht wrote:
My preference for this would be to try to work it out before dropping it. It seems important to have it - at least adaptations - for defining network topology that can be used to create ete circuits.
To be clear: I'm not advocating that we drop this entirely. I merely want to speed up the process for the first schema. As far as I can remember, we have reached consensus on the single layer schema at OGF23 in Barcelona and the Berlin meeting after that. It really is time that we write this up into a draft standard. Adaptations are not required for the single layer schema, but it seems very likely that some form of adaptation will be present in the multi-layer schema. Jeroen.
Jeroen & All;
John Vollbrecht wrote:
My preference for this would be to try to work it out before dropping it. It seems important to have it - at least adaptations - for defining network topology that can be used to create ete circuits.
To be clear: I'm not advocating that we drop this entirely. I merely want to speed up the process for the first schema. As far as I can remember, we have reached consensus on the single layer schema at OGF23 in Barcelona and the Berlin meeting after that. It really is time that we write this up into a draft standard.
Adaptations are not required for the single layer schema, but it seems very likely that some form of adaptation will be present in the multi-layer schema.
I understand the desire to produce a document quickly, but I agree with John that we must work out the differences before proceeding. Note that several groups (including DCN and perfSONAR) will be examining the schema and deciding if immediate adoption is in their best interest. It would not be good to leave out any functionality if we expect outside parties to embrace the standard. -jason
Jason Zurawski wrote:
It would not be good to leave out any functionality if we expect outside parties to embrace the standard.
Sorry to sound like a broken record, but multi-layer topology descriptions were never the aim of the first schema document. And we have in our charter that we will provide that schema as a deliverable, with a followup multi-layer schema deliverable. I'm not completely sure about the formal process of rechartering, but that's what we'd have to do then. I'm fine either way, but the goal should be clear. And as the editor of the first schema document, I'd very much like to be certain what should and shouldn't be in the document.... Jeroen.
I am not sure about the order of things in the group. It may be good to do a single layer schema first and standardize it so there is a stake in the ground. However, NSI needs to have adaptations in topology to support its architecture and eventually its protocol definitions. NSI and NML need to be in sync on network model and terminology. If the single layer schema is done first, then I think it is important to have a clear timeline for when the multi-layer will be available. John On Jun 3, 2009, at 11:46 AM, Jeroen van der Ham wrote:
Jason Zurawski wrote:
It would not be good to leave out any functionality if we expect outside parties to embrace the standard.
Sorry to sound like a broken record, but multi-layer topology descriptions were never the aim of the first schema document.
And we have in our charter that we will provide that schema as a deliverable, with a followup multi-layer schema deliverable. I'm not completely sure about the formal process of rechartering, but that's what we'd have to do then.
I'm fine either way, but the goal should be clear. And as the editor of the first schema document, I'd very much like to be certain what should and shouldn't be in the document....
Jeroen. _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
IMHO, I don't have a problem with meeting the requirements of the charter and standardizing a single layer schema. As John pointed out, the NSI is highly dependent on the NML to develop a schema that will work for us. As it stands right now, the adaptation functions will be an extension to the single layer schema which I'm perfectly fine with. It would be a big concern if adding the adaptation will cause a complete rework of the schema, which would result in the depreciation of the single layer schema, and void the implementation by some early adopters of the schema (i.e. IDC). - Chin --On June 3, 2009 1:06:03 PM -0400 John Vollbrecht <jrv@internet2.edu> wrote:
I am not sure about the order of things in the group. It may be good to do a single layer schema first and standardize it so there is a stake in the ground. However, NSI needs to have adaptations in topology to support its architecture and eventually its protocol definitions. NSI and NML need to be in sync on network model and terminology. If the single layer schema is done first, then I think it is important to have a clear timeline for when the multi-layer will be available.
John
On Jun 3, 2009, at 11:46 AM, Jeroen van der Ham wrote:
Jason Zurawski wrote:
It would not be good to leave out any functionality if we expect outside parties to embrace the standard.
Sorry to sound like a broken record, but multi-layer topology descriptions were never the aim of the first schema document.
And we have in our charter that we will provide that schema as a deliverable, with a followup multi-layer schema deliverable. I'm not completely sure about the formal process of rechartering, but that's what we'd have to do then.
I'm fine either way, but the goal should be clear. And as the editor of the first schema document, I'd very much like to be certain what should and shouldn't be in the document....
Jeroen. _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
Jeroen, All,
Sorry to sound like a broken record, but multi-layer topology descriptions were never the aim of the first schema document.
I'm not sure that I agree with this.
And we have in our charter that we will provide that schema as a deliverable, with a followup multi-layer schema deliverable. I'm not completely sure about the formal process of rechartering, but that's what we'd have to do then.
My read of the charter is that the "base" schema doesn't have specific parameters for e.g. SONET, Ethernet, etc and that those are to be defined later. But I think that the "base" schema should have the scaffolding to relate various layers. I don't think that is goes against the charter in word or intent. I also think it makes it more valuable. best, martin
Jeroen wrote:
Sorry to sound like a broken record, but multi-layer topology descriptions were never the aim of the first schema document.
Martin wrote:
My read of the charter is that the "base" schema doesn't have specific parameters for e.g. SONET, Ethernet, etc and that those are to be defined later. But I think that the "base" schema should have the scaffolding to relate various layers. I don't think that is goes against the charter in word or intent. I also think it makes it more valuable.
Hi Martin, others, I do follow Jeroen's reading of the charter (which can be found at http://www.ogf.org/gf/group_info/charter.php?review&group=nml-wg). To quote (emphasis is mine):
D2. A recommendation document describing a normative schema which allow the description of a basic network topology. THIS SCHEMA DOES NOT INCLUDE ANY LAYER OR TECHNOLOGY SPECIFIC INFORMATION.
D3. A recommendation document describing a normative schema which, along with the schema in deliverable 2, can be used to describe a multi-layer network.
However, after some discussions with Martin, I now think that it can be read in both ways. So I would like to ask the working group for input. A) Should deliverable 2 contain the full abstract schema, including adaptations, and deliverable 3 the application of the schema to actual technologies? or B) Should deliverable 2 only contain the single layer schema, and deliverable 3 both the multilayer schema extension (e.g. adaptation) as well as application of the schema to actual technologies? To me, the advantage of (B) is that we can proceed quicker with deliverable 2, but the disadvantage is that we may have to make changes to the base schema based on later discussions. The advantage of (A) is that such risk -as eloquently described by Chin- is eliminated (or at least a lot less likely). Regards, Freek Dijkstra
Hi All,
A) Should deliverable 2 contain the full abstract schema, including adaptations, and deliverable 3 the application of the schema to actual technologies?
I vote A. Just to reiterate, I think that we can construct the base schema without layer or technology specific information, but provide the basic building blocks for relating elements and describing the services they provide. I also don't think that it is that difficult so I don't think it will set us back time-wise. best, martin
I also vote A. If we don't put the right 'building blocks' in from the beginning, I think we are in danger of not having the seamless upgrade path Chin mentioned. So it is important to me that we get the model for how different layers/technologies relate to each other. But, of course we are not defining those layers. jeff On Jun 3, 2009, at 6:18 PM, Martin Swany wrote:
Hi All,
A) Should deliverable 2 contain the full abstract schema, including adaptations, and deliverable 3 the application of the schema to actual technologies?
I vote A. Just to reiterate, I think that we can construct the base schema without layer or technology specific information, but provide the basic building blocks for relating elements and describing the services they provide. I also don't think that it is that difficult so I don't think it will set us back time-wise.
best, martin _______________________________________________ nml-wg mailing list nml-wg@ogf.org http://www.ogf.org/mailman/listinfo/nml-wg
I vote blank. I'm fine either way, as long as it is clear to everyone what we are doing. However, I do have one remark below regarding option A. Jeff W.Boote wrote:
If we don't put the right 'building blocks' in from the beginning, I think we are in danger of not having the seamless upgrade path Chin mentioned. So it is important to me that we get the model for how different layers/technologies relate to each other. But, of course we are not defining those layers.
As far as I've seen from the models that were presented at the NML meetings, the way you describe adaptation/services very much determines the way you describe layers.Once you have defined adaptations, then the definition of layers should follow naturally. To follow the 'building blocks' analogy: once you have determined the form of the blocks, then defining layers is just putting them together in the right way. And the form of the blocks very much determines how you are going to do that. Jeroen.
Jeroen,
As far as I've seen from the models that were presented at the NML meetings, the way you describe adaptation/services very much determines the way you describe layers.Once you have defined adaptations, then the definition of layers should follow naturally.
To follow the 'building blocks' analogy: once you have determined the form of the blocks, then defining layers is just putting them together in the right way. And the form of the blocks very much determines how you are going to do that.
I very much agree with this and I think that it underlies part of our differing views on the delineation between deliverables 2 and 3. UNIS was always multi-layer and we took advantage of the namespacing technique from the NM-WG measurement stuff to accomplish that. I think that's why I see the support for the multi-layering as being present in the base, with the details of the layers themselves being in deliverable 3. martin
Martin, Martin Swany wrote:
UNIS was always multi-layer and we took advantage of the namespacing technique from the NM-WG measurement stuff to accomplish that. I think that's why I see the support for the multi-layering as being present in the base, with the details of the layers themselves being in deliverable 3.
Alright, I think most of the group is in favor of including adaptation and/or service in the base schema. Could you write a proposal for this perhaps including a new version of the schema diagram? I would like to understand your proposal better. Jeroen.
On Jun 3, 2009, at 5:18 PM, Martin Swany wrote:
Hi All,
A) Should deliverable 2 contain the full abstract schema, including adaptations, and deliverable 3 the application of the schema to actual technologies?
I vote A. Just to reiterate, I think that we can construct the base schema without layer or technology specific information, but provide the basic building blocks for relating elements and describing the services they provide. I also don't think that it is that difficult so I don't think it will set us back time-wise.
I agree with Martin.
Freek Dijkstra wrote:
- Freek: Change the hasPort relation Node-Link to Group-Link and make Node a subclass of Group. This allows a relation between Port and Topology (for describing edge interfaces of a domain, which was not possible with the current schema).
I assume you mean Node-Port and Group-Port there? Why are you proposing to make Node a subclass of Group? I don't really see any practical reason for it, other than that it makes it esthetically more pleasing in the UML diagram, by having only one hasPort relationship. I do agree that it makes sense for Groups to have a hasPort relation so that we can describe aggregated topologies. Jeroen.
- Freek: Change the hasPort relation Node-Link to Group-Link and make Node a subclass of Group. This allows a relation between Port and Topology (for describing edge interfaces of a domain, which was not possible with the current schema).
Jeroen van der Ham replied:
I assume you mean Node-Port and Group-Port there?
Yes, you are absolute right. Thanks for spotting this.
Why are you proposing to make Node a subclass of Group? I don't really see any practical reason for it, other than that it makes it esthetically more pleasing in the UML diagram, by having only one hasPort relationship.
I actually did not think of defining two hasPort relations. I have no strong preference either way, though defining it once seems more "clear" to me. It would be odd that in that case it would also apply to other groups, like Bidirectional link. Perhaps we should distinguish between group of ports (like node and topology) and group of transport elements (such as two unidirectional links that make up a birectional link). Just a thought (I'm not yet in favour of doing so, as it makes the schema more complex, and don't see a clear benefit yet). Regards, Freek
Hello Freek, Was not at the meeting, but we plan to read very soon the document John V. sent (viewing from Stitching framework). And if necessary provide feedback. Freek Dijkstra wrote:
- Freek: Port is unidirectional (not bidirectional. This suggestion is based on experience with multicast, and complex adaptation stacks, which were harder to describe using bidirectional Ports. Suggested by Guy)
Fully support that.
- Martin: Add time-based information. Each network object can point to _multiple_ time intervals (with start time and end time). The meaning is that if "the network object is available" during these time interval(s). It was shortly discussed that time intervals can be used for both inventory management as well as reservation data, though it is not yet entirely clear if this can be described with the same type of relation from network object to time interval.
Can understand this point. And it has some relation with the points I have (due to work in the Stitching Framework: http://www.geant2.net/upload/pdf/GN2-07-066v5-DJ3-5-3-Report_on_Testing_of_T... ). The below points have perhaps a lower level relation with the present work status in NML, but I still want to mention it. The Stitching framework will be able to work with any definition language (like XML) as long as it has the concept that an object not only has properties like Name (e.g. 'Speed of interface') and Value (like "1 Gbit/s or 10 Gbit/s"), but that other semantic related properties can be attached to an object (like "What can adjust the Value?": For intance what can change the speed of an interface"; e.g. human, ethernet protocol, etc.). In the stitching framework the Name of an object (which is also a property) does not have to be defined by the way. This make the framework open to new technologies (where standards are not yet set;in case of research/testing). The framework just looks for objects that have the same name in Peering domains and then using the other semantic properties determines if they can be stitched/connected and how. That aspect of additional semantic properties is the most important part of the Stitching Framework and should be part of the semantics of a description language. This part is quite often missed the semantics in a network description languages, correct? In the Stitching Framework has a few semantic properties for an object defined (section 2.3: who can change it, what are dependencies on other instantiations of objects, how a value changes in a domain, etc.). But in the future objects might need other properties, so flexibility is important. Beside this concept of semantic properties for an object; the concept of abstraction is essential. So there should be a way how to abstract the intricate insides of a network into something that people want to export to others. Abstracting is important if one wants to allow people to hide certain things. This is analogous to for instance the reason of the existence of BGP. Abstracting can be done outside the semantics of a description language or the Stitching Framework of course. I don't know if the above helps, but the most important attributes of the languages are for me (related to your work) are: . there are semantic related properties . and the name of object does have to be known (allowing for extendibility and non-standard situations; like research/testing). All the best, Victor -- Victor Reijs, Network Development Manager HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/
participants (10)
-
Chin Guok -
Evangelos Chaniotakis -
Freek Dijkstra -
Freek Dijkstra -
Jason Zurawski -
Jeff W.Boote -
Jeroen van der Ham -
John Vollbrecht -
Martin Swany -
Victor Reijs