July 2013 - Nsi-wg - lists.ogf.org

Issue 94 in ogf-nsi-project: Simplify serviceAttributes definition.
by ogf-nsi-project＠googlecode.com 04 Jul '13

04 Jul '13

Status: Accepted Owner: jmacauley Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 94 by jmacauley: Simplify serviceAttributes definition. http://code.google.com/p/ogf-nsi-project/issues/detail?id=94 Current serviceAttributes definition can consist of both type/value pairs or ANY elements included from other namespaces. targetNamespace="http://schemas.ogf.org/nsi/2013/04/connection/types" <xsd:element name="serviceAttributes" type="ftypes:TypeValuePairListType" minOccurs="0" /> targetNamespace="http://schemas.ogf.org/nsi/2013/04/framework/types" <xsd:complexType name="TypeValuePairListType"> <xsd:sequence> <xsd:element name="attribute" type="tns:TypeValuePairType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> <xsd:complexType name="TypeValuePairType"> <xsd:sequence> <xsd:element name="value" type="xsd:string" nillable="true" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="type" type="xsd:string" use="optional" /> <xsd:attribute name="targetNamespace" type="xsd:anyURI" use="optional" /> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> This allows us to specify the same thing two different ways. The example below shows how I can specify a custom attribute "sNCP" from the SURFnet namespace. <serviceAttributes> <attribute> <surf:sNCP xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">Protected</surf:sNCP> </attribute> <attribute type="sNCP" targetNamespace="http://schemas.surfnet.nl/nsi/2013/04/services"> <value>Protected</value> </attribute> </serviceAttributes> The proposal is to flatten the serviceAttributes to contain only the ANY structure as follows: targetNamespace="http://schemas.ogf.org/nsi/2013/04/connection/types" <xsd:element name="serviceAttributes" type="tns:ServiceAttributesType" minOccurs="0" /> <xsd:complexType name="ServiceAttributesType"> <xsd:sequence> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:anyAttribute namespace="##other" processContents="lax" /> </xsd:complexType> This will restrict the protocol to a singular mechanism of attribute specification. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

Issue 96 in ogf-nsi-project: Add dataPlaneStateChange notifications to QueryNotificationConfirmedType.
by ogf-nsi-project＠googlecode.com 04 Jul '13

04 Jul '13

Status: Accepted Owner: jmacauley Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 96 by jmacauley: Add dataPlaneStateChange notifications to QueryNotificationConfirmedType. http://code.google.com/p/ogf-nsi-project/issues/detail?id=96 The current QueryNotificationConfirmedType does not return dataPlaneStateChange notifications since this information is already available in the reservation query results. Including the dataPlaneStateChange notifications would provide minimal additional value. The current QueryNotificationConfirmedType appears as follows: <xsd:complexType name="QueryNotificationConfirmedType"> <xsd:sequence> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="tns:errorEvent" /> <xsd:element ref="tns:reserveTimeout" /> <xsd:element ref="tns:messageDeliveryTimeout" /> </xsd:choice> </xsd:sequence> </xsd:complexType> Feed back from design teams has indicated that for consistency they would like dataPlaneStateChange notifications to be included in the QueryNotificationConfirmedType for consistent notification behaviours. The NSI working group agreed that this change would be acceptable to provide the requested consistency. The type definition will be changed to the following: <xsd:complexType name="QueryNotificationConfirmedType"> <xsd:sequence> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element ref="tns:errorEvent" /> <xsd:element ref="tns:reserveTimeout" /> <xsd:element ref="tns:dataPlaneStateChange" /> <xsd:element ref="tns:messageDeliveryTimeout" /> </xsd:choice> </xsd:sequence> </xsd:complexType> -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

Issue 93 in ogf-nsi-project: Correct ReserveConfirmedType that has zero to many criteria elements.
by ogf-nsi-project＠googlecode.com 04 Jul '13

04 Jul '13

Status: Accepted Owner: jmacauley Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 93 by jmacauley: Correct ReserveConfirmedType that has zero to many criteria elements. http://code.google.com/p/ogf-nsi-project/issues/detail?id=93 The ReserveConfirmedType has an incorrectly enumerated criteria element. <xsd:element name="criteria" type="tns:ReservationConfirmCriteriaType" minOccurs="0" maxOccurs="unbounded" /> There should always be a single criteria returned. Resolution: Remove minOccurs="0" maxOccurs="unbounded" specification. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

NSIv2 interop testing
by Henrik Thostrup Jensen 03 Jul '13

03 Jul '13

Hi everyone Might as well get started with this :-) I have a NSI2 provider endpoint here: http://nsidev.nordu.net:9080/NSI/services/CS2 NSA name: urn:ogf:network:nsa:northernlight It manages a network named: urn:ogf:network:northernlight It has the following ports: ps netherlight uvalight These are all bidirectional, and ethernet vlan ports. They expect a vlan type attribute with a value, which can be a range, i.e.: <sourceSTP> <networkId>urn:ogf:network:northernlight</networkId> <localId>urn:ogf:network:northernlight:ps</localId> <labels> <ns3:attribute type="vlan"> <value>2-3</value> </ns3:attribute> </labels> </sourceSTP> They support the VLANs 1780-1783, but I have a bug in the label selection, so right now you can specify whatever, but I'll get that fixed :-). There are definitely bugs in this thing, so don't be too surprised if you find something. There is also a topology resource available here: http://nsidev.nordu.net:9080/NSI/topology/northernlight.xml There are however known structural errors in this, so for now it is just for show. If anyone else has provider endpoints ready for testing, post them to mailling list or just me, and I'll give them a go :-). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 1

call for new functions in NSI
by Guy Roberts 01 Jul '13

01 Jul '13

Hello All, Now that NSI v2.0 is nearly out the door we should be looking ahead to the next phase of NSI. The NSI working group will meet in Singapore in the week beginning 30th September to discuss the next steps for NSI - details of the meeting will be announced on this mailing list. If you have any ideas for NSI enhancements please prepare a presentation for that meeting. Regards, Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

2 1

Service decoupling proposal
by John MacAuley 01 Jul '13

01 Jul '13

All, Please find attached the service decoupling proposal discussed a couple weeks ago via e-mail. The document describes the current XSD structure and associated issues, as well as the proposed minor changes to fix the problem. I have also included the modified schema files and an example of a new reserve message. Behaviours remain the same. John

2 1