[Nml-wg] [Nsi-wg] STPs in NSI v2.0

[Roman Łapacz]

W dniu 2012-07-11 14:34, Freek Dijkstra pisze:
> On 11-07-2012 14:10, Roman Łapacz wrote:
>
>> W dniu 2012-07-10 22:27, Freek Dijkstra pisze:
>>>       <nsi:path>
>>>           <!-- Two STP, each with a source and sink: a bidirectional path -->
>>>           <nsi:STP>
>>>               <Network>urn:ogf:network:cesnet.cz:2012:czechlight</Network>
>>>               <!-- No VLAN specified: pick any one VLAN within these Port Groups. -->
>>>               <source><nml:PortGroup>urn:ogf:network:nordu.net:2012:nordunet-surfnet</nml:PortGroup></source>
>>>               <sink><nml:PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</nml:PortGroup></sink>
>>>           </nsi:STP>
>>>           <nsi:STP>
>>>               <Network>urn:ogf:network:sne.science.uva.nl:2012:lighthouse</Network>
>>>               <!-- No VLAN specified: pick any one VLAN within these Port Groups. -->
>>>               <source><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress</nml:PortGroup></source>
>>>               <sink><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress</nml:PortGroup></sink>
>>>           </nsi:STP>
>>>       </nsi:path>
>> Freek, in your examples sent to the NSI group you didn't use idRef
>> attribute for nml:GroupPort (or nml:Port). It's a small thing but I
>> think we should be strict to use accepted structures. To me using tag
>> values for this is not supported by NML at the moment (if we had xsd or
>> rnc schema this would be verified easily).
> Hi Roman,
>
> That's correct, but the above isn't NML. It is NSI which is referring to
> NML objects. Given that NSI does not use id/idRef I decided to use their
> syntax.
>
> But you are right that in that case I shouldn't have used the nml
> namespace if it is not NML.
>
> What do you suggest?

I would not use nml namespace if the elements don't apply NML schema.  
Simply, I would remove it from your examples.

>
> I can understand the desire to make it a short piece of NML, but that
> would require introducing id/idRef, the hasInboundPort/hasOutboundPort
> relations, hence the nml:Relation construct. The original proposal used
> query parts in the URN, which is not part of NML (I'm not even sure if
> the query part is part of the URN or not -- see my mail
> http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html).

I like Aaron proposal to use child elements and keep URN 
identifiers/strings static.

>
> A further complication was that the NSI in some case want to define a
> Port or subset of the PortGroup within a larger PortGroup by identifying
> it by its label or label subset, without actually naming the result.
> That would require me to introduce unnamed NML objects (NML objects
> without a URN identifier, that are identified by their properties). I
> may want to do that anyway, but felt this was a bit too much wrestling
> if all I wanted was a reference.

Do we really need to have such unnamed NML objects? Maybe some query 
syntax used by NSI would represent the groups filtered from NML 
topologies (clear distinction: NML gives topology data,  applications 
parse/fetch/filter that data the way they need).

Roman

>
> But by all means rewrite the examples and propose it to NML + NSI. To me
> this is not NML, but you have a valid argument that if this is just
> syntactic sugar to define a reference, why not make the sugar look like
> the same.
>
> Regards,
> Freek