[Nsi-wg] Adding service definition elements to NML

[John MacAuley]

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 at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg