Re: [Nsi-wg] Adding service definition elements to NML

29 Oct 2013

      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