Peoples, Our decision in Madrid was to associate a list of applicable service definitions against an STP within our topology definitions. The question I have is a that of procedure. At the moment there is the base NML specification (nmlbase.xsd) which we should never have to touch. Then there is the NML extensions for NSI (nsi-ext.xsd) which contains definitions for our NSA and Service entries. It is my assumption that we should we be expanding on the "NML extensions for NSI" document instead of creating an additional "NSI extensions for NML extensions for NSI". Do people agree? I had a look through the NML base definitions and it looks like we could put a serviceDefinition element into the base PortType definition through the XML ANY held in the BasePortContent group. However, we are in a bit of a pickle for PortGroup because it does not contain a direct child XML ANY element. Therefore, we will need to access indirectly through a Port element, which may confuse the meaning of PortGroup a little bit. I have included a mock example below: <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Port><nsi:serviceDefinition type="EVTS.A-GOLE"/></nml:Port> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation> The other option we have is to invert the relationship and include the member Port/PortGroup elements in a service definition element as a child of the Topology element something like this: <nml:Topology id="urn:ogf:network:example.org:2013:topology"> <nml:name>ExampleA Topology</nml:name> <nsi:ServiceDefinition type="http://services.ogf.org/nsi/2013/07/definitions/EVTS.A-GOLE"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out" /> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in" /> </nsi:ServiceDefinition> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-in"/> </nml:Relation> </nml:PortGroup> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation> </nml:Topology> I believe that given the current limitations of the NML base schema we should probably use the second mechanism. It seem to fit a bit better and will contain the ServiceDefinition element to a single location on the Topology element. Comments? John
On Mon, 28 Oct 2013, John MacAuley wrote:
I had a look through the NML base definitions and it looks like we could put a serviceDefinition element into the base PortType definition through the XML ANY held in the BasePortContent group. However, we are in a bit of a pickle for PortGroup because it does not contain a direct child XML ANY element.
:-(.
Therefore, we will need to access indirectly through a Port element, which may confuse the meaning of PortGroup a little bit. I have included a mock example below:
<nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Port><nsi:serviceDefinition type="EVTS.A-GOLE"/></nml:Port> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation>
Please... no.
The other option we have is to invert the relationship and include the member Port/PortGroup elements in a service definition element as a child of the Topology element something like this:
<nml:Topology id="urn:ogf:network:example.org:2013:topology"> <nml:name>ExampleA Topology</nml:name> <nsi:ServiceDefinition type="http://services.ogf.org/nsi/2013/07/definitions/EVTS.A-GOLE"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out" /> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in" /> </nsi:ServiceDefinition> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-in"/> </nml:Relation> </nml:PortGroup> </nml:Relation>
<nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation> </nml:Topology>
I am not thrilled about this one either. Similar to bidirectional port construct it forces a two-stage parsing, where one first has to build up an intermediate representation, and then build up the final representation, where one can put service definitions in the ports.
I believe that given the current limitations of the NML base schema we should probably use the second mechanism. It seem to fit a bit better and will contain the ServiceDefinition element to a single location on the Topology element.
The second option might be ever so slightly better than the first. However I don't think any of them are really good. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Well, the only other alternative I can see is expanding the NML specification to add an XML ANY to be added to PortGroupType and probably BidirectionalPortType at the same time. I have no issue with the multiple parsing at the moment as i am already doing it so I can create a completely separate NSI topology model using Network, STP, SDP, and the new TransferFunction. Do you have any additional thoughts? John On 2013-10-29, at 6:18 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Mon, 28 Oct 2013, John MacAuley wrote:
I had a look through the NML base definitions and it looks like we could put a serviceDefinition element into the base PortType definition through the XML ANY held in the BasePortContent group. However, we are in a bit of a pickle for PortGroup because it does not contain a direct child XML ANY element.
:-(.
Therefore, we will need to access indirectly through a Port element, which may confuse the meaning of PortGroup a little bit. I have included a mock example below: <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Port><nsi:serviceDefinition type="EVTS.A-GOLE"/></nml:Port> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation>
Please... no.
The other option we have is to invert the relationship and include the member Port/PortGroup elements in a service definition element as a child of the Topology element something like this: <nml:Topology id="urn:ogf:network:example.org:2013:topology"> <nml:name>ExampleA Topology</nml:name>
<nsi:ServiceDefinition type="http://services.ogf.org/nsi/2013/07/definitions/EVTS.A-GOLE"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out" /> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in" /> </nsi:ServiceDefinition>
<nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-in"/> </nml:Relation> </nml:PortGroup> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation> </nml:Topology>
I am not thrilled about this one either. Similar to bidirectional port construct it forces a two-stage parsing, where one first has to build up an intermediate representation, and then build up the final representation, where one can put service definitions in the ports.
I believe that given the current limitations of the NML base schema we should probably use the second mechanism. It seem to fit a bit better and will contain the ServiceDefinition element to a single location on the Topology element.
The second option might be ever so slightly better than the first.
However I don't think any of them are really good.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Tue, 29 Oct 2013, John MacAuley wrote:
Well, the only other alternative I can see is expanding the NML specification to add an XML ANY to be added to PortGroupType and probably BidirectionalPortType at the same time.
There are no really good options here. Convulated solution or a new base schema :-|.
I have no issue with the multiple parsing at the moment as i am already doing it so I can create a completely separate NSI topology model using Network, STP, SDP, and the new TransferFunction.
Out of curiosity: I had to rewrite a large portion of the OpenNSA topology code to handle NML, as the flat model of NML is significantly different from the hierarchical model we had previously (wrapping the other way would be easy though). How do you map/wrap that? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Are you asking how I parse the existing NML into the NSI model? On 2013-10-29, at 10:32 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Tue, 29 Oct 2013, John MacAuley wrote:
Well, the only other alternative I can see is expanding the NML specification to add an XML ANY to be added to PortGroupType and probably BidirectionalPortType at the same time.
There are no really good options here. Convulated solution or a new base schema :-|.
I have no issue with the multiple parsing at the moment as i am already doing it so I can create a completely separate NSI topology model using Network, STP, SDP, and the new TransferFunction.
Out of curiosity: I had to rewrite a large portion of the OpenNSA topology code to handle NML, as the flat model of NML is significantly different from the hierarchical model we had previously (wrapping the other way would be easy though). How do you map/wrap that?
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Tue, 29 Oct 2013, John MacAuley wrote:
Are you asking how I parse the existing NML into the NSI model?
Yes. Specifically how you get the NML model "ports are top level objects and a topology is just a grouping of ports" into the NSI model "ports are strongly scoped inside networks". Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 28 Oct 2013, at 16:31, John MacAuley <john.macauley@surfnet.nl> wrote:
Our decision in Madrid was to associate a list of applicable service definitions against an STP within our topology definitions. The question I have is a that of procedure. At the moment there is the base NML specification (nmlbase.xsd) which we should never have to touch. Then there is the NML extensions for NSI (nsi-ext.xsd) which contains definitions for our NSA and Service entries. It is my assumption that we should we be expanding on the "NML extensions for NSI" document instead of creating an additional "NSI extensions for NML extensions for NSI". Do people agree?
The "NML Extensions for NSI” document is still in draft, so it can be changed. If you have suggestions, patches or text are welcome!
I had a look through the NML base definitions and it looks like we could put a serviceDefinition element into the base PortType definition through the XML ANY held in the BasePortContent group. However, we are in a bit of a pickle for PortGroup because it does not contain a direct child XML ANY element. Therefore, we will need to access indirectly through a Port element, which may confuse the meaning of PortGroup a little bit. I have included a mock example below:
This seems like an error in the NML spec, as the PortGroup element (like other elements in NML) should be extensible.
I believe that given the current limitations of the NML base schema we should probably use the second mechanism. It seem to fit a bit better and will contain the ServiceDefinition element to a single location on the Topology element.
I have no preference for either. I’m happy to see that someone is finally giving the NML base schema the scrutiny it has needed for some time. Any changes you find necessary to make this into a proper schema are very welcome. Jeroen.
participants (3)
-
Henrik Thostrup Jensen -
Jeroen van der Ham -
John MacAuley