Example topology of Automated GOLE
Hi, Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI. It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain. Some terms used in the topology: NSA: Network Service Agent, program that does the provisioning NSNetwork: The Network that the NSA manages. STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator. Connectivity is only defined between networks, internally full connectivity is assumed. Jeroen.
W dniu 2012-02-09 17:42, Jeroen van der Ham pisze:
Hi,
Hi Jeroen if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent? Cheers, Roman
Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI.
It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain.
Some terms used in the topology: NSA: Network Service Agent, program that does the provisioning NSNetwork: The Network that the NSA manages. STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator.
Connectivity is only defined between networks, internally full connectivity is assumed.
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi, On 13 Feb 2012, at 16:32, Roman Łapacz wrote:
if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent?
The Automated GOLE demo uses a similar editor available for the NML editor. The Automated GOLE editor is available at: http://auto-gole.appspot.com (The NML editor is available at http://nml-editor.appspot.com) Jeroen.
Hi Roman and everyone- The topology that Jeroen distributed was the topo used last fall for our NSI demos. And we did use the UvA SNE editor to initially create that topology. And that version of the topo should still be compatible with SNE. But the graphical representation created by SNE is not automatic - it is manually created by the individual building the topology... Attached is the diagram we used for public consumption last fall. A more useful approach (IMO) to learn NSI or to understand the AutoGOLE fabric than the SNE graphical display of this topology would be to look at any one NSI Network - say Netherlight.ets - in the diagram, and study its components in the OWL topology file to learn those relations to NSAs, STPs, location info, etc. Once you understand the set of topological relations to one particular network, the other networks in the overall topology are simply repeated themes. This high level top down approach to understanding the topology is much more effective than the SNE graphics IMO. Indeed, I had to manually edit the SNE graphical layout (manually computing the coordinates of each object) in order to get a meaningful graphical display from the topology. The SNE editor is a very basic tool. And certain necessary topological relations cause graphical diagrams to get complex and busy very quickly. So, the prospect of graphically editing any but the simplest topologies requires a rather inteligent editing tool that understands and uses the network semantics - not just RDF relations - to develop the graphical representation and manipulation interactions. As the topology continues to get more complex it has become unwieldy to use the SNE editor in its current form to work on it. So the topo releases we are moving to this spring are not built using SNE. The rest of the OWL topology representation is the same, and I am pretty sure SNE can still be used to process it, but these other semantic/graphical issues make the SNE tool less useful than it might be for building more complex network topologies. NOTE: SNE is the only tool I know that understand the OWL data format and so I believe it might be more useful for representing RDF semantic relations rather than building network topologies per se...so don't take this critique of SNE as a swipe at it...we just need a tool more aimed at network service architectures than semantic web applications. I always think of CASE/CAE tools, or an object oriented approach, as a potentially more effective GUI model. We *do* need some sort of graphical editor for managing large scale topological information, but we need some editing features that are not currently available in SNE (or any other similar topology tool AFAIK). These would include graphical sumarization and layering (not just hardware, but service layering, control plane layers, etc.), auto-routing/placement that "makes sense" within the semantic context of the objects and that minimizes visual clutter, color coding would be useful, groupings and graphical object editing ala Powerpoint or the like, etc. These are largely human-interface/presentation issues, some graphical bugs resolved, etc., but nevertheless these features are why we want graphical editors for this task, and these would make graphical management of topologies much more intuitive and efficient - and thus used. I would suggest that if you are starting out to create a basic topology from scratch, the SNE editor is very good place to begin. It works fine for a basic not-too-complex topology and generates an OWL file with all the headers required for this data representation form. You can learn a fair bit about NSI by building some simple topologies using SNE. And then you can study the resulting OWL output and extend the topology using SNE or other conventional editing tools or auto-generating scripts to generate larger more complex OWL based topologies. And I think you can still feed those auto-generated topologies into SNE for a rough validation. (There may be other ways to validate an OWL topology file I am not aware of...Jeroen? Any thoughts on this?) Just some observations... Jerry On 2/13/12 12:21 PM, Jeroen van der Ham wrote:
Hi,
On 13 Feb 2012, at 16:32, Roman Łapacz wrote:
if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent?
The Automated GOLE demo uses a similar editor available for the NML editor. The Automated GOLE editor is available at: http://auto-gole.appspot.com
(The NML editor is available at http://nml-editor.appspot.com)
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Thanks Jerry. When I took a look at the example Jeroen sent I thought that it would be difficult to analyse it. Too much information, especially for me who was not involved in the NSI discussion. That is why I asked for a tool to see the whole picture in a simple way. But today I analysed the PIONIER part in that file and I think I understand (other sections only repeat constructions with content relevant to other domains). Cheers, Roman W dniu 2012-02-14 14:35, Jerry Sobieski pisze:
Hi Roman and everyone-
The topology that Jeroen distributed was the topo used last fall for our NSI demos. And we did use the UvA SNE editor to initially create that topology. And that version of the topo should still be compatible with SNE.
But the graphical representation created by SNE is not automatic - it is manually created by the individual building the topology... Attached is the diagram we used for public consumption last fall. A more useful approach (IMO) to learn NSI or to understand the AutoGOLE fabric than the SNE graphical display of this topology would be to look at any one NSI Network - say Netherlight.ets - in the diagram, and study its components in the OWL topology file to learn those relations to NSAs, STPs, location info, etc. Once you understand the set of topological relations to one particular network, the other networks in the overall topology are simply repeated themes. This high level top down approach to understanding the topology is much more effective than the SNE graphics IMO. Indeed, I had to manually edit the SNE graphical layout (manually computing the coordinates of each object) in order to get a meaningful graphical display from the topology. The SNE editor is a very basic tool. And certain necessary topological relations cause graphical diagrams to get complex and busy very quickly. So, the prospect of graphically editing any but the simplest topologies requires a rather inteligent editing tool that understands and uses the network semantics - not just RDF relations - to develop the graphical representation and manipulation interactions.
As the topology continues to get more complex it has become unwieldy to use the SNE editor in its current form to work on it. So the topo releases we are moving to this spring are not built using SNE. The rest of the OWL topology representation is the same, and I am pretty sure SNE can still be used to process it, but these other semantic/graphical issues make the SNE tool less useful than it might be for building more complex network topologies. NOTE: SNE is the only tool I know that understand the OWL data format and so I believe it might be more useful for representing RDF semantic relations rather than building network topologies per se...so don't take this critique of SNE as a swipe at it...we just need a tool more aimed at network service architectures than semantic web applications. I always think of CASE/CAE tools, or an object oriented approach, as a potentially more effective GUI model.
We *do* need some sort of graphical editor for managing large scale topological information, but we need some editing features that are not currently available in SNE (or any other similar topology tool AFAIK). These would include graphical sumarization and layering (not just hardware, but service layering, control plane layers, etc.), auto-routing/placement that "makes sense" within the semantic context of the objects and that minimizes visual clutter, color coding would be useful, groupings and graphical object editing ala Powerpoint or the like, etc. These are largely human-interface/presentation issues, some graphical bugs resolved, etc., but nevertheless these features are why we want graphical editors for this task, and these would make graphical management of topologies much more intuitive and efficient - and thus used.
I would suggest that if you are starting out to create a basic topology from scratch, the SNE editor is very good place to begin. It works fine for a basic not-too-complex topology and generates an OWL file with all the headers required for this data representation form. You can learn a fair bit about NSI by building some simple topologies using SNE. And then you can study the resulting OWL output and extend the topology using SNE or other conventional editing tools or auto-generating scripts to generate larger more complex OWL based topologies. And I think you can still feed those auto-generated topologies into SNE for a rough validation. (There may be other ways to validate an OWL topology file I am not aware of...Jeroen? Any thoughts on this?)
Just some observations... Jerry
On 2/13/12 12:21 PM, Jeroen van der Ham wrote:
Hi,
On 13 Feb 2012, at 16:32, Roman Łapacz wrote:
if I'm not wrong the NSI group uses some tool to generate diagrams from such topology files. Is it possible to get a diagram based on the example file you sent? The Automated GOLE demo uses a similar editor available for the NML editor. The Automated GOLE editor is available at:http://auto-gole.appspot.com
(The NML editor is available athttp://nml-editor.appspot.com)
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi, I'm sending you my first try of mapping owl topology desc into nml. Please, treat this as a start point for further discussion in order to get the final proposal for the NSI team. Few comments: - I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network. - I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions. An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work. Cheers, Roman W dniu 2012-02-09 17:42, Jeroen van der Ham pisze:
Hi,
Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI.
It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain.
Some terms used in the topology: NSA: Network Service Agent, program that does the provisioning NSNetwork: The Network that the NSA manages. STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator.
Connectivity is only defined between networks, internally full connectivity is assumed.
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
forgive me my mistakes with </nml-nsi: ....> . It should be of course <nml-nsi: .... /> Roman W dniu 2012-02-14 14:30, Roman Łapacz pisze:
Hi,
I'm sending you my first try of mapping owl topology desc into nml. Please, treat this as a start point for further discussion in order to get the final proposal for the NSI team.
Few comments: - I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network. - I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions.
An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work.
Cheers, Roman
W dniu 2012-02-09 17:42, Jeroen van der Ham pisze:
Hi,
Attached is the topology that has been used for the Automated GOLE demonstration the last few months. This is really loosely based on NML, and adds some concepts which are needed for NSI.
It is the whole topology of the demo, consisting of multiple domains. This is because we don't have a good distribution method yet. It should all be separate for each domain.
Some terms used in the topology: NSA: Network Service Agent, program that does the provisioning NSNetwork: The Network that the NSA manages. STP: Service Termination Point, the point to which the service is provided. These are typically mapped locally to actual network endpoints. In this demonstration a suffix is used, in this case it maps to a specific VLAN. How that is actually implemented is up to the operator.
Connectivity is only defined between networks, internally full connectivity is assumed.
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi, On 14 Feb 2012, at 14:30, Roman Łapacz wrote:
- I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network.
Seems sensible to me.
- I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions.
I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work.
I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine. On to the comments for your description: - You're using <nml:relation type="next"> to describe connections, this should be <nml:relation type="connectedTo">. - We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema. Jeroen.
W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
Hi,
On 14 Feb 2012, at 14:30, Roman Łapacz wrote:
- I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network. Seems sensible to me.
- I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions. I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work. I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">.
I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
I'll try to find something. Any suggestions are welcome. Roman
Jeroen.
On 15 Feb 2012, at 12:31, Roman Łapacz wrote:
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">.
I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
I'll try to find something. Any suggestions are welcome.
There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think. There's also the vCard standard, for which there is (I think) both an RDF and XML notation. Jeroen.
W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
On 15 Feb 2012, at 12:31, Roman Łapacz wrote:
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">. I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine. We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.
Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the nml-nsi namespace would be STP). "connectedTo" would work, no doubt, but the question is: should we use this if we already used "next" in circuit monitoring (and both mean the same).
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema. I'll try to find something. Any suggestions are welcome. There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think. There's also the vCard standard, for which there is (I think) both an RDF and XML notation.
yes, vCard was my first candidate as well http://tools.ietf.org/html/rfc6351 Roman
Jeroen.
I am very nervous about this - we deliberatly did *NOT* use "port" in NSI because of the overloaded connotation. The Service Termination Point in NSI is *not* a port. ...not in the physical sense. So we need to understand what a NML "port" represents. Was there an example for this? Thanks! Jerry On 2/15/12 7:41 AM, Roman Łapacz wrote:
W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
On 15 Feb 2012, at 12:31, Roman Łapacz wrote:
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">. I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine. We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.
Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the nml-nsi namespace would be STP). "connectedTo" would work, no doubt, but the question is: should we use this if we already used "next" in circuit monitoring (and both mean the same).
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema. I'll try to find something. Any suggestions are welcome. There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think. There's also the vCard standard, for which there is (I think) both an RDF and XML notation.
yes, vCard was my first candidate as well http://tools.ietf.org/html/rfc6351
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
W dniu 2012-02-15 14:12, Jerry Sobieski pisze:
I am very nervous about this - we deliberatly did *NOT* use "port" in NSI because of the overloaded connotation. The Service Termination Point in NSI is *not* a port. ...not in the physical sense. So we need to understand what a NML "port" represents.
port in the nml-nsi namespace is not physical. This is an abstraction and represents STP. We could introduce new element nml-nsi:stp but is it really necessary? Roman
Was there an example for this?
Thanks! Jerry
On 2/15/12 7:41 AM, Roman Łapacz wrote:
W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
On 15 Feb 2012, at 12:31, Roman Łapacz wrote:
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">. I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine. We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.
Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the nml-nsi namespace would be STP). "connectedTo" would work, no doubt, but the question is: should we use this if we already used "next" in circuit monitoring (and both mean the same).
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema. I'll try to find something. Any suggestions are welcome. There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think. There's also the vCard standard, for which there is (I think) both an RDF and XML notation.
yes, vCard was my first candidate as well http://tools.ietf.org/html/rfc6351
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On 2/15/12 8:24 AM, Roman Łapacz wrote:
W dniu 2012-02-15 14:12, Jerry Sobieski pisze:
I am very nervous about this - we deliberatly did *NOT* use "port" in NSI because of the overloaded connotation. The Service Termination Point in NSI is *not* a port. ...not in the physical sense. So we need to understand what a NML "port" represents.
port in the nml-nsi namespace is not physical. This is an abstraction and represents STP. We could introduce new element nml-nsi:stp but is it really necessary?
Ah, ok...the abstraction is good. (Thanks both Roman and Freek in explaining this.) This was much of my concern. But lets discuss tomorrow in more detail as there are still some other aspects of NML "ports" we need to understand/reconcile. Some further background on NSI notions: In NSI, the STP is indeed an interface at the edge of a network service domain - it identifies uniquely where user data enters or exits a service domain. The STPs associated with a network service define the boundary of that NSI service domain. STPs "mapTo" an internally defined tuple that represents the internal specifics associated with that Service Termination Point. For instance, an STP "NorthernLight:ams-80" would mapTo <switch, mx80-CPH>, <blade, 0>, <port, 2>, <vlan, 1780>. This entire tuple is the internal topological information represented by that STP. (Note- the internal tuple specification is a local network internal issue relevant to the specific infrastructure or software being used.) Inter-domain peering between two networks is expressed via a Service Demarcation Point "SDP". An SDP pairs two corresponding STPs - one in each network. SDPs indicate adjacencies between NSI network services, and differentiate the paths that exist between two networks (or that originate or terminate at a network.) SDPs are *not* physical links (circuits, fibers, etc) between networks - SDPs are /relations/ that identify a common topological interface between two domains - i.e. the two STPs that are part of an SDP represent the *same* topological location - albeit from different name spaces and with different internal mapsTo info. For example, an SDP might look like this: < NorthernLight:ams-80, NetherLight:cph-80 > In the OWL topology, this SDP would be expressed as NorthernLight:ams-80 "connectsTo" NetherLight:cph-80. Thus it is found in an NorthernLight:ams-80 STP object. A similar SDP would be defined in the NetherLight domain. These STP names are just strings, but they "mapTo" the internal physical details of the terminus, and they "connectTo" the corresponding STP in another network. (Note: NSI is developing an "enumeration" construct that will allow a compact SDP representation of large groups of peering STPs...e.g. where two networks terminate a physical link that carries large number of VLAN IDs. perhaps we can discuss this too at the NML call thursday.?) If an STP does not have a corresponding STP in another NSI network - for example where the remote side is an end host that does not participate in NSI - there is just no "connectsTo" relation, i.e no SDP. In our AutoGOLE topology, these are how we represent the perfSonar nodes. Note that these STPs and SDPs are expressly technology agnostic. The physical details are held internally to each network NSA in the "mapsTo" relation and the internal topology DB. I think what we nee to now do with NML and NSI is that we want to express these NSI topological constructs and the NML constructs using a common form (the NML representation is what we currently believe to be the right approach), without breaking the semantics that NSI requires to remain secure and autonomous. At the same time, we want to enable a network announce much more topology if they wish - We'd like both of these aspects to be a well integrated common representational model that syntactically functions smoothly together. Thus a NSA would announce the NSI service domain (presumably using an NML representation), and if they wish, they can include more details of internal structure using further - perhaps more technology specific - NML constructs. Ideally, all of this announcement would be a common structure syntactically, and hopefully semantically as well. This would simplify implementations - partcularly in furture virtual worlds... But we *must* maintain the NSI topological model of STPs and SDPs and Networks and NSAs etc (though we might elect to rename them within the NML context) So I think our task is to figure out how to dovetail these NSI semantics and the NML semantics so that processes can traverse between the two smoothly and hopefully imperceptibly. I look forward to the discussion tomorrow! Jerry
W dniu 2012-02-15 15:56, Jerry Sobieski pisze:
On 2/15/12 8:24 AM, Roman Łapacz wrote:
W dniu 2012-02-15 14:12, Jerry Sobieski pisze:
I am very nervous about this - we deliberatly did *NOT* use "port" in NSI because of the overloaded connotation. The Service Termination Point in NSI is *not* a port. ...not in the physical sense. So we need to understand what a NML "port" represents.
port in the nml-nsi namespace is not physical. This is an abstraction and represents STP. We could introduce new element nml-nsi:stp but is it really necessary?
Ah, ok...the abstraction is good. (Thanks both Roman and Freek in explaining this.) This was much of my concern. But lets discuss tomorrow in more detail as there are still some other aspects of NML "ports" we need to understand/reconcile.
Some further background on NSI notions:
In NSI, the STP is indeed an interface at the edge of a network service domain - it identifies uniquely where user data enters or exits a service domain. The STPs associated with a network service define the boundary of that NSI service domain. STPs "mapTo" an internally defined tuple that represents the internal specifics associated with that Service Termination Point. For instance, an STP "NorthernLight:ams-80" would mapTo <switch, mx80-CPH>, <blade, 0>, <port, 2>, <vlan, 1780>. This entire tuple is the internal topological information represented by that STP. (Note- the internal tuple specification is a local network internal issue relevant to the specific infrastructure or software being used.)
Inter-domain peering between two networks is expressed via a Service Demarcation Point "SDP". An SDP pairs two corresponding STPs - one in each network. SDPs indicate adjacencies between NSI network services, and differentiate the paths that exist between two networks (or that originate or terminate at a network.) SDPs are *not* physical links (circuits, fibers, etc) between networks - SDPs are /relations/ that identify a common topological interface between two domains - i.e. the two STPs that are part of an SDP represent the *same* topological location - albeit from different name spaces and with different internal mapsTo info. For example, an SDP might look like this: < NorthernLight:ams-80, NetherLight:cph-80 > In the OWL topology, this SDP would be expressed as NorthernLight:ams-80 "connectsTo" NetherLight:cph-80. Thus it is found in an NorthernLight:ams-80 STP object. A similar SDP would be defined in the NetherLight domain. These STP names are just strings, but they "mapTo" the internal physical details of the terminus, and they "connectTo" the corresponding STP in another network. (Note: NSI is developing an "enumeration" construct that will allow a compact SDP representation of large groups of peering STPs...e.g. where two networks terminate a physical link that carries large number of VLAN IDs. perhaps we can discuss this too at the NML call thursday.?)
I was thinking about this grouping. To better understand the problem I've created an example presenting simple solution. I wasn't involved in the NSI discussion on this so that piece of xml may be far away from that what you want. But your comments let me see your ideas of solving this. Cheers, Roman
If an STP does not have a corresponding STP in another NSI network - for example where the remote side is an end host that does not participate in NSI - there is just no "connectsTo" relation, i.e no SDP. In our AutoGOLE topology, these are how we represent the perfSonar nodes.
Note that these STPs and SDPs are expressly technology agnostic. The physical details are held internally to each network NSA in the "mapsTo" relation and the internal topology DB. I think what we nee to now do with NML and NSI is that we want to express these NSI topological constructs and the NML constructs using a common form (the NML representation is what we currently believe to be the right approach), without breaking the semantics that NSI requires to remain secure and autonomous. At the same time, we want to enable a network announce much more topology if they wish - We'd like both of these aspects to be a well integrated common representational model that syntactically functions smoothly together. Thus a NSA would announce the NSI service domain (presumably using an NML representation), and if they wish, they can include more details of internal structure using further - perhaps more technology specific - NML constructs. Ideally, all of this announcement would be a common structure syntactically, and hopefully semantically as well. This would simplify implementations - partcularly in furture virtual worlds... But we *must* maintain the NSI topological model of STPs and SDPs and Networks and NSAs etc (though we might elect to rename them within the NML context) So I think our task is to figure out how to dovetail these NSI semantics and the NML semantics so that processes can traverse between the two smoothly and hopefully imperceptibly.
I look forward to the discussion tomorrow! Jerry
Jerry Sobieski wrote:
I am very nervous about this - we deliberatly did *NOT* use "port" in NSI because of the overloaded connotation. The Service Termination Point in NSI is *not* a port. ...not in the physical sense. So we need to understand what a NML "port" represents.
Indeed the term "Port" is overloaded, but so are (unfortunately) other terms. We had multiple (very long) discussion on the exact term to use, and we closed the discussion by reaching working group consensus onn "Port". An NML "port" is equivalent to a G.800 "Forwarding Point" (or G.805 "Connection Point"). I usually refer to it as a "logical interface", to clearly distinguish it from a "physical interface". G.805 defines it as 'A "reference point" that consists of a pair of co-located "unidirectional connection points" and therefore represents the binding of two paired bidirectional "connections".' You will note from this definition that in G.800, two "Ports" connected together form a "Point", I think this is similar to a NSI STP and SDP.
From discussion we had with people involved in the ITU, most people nowadays consider this distinction unnecessary, since there is only rarely the need to differentiate between the G.800 "Port" and G.800 "Point" when it comes to topology descriptions (in fact I do not know of any use case where the distinction is required -- I would love to hear about one).
Regards, Freek
Freek Dijkstra wrote:
An NML "port" is equivalent to a G.800 "Forwarding Point" (or G.805 "Connection Point").
I usually refer to it as a "logical interface", to clearly distinguish it from a "physical interface".
FYI, NML has no term or concept for a "physical interface" or "physical port" other than to define it as a (logical) port on the Fiber layer. However, that concept would not include the full complexity of a physical port (e.g. adaptations to link connections on higher layers whose data pass through the physical interface, or the exact position in a device where the XFP is plugged in). If it is useful to add this concept of "physical port" next to the current "Port" (which is a logical connection point), I'm happy to hear about a use-case or a proposal. Freek
Hi, an update is attached. Two changes: - use of xCard for the contact element (rfc6351) - I was thinking a bit about "next" vs "connectedTo" (I wouldn't like to have the situation when we there are different attribute values which mean the same; let's keep the set of xml/nml elements and their attribute values as small as possible). There is a solution which avoid the conflict of existing these two values in the NML world. I propose to use a namespae for type attribute in the relation element. In the case of topology for NSI we could have nml-nsi:type which ensures that the value "connectedTo" is known and accepted by application parsers. Cheers, Roman W dniu 2012-02-15 13:41, Roman Łapacz pisze:
W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
On 15 Feb 2012, at 12:31, Roman Łapacz wrote:
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">. I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine. We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.
Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the nml-nsi namespace would be STP). "connectedTo" would work, no doubt, but the question is: should we use this if we already used "next" in circuit monitoring (and both mean the same).
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema. I'll try to find something. Any suggestions are welcome. There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think. There's also the vCard standard, for which there is (I think) both an RDF and XML notation.
yes, vCard was my first candidate as well http://tools.ietf.org/html/rfc6351
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
I forgot to remove previous contact structure. Fixed. Roman W dniu 2012-02-16 13:00, Roman Łapacz pisze:
Hi,
an update is attached. Two changes: - use of xCard for the contact element (rfc6351) - I was thinking a bit about "next" vs "connectedTo" (I wouldn't like to have the situation when we there are different attribute values which mean the same; let's keep the set of xml/nml elements and their attribute values as small as possible). There is a solution which avoid the conflict of existing these two values in the NML world. I propose to use a namespae for type attribute in the relation element. In the case of topology for NSI we could have nml-nsi:type which ensures that the value "connectedTo" is known and accepted by application parsers.
Cheers, Roman
W dniu 2012-02-15 13:41, Roman Łapacz pisze:
W dniu 2012-02-15 13:20, Jeroen van der Ham pisze:
On 15 Feb 2012, at 12:31, Roman Łapacz wrote:
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">. I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine. We're already saying that an nml-nsi:STP is equivalent to an nml:Port with some added behavior. I don't really see any reason why connectedTo would not work in this case.
Just to clarify, I propose nml-nsi:port, not nml-nsi:STP (port in the nml-nsi namespace would be STP). "connectedTo" would work, no doubt, but the question is: should we use this if we already used "next" in circuit monitoring (and both mean the same).
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema. I'll try to find something. Any suggestions are welcome. There's a FOAF namespace in RDF which describes similar things about a person. However, it's not really a standard I think. There's also the vCard standard, for which there is (I think) both an RDF and XML notation.
yes, vCard was my first candidate as well http://tools.ietf.org/html/rfc6351
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Could we have a Skype call to dscuss this...I am not following the whole proposal here - proabably because I am not clear on the NML constructs... We need some examples. I am available this afternoon (EST) after the NSI call. Thanks Jerry On 2/15/12 6:31 AM, Roman Łapacz wrote:
W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
Hi,
On 14 Feb 2012, at 14:30, Roman Łapacz wrote:
- I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network. Seems sensible to me.
- I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions. I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work. I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">.
I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
I'll try to find something. Any suggestions are welcome.
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi, tomorrow we've got the NML conf call. Can we discuss it then? Roman W dniu 2012-02-15 14:08, Jerry Sobieski pisze:
Could we have a Skype call to dscuss this...I am not following the whole proposal here - proabably because I am not clear on the NML constructs... We need some examples.
I am available this afternoon (EST) after the NSI call.
Thanks Jerry
On 2/15/12 6:31 AM, Roman Łapacz wrote:
W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
Hi,
On 14 Feb 2012, at 14:30, Roman Łapacz wrote:
- I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network. Seems sensible to me.
- I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions. I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work. I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">.
I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
I'll try to find something. Any suggestions are welcome.
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Sure - thats a good idea:-) (Duh!) Thanks Roman! J On 2/15/12 8:18 AM, Roman Łapacz wrote:
Hi,
tomorrow we've got the NML conf call. Can we discuss it then?
Roman
W dniu 2012-02-15 14:08, Jerry Sobieski pisze:
Could we have a Skype call to dscuss this...I am not following the whole proposal here - proabably because I am not clear on the NML constructs... We need some examples.
I am available this afternoon (EST) after the NSI call.
Thanks Jerry
On 2/15/12 6:31 AM, Roman Łapacz wrote:
W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
Hi,
On 14 Feb 2012, at 14:30, Roman Łapacz wrote:
- I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network. Seems sensible to me.
- I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions. I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work. I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">.
I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
I'll try to find something. Any suggestions are welcome.
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
We can certainly put this on the agenda for the NML call tomorrow. In the meantime: the current NML schema is still available at https://forge.ogf.org/sf/go/doc15481?nav=1 Jeroen. On 15 Feb 2012, at 14:08, Jerry Sobieski wrote:
Could we have a Skype call to dscuss this...I am not following the whole proposal here - proabably because I am not clear on the NML constructs... We need some examples.
I am available this afternoon (EST) after the NSI call.
Thanks Jerry
On 2/15/12 6:31 AM, Roman Łapacz wrote:
W dniu 2012-02-15 11:47, Jeroen van der Ham pisze:
Hi,
On 14 Feb 2012, at 14:30, Roman Łapacz wrote:
- I've created a new namespace nml-nsi which groups NSI elements. This allows to avoid using type attribute to indicate that, for example, the network element represents the NS network. Seems sensible to me.
- I had a problem with the STP element because in general I didn't want to introduce new names if it's not really needed. Finally, I found out (correct me if I'm wrong) that we can treat it as a port, but specific one and belonging to NSI namespace. This may be new to the NSI team but I hope it's only a matter of terminology and does not violate some basic functionality definitions. I think that that is correct. An STP is a specialized form of a Port, one that is used to define the boundary between an intra-domain network service and some other service. This can be an inter-domain network service, or something like a PerfSonar server.
An example I'm sending contains only the topology description of PIONIER (I didn't want to waste too much time for mapping all domains included in the owl file). I propose to focus on examples and later prepare the schema file (xsd or rnc; or both). This approach may speed up our work. I agree. Most domains are roughly equal in setup, and certainly equal in constructs. Doing this for one domain is fine.
On to the comments for your description:
- You're using<nml:relation type="next"> to describe connections, this should be<nml:relation type="connectedTo">.
I proposed "next" because it was already used in the framework for circuit monitoring. I'm hesitating to introduce an other name which means the same (1. as I wrote I try to limit new names; 2. use of new name would be incompatible or inconsistent with that solution for circuit monitoring). On the other hand, "connectedTo" is already used by NSI so I understand that some continuation is welcome. If you think that it's really important to keep "connectedTo" then I'm fine.
- We don't have an nml:contact object at the moment, but it seems that we may indeed need one. However, defining the contact methods should perhaps be done using some other appropriate (standard) schema.
I'll try to find something. Any suggestions are welcome.
Roman
Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Roman Łapacz wrote:
I'm sending you my first try of mapping owl topology desc into nml. Please, treat this as a start point for further discussion in order to get the final proposal for the NSI team.
Hi Roman, I have three main comments for now. 1. You use the nml "next" relation to signify a network connections. The "next" relation is already in use to describe something else: the order in XML lists (as such it is merely a syntactic construct, instead of an actual connection/relation between network elements). This was proposed in Salt Lake City last year, and agreed upon by a small margin. 2. You seem to define network ports and create relations between them to define a network topology. The NML method is instead to define the links, and create relations between them to define a network topology. You can either connect two links using a port, or connect them directly together (which is slightly shorter to describe circuits through a network). 3. As Jeroen mentioned, I would refer to vCard for defining contacts, and XML (or OWL) schemas are great in combining multiple schemas in one document. Freek
W dniu 2012-02-16 13:16, Freek Dijkstra pisze:
Roman Łapacz wrote:
I'm sending you my first try of mapping owl topology desc into nml. Please, treat this as a start point for further discussion in order to get the final proposal for the NSI team. Hi Roman,
Hi Freek,
I have three main comments for now.
1. You use the nml "next" relation to signify a network connections. The "next" relation is already in use to describe something else: the order in XML lists (as such it is merely a syntactic construct, instead of an actual connection/relation between network elements). This was proposed in Salt Lake City last year, and agreed upon by a small margin.
I replaced that with nml-nsi:type="connectedTo" (suggested by Jeroen). See my last update. But even if we wanted to use "next" I wouldn't see the problem in using it for network connections and lists (in fact, network connections are the lists of ports or links).
2. You seem to define network ports and create relations between them to define a network topology. The NML method is instead to define the links, and create relations between them to define a network topology. You can either connect two links using a port, or connect them directly together (which is slightly shorter to describe circuits through a network).
I wanted to be as close as possible to the example that Jeroen sent. I believe that NML should be flexible and allow creating relations between ports or links. I see (this is my vision) NML as a set of components that you can use to build various complex topology structures according to the needs raised by users (in this case NSI).
3. As Jeroen mentioned, I would refer to vCard for defining contacts, and XML (or OWL) schemas are great in combining multiple schemas in one document.
Done. See my last update. Roman
Freek
Hi Roman, Sorry, I saw your new file after I send my email (insert rant about gray-listing here). It seems that NSI uses a different topology concept than NML, using the (NDL-based?) connectedTo. This is different from what we have in the examples (relating either links with port using "source" and "sink", or as I proposed, directly connecting two links with "serialcompound" relation). Perhaps it is good to discuss this in today's call. Nevertheless, it seems that the concepts are sufficiently equivalent to merge the NSI and NML topology concept. Freek
W dniu 2012-02-16 14:27, Freek Dijkstra pisze:
Hi Roman,
Sorry, I saw your new file after I send my email (insert rant about gray-listing here).
It seems that NSI uses a different topology concept than NML, using the (NDL-based?) connectedTo. This is different from what we have in the examples (relating either links with port using "source" and "sink", or as I proposed, directly connecting two links with "serialcompound" relation). Perhaps it is good to discuss this in today's call.
Nevertheless, it seems that the concepts are sufficiently equivalent to merge the NSI and NML topology concept.
My thinking is that NML would be more interesting and useful for users (in this case NSI) if we don't impose too many resrtictions. As I wrote NML could offer a set of elements, basic relations and minimal set of rules how to use them (we may have suggestion and examples of usage). It would be up to users and their use cases which elements and combination of them are used. Of course there's a risk of going too far with such open approach but ... what the hell, users are always right :) Roman
Freek
Roman Łapacz wrote:
W dniu 2012-02-16 14:27, Freek Dijkstra pisze:
Hi Roman,
Sorry, I saw your new file after I send my email (insert rant about gray-listing here).
It seems that NSI uses a different topology concept than NML, using the (NDL-based?) connectedTo. This is different from what we have in the examples (relating either links with port using "source" and "sink", or as I proposed, directly connecting two links with "serialcompound" relation). Perhaps it is good to discuss this in today's call.
Nevertheless, it seems that the concepts are sufficiently equivalent to merge the NSI and NML topology concept.
My thinking is that NML would be more interesting and useful for users (in this case NSI) if we don't impose too many restrictions.
I agree if you are saying "don't impose too many restrictions on the network topology that users can describe". I disagree if you are saying "don't impose too many restrictions on the number of ways that users can describe the same topology". In both cases the core building blocks are (logical) ports and links between these logical ports, and I do not see any restrictions there (which I think is good), but I do see two different methods how this same topology is described (which I think is bad). Regards, Freek
On Feb 16, 2012, at 7:03 AM, Freek Dijkstra wrote:
My thinking is that NML would be more interesting and useful for users (in this case NSI) if we don't impose too many restrictions.
I agree if you are saying "don't impose too many restrictions on the network topology that users can describe".
I disagree if you are saying "don't impose too many restrictions on the number of ways that users can describe the same topology".
Freek++ We can't forget the primary purpose of the schema. It is to communicate the topology among software/hardware implementations. It is not to describe it to humans. And, we want that software to be as simple to write and keep up to date as possible. (So - lets not have multiple ways to describe the same topology please.) Computers don't care if this is 'Next' or 'ConnectedTo'. It could be called 'RelationType3' and it would be just fine as long as it is consistent. The only reason to name it something in particular is to make sure it is understandable to the programmers writing the software. Lets just pick something, document it well, and move on. ;) Jeff
In both cases the core building blocks are (logical) ports and links between these logical ports, and I do not see any restrictions there (which I think is good), but I do see two different methods how this same topology is described (which I think is bad).
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jeff W. Boote wrote:
Computers don't care if this is 'Next' or 'ConnectedTo'.
I think the issue ad hand is unfortunately a bit more complex. The question at hand is basically how to describe the following (with apologies with my poor ASCII art skills) port A link X port B link Y port C O------------------>O------------------>O Roman described this as: Port A relation=next/connectTo port B Port B relation=next/connectTo port C In the NML schema it is currently defined as: link X relation=source port A relation=sink port B link Y relation=source port B relation=sink port C Previous year I noticed some reluctance in describing both Ports and Links in examples, and asked if there was need to simplify as follows: link X relation=serialcompound link Y (After which the discussion ended in "that's a might ugly word `serialcompound' there, that's how G.800 defined it and I wasn't creative enough to come up with something better".) At this moment, neither "serialcompound" nor "connectTo" are valid NML constructs. What I'm saying is that I would regret seeing all three options as "valid". The current source/sink think is most flexible, but I'm happy to consider alternatives. Please discuss. Regards, Freek
W dniu 2012-02-16 16:33, Freek Dijkstra pisze:
Jeff W. Boote wrote:
Computers don't care if this is 'Next' or 'ConnectedTo'. I think the issue ad hand is unfortunately a bit more complex.
The question at hand is basically how to describe the following (with apologies with my poor ASCII art skills)
port A link X port B link Y port C O------------------>O------------------>O
Roman described this as:
Port A relation=next/connectTo port B Port B relation=next/connectTo port C
In the NML schema it is currently defined as:
link X relation=source port A relation=sink port B link Y relation=source port B relation=sink port C
Previous year I noticed some reluctance in describing both Ports and Links in examples, and asked if there was need to simplify as follows:
link X relation=serialcompound link Y
(After which the discussion ended in "that's a might ugly word `serialcompound' there, that's how G.800 defined it and I wasn't creative enough to come up with something better".)
At this moment, neither "serialcompound" nor "connectTo" are valid NML constructs.
What I'm saying is that I would regret seeing all three options as "valid".
But if NSI wants to use paths/links as connected ports because of some reasons then I woul be open to let them do it this way. Other users/applications may prefer using links because of some other reasons. By setting the limits should we prevent various users/applications from utilizing NML? Do we want to be so strict? Extensions (namespaces) and minimal set of rules would be an answer. Roman
The current source/sink think is most flexible, but I'm happy to consider alternatives. Please discuss.
Regards, Freek
Roman Łapacz wrote:
The question at hand is basically how to describe the following (with apologies with my poor ASCII art skills)
port A link X port B link Y port C O------------------>O------------------>O
Roman described this as:
Port A relation=next/connectTo port B Port B relation=next/connectTo port C
In the NML schema it is currently defined as:
link X relation=source port A relation=sink port B link Y relation=source port B relation=sink port C
Previous year I noticed some reluctance in describing both Ports and Links in examples, and asked if there was need to simplify as follows:
link X relation=serialcompound link Y
[...]
What I'm saying is that I would regret seeing all three options as "valid".
But if NSI wants to use paths/links as connected ports because of some reasons then I would be open to let them do it this way. Other users/applications may prefer using links because of some other reasons. By setting the limits should we prevent various users/applications from utilizing NML? Do we want to be so strict? Extensions (namespaces) and minimal set of rules would be an answer.
I do not see how the current source/sink syntax "prevent various users/applications from utilizing NML". I agree it is not the most compact syntax out there. But I think it makes it possible to describe the network topology that NSI uses. Again, that should be the restriction: can it describe the desired topology. Not: does it match the syntactical constructs we currently have. Freek
W dniu 2012-02-16 17:09, Freek Dijkstra pisze:
Roman Łapacz wrote:
The question at hand is basically how to describe the following (with apologies with my poor ASCII art skills)
port A link X port B link Y port C O------------------>O------------------>O
Roman described this as:
Port A relation=next/connectTo port B Port B relation=next/connectTo port C
In the NML schema it is currently defined as:
link X relation=source port A relation=sink port B link Y relation=source port B relation=sink port C
Previous year I noticed some reluctance in describing both Ports and Links in examples, and asked if there was need to simplify as follows:
link X relation=serialcompound link Y
[...]
What I'm saying is that I would regret seeing all three options as "valid". But if NSI wants to use paths/links as connected ports because of some reasons then I would be open to let them do it this way. Other users/applications may prefer using links because of some other reasons. By setting the limits should we prevent various users/applications from utilizing NML? Do we want to be so strict? Extensions (namespaces) and minimal set of rules would be an answer. I do not see how the current source/sink syntax "prevent various users/applications from utilizing NML".
I agree it is not the most compact syntax out there. But I think it makes it possible to describe the network topology that NSI uses.
Again, that should be the restriction: can it describe the desired topology. Not: does it match the syntactical constructs we currently have.
I see you point and am not against. I'm only asking the questions which may appear on the user side. The best way is to answer someone from NSI. Roman
Freek
participants (5)
-
Freek Dijkstra -
Jeff W. Boote -
Jeroen van der Ham -
Jerry Sobieski -
Roman Łapacz