[Nsi-wg] Adding service definition elements to NML

[John MacAuley]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20131028/16960d9c/attachment.html>