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