[Nsi-wg] Adding service definition elements to NML

[Henrik Thostrup Jensen]

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