[Nsi-wg] NSI WSDL - The Maastricht Updates

[John MacAuley]

Jeroen,

In this case the XSD contracted interface is for Mb/s, and therefore, specifying a unit qualifier would be redundant.  It is a nice convenience function for a human, but I do not think it provides value programatically.

As for being verbose, the p2p namespace could be specified once in the serviceAttribute elements, or in the main reserve header to reduce the need to have it in every attribute.  I put it there for illustration purposes.

John.

On 2013-06-20, at 4:13 AM, Jeroen van der Ham <vdham at uva.nl> wrote:

> Hi,
> 
> As long as we're being verbose, I would suggest to add a "unit" attribute to the bandwidth to make sure that everyone understands that this is in megabits.
> 
> Jeroen.
> 
> On 20 Jun 2013, at 05:49, John MacAuley <john.macauley at surfnet.nl> wrote:
> 
>> Peoples,
>> 
>> To follow up with the simplification I mentioned on the call today I have pulled together two example reserve requests.  Here is the current structure with dedicated bandwidth and path attributes in the criteria element.
>> 
>> <tns:reserve
>>   xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types"
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> 
>>   <connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId>
>>   <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId>
>>   <description></description>
>>   <criteria version="1">
>>       <schedule>
>>           <startTime>2013-09-30T09:30:10Z</startTime>
>>           <endTime>2013-09-30T10:30:10Z</endTime>
>>       </schedule>
>>       <bandwidth>1000</bandwidth>
>>       <serviceAttributes>
>>           <attribute type="sNCP" targetNamespace="http://schemas.surfnet.nl/nsi/2013/04/services">
>>               <value>Protected</value>
>>           </attribute>
>>           <attribute>
>>               <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP>
>>           </attribute>
>>       </serviceAttributes>
>>       <path>
>>           <directionality>Bidirectional</directionality>
>>           <symmetricPath>true</symmetricPath>
>>           <sourceSTP>
>>               <networkId>urn:ogf:network:netherlight.net:2012</networkId>
>>               <localId>uvalight-netherlight</localId>
>>           </sourceSTP>
>>           <destSTP>
>>               <networkId>urn:ogf:network:netherlight.net:2012</networkId>
>>               <localId>netherlight-czechlight</localId>
>>           </destSTP>
>>       </path>
>>   </criteria>
>> </tns:reserve>
>> 
>> Notice the service attributes provided.  This is an example of the two ways we can specify the same thing, and in this case, it is the SURFnet subnetwork protection attribute.  I would like to flatten the serviceAttributes structure to a simple ANY to give us the following:
>> 
>>       <serviceAttributes>
>>           <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP>
>>       </serviceAttributes>
>> 
>> Now onto the key point I was trying to get across.  Bandwidth and path are specific to a symmetric point-to-point service.  I would like to make a simple change to move bandwidth and path into serviceAttributes with their own specific p2pservice namespace.  This will let us have a more generic reserve message.  Here is an example:
>> 
>> <tns:reserve
>>   xmlns:tns="http://schemas.ogf.org/nsi/2013/04/connection/types"
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>> 
>>   <connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId>
>>   <globalReservationId>urn:uuid:83fe4f36-5b38-41b6-bc46-a362a06a54ee</globalReservationId>
>>   <description></description>
>>   <criteria version="1">
>>       <schedule>
>>           <startTime>2013-09-30T09:30:10Z</startTime>
>>           <endTime>2013-09-30T10:30:10Z</endTime>
>>       </schedule>
>>       <serviceAttributes>
>>           <p2p:bandwidth xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice">1000</p2p:bandwidth>
>>           <p2p:path xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/connection/p2pservice">
>>               <directionality>Bidirectional</directionality>
>>               <symmetricPath>true</symmetricPath>
>>               <sourceSTP>
>>                   <networkId>urn:ogf:network:netherlight.net:2012</networkId>
>>                   <localId>uvalight-netherlight</localId>
>>               </sourceSTP>
>>               <destSTP>
>>                   <networkId>urn:ogf:network:netherlight.net:2012</networkId>
>>                   <localId>netherlight-czechlight</localId>
>>               </destSTP>
>>           </p2p:path>
>>           <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP>
>>       </serviceAttributes>
>>   </criteria>
>> </tns:reserve>
>> 
>> This will allow us to use the existing XSD for new service definitions without needing to modify the schema.  New attributes can be imported for other namespaces when defined.  It really is a simple change and it should provide good value.
>> 
>> Comments?
>> 
>> John
>> 
>> On 2013-06-19, at 9:51 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:
>> 
>>> On Tue, 18 Jun 2013, John MacAuley wrote:
>>> 
>>>> Here is the reason you are seeing these attributes as optional: The modify command was folded into the reserve command, and therefore, must now share the same types.
>>> 
>>> Thanks. Makes sense.
>>> 
>>> However, with that in mind I think the seperation between ReservationRequestCriteriaType and ReservationConfirmCriteriaType makes evene less sense. They carry the same data, and there will always need to be some sanity checking outside the xml-xsd correlation anyway.
>>> 
>>> 
>>>  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
>> 
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>