- Nsi-wg - lists.ogf.org

NSI v2.0 feature list
by Guy Roberts 11 Mar '13

11 Mar '13

Hello NSI team, Welcome to OGF37. To help us keep track of decisions we make this week the agreed NSI v2.0 features will be logged in this Google Document: https://docs.google.com/document/d/1_X0pqbc-DqbzDI_C259rz9npk7EuEmZFoq3CU98… Please feel free to edit this document by adding your thoughts in the benefits/risks columns. 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. _____________________________________________________________________

1 0

Question about NSA identifier
by John MacAuley 10 Mar '13

10 Mar '13

Peoples, I was running through the bootstrap procedure with Chin when the question of multiple NSA identifiers per software instance came up. Can someone please explain to me again why we need a one-to-one mapping between NSA (NSA identifier) and Network (Network Identifier)? It seems to be a very arbitrary restriction. I have looked through the existing WSDL definitions and there are no restrictions within it for this imposed rule. In addition, the topology schema could easily have multiple "managing" elements within the NSA object to allow it to reference multiple Network Identifiers, thereby creating a one-to-many relationship. We have a very real network requirement to support multiple network services off of a single NSA software instance. For example, off of one NSA (urn:ogf:network:surfnet.nl:2012:nsa) we can support the ETS service (urn:ogf:network:surfnet.nl:2012:ets) and an EPL service (urn:ogf:network:surfnet.nl:2012:epl). At the moment, given the current restriction, I would have to have two separate NSA. Does anyone have a reason why we can't remove this restriction? Thank you, John

4 4

Issue 76 in ogf-nsi-project: Change WSDL so connection identifier is allocated by provider NSA
by ogf-nsi-project＠googlecode.com 09 Mar '13

09 Mar '13

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 76 by jmacau...(a)gmail.com: Change WSDL so connection identifier is allocated by provider NSA http://code.google.com/p/ogf-nsi-project/issues/detail?id=76 Description of Issue: In NSI CS v1.1 the requesting NSA provides the connection identifier that is used to reference the connection within the provider NSA. This implies a connection can only be identified by the tuple (Requester NSA, Provider NSA, connection ID). Furthermore, the context of a connection identifier is only addressable from the point of view of the Requesting NSA since we do not provide the ability to specify the referencing tuple within the existing protocol specification. As a result, no external entities are able to reference a reservation within a provider NSA. Resolution of Issue: E-mail list discussion in late August 2012 agreed to changing the NSI CS v2.0 protocol to allow for provider allocated connection identifiers. The following changes were agreed to: 1. In the ACK to the reservation request the Provider NSA will return the reservation ID it has associated with the new reservation. 2. The reservation confirm will still return the result of the reservation. 3. Connection Identifier specification will be relaxed to remove the need for a UUID. -- 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 71 in ogf-nsi-project: Separate summary and detailed query functionality into separate operations.
by ogf-nsi-project＠googlecode.com 08 Mar '13

08 Mar '13

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 71 by jmacau...(a)gmail.com: Separate summary and detailed query functionality into separate operations. http://code.google.com/p/ogf-nsi-project/issues/detail?id=71 Description of Issue: For consistency with the new querySummarySync() operation we are breaking they existing asynchronous query operation into two separate operations: querySummary(), and queryTree(). querySummary() would provide the existing summary query capabilities and queryTree() would provide the existing detailed query capabilities. Resolution of Issue: Modification of the WSDL to separate existing query behaviour into two separate operations. -- 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 70 in ogf-nsi-project: Add new querySummarySync operation.
by ogf-nsi-project＠googlecode.com 08 Mar '13

08 Mar '13

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 70 by jmacau...(a)gmail.com: Add new querySummarySync operation. http://code.google.com/p/ogf-nsi-project/issues/detail?id=70 Description of Issue: An NSI client (Requester Agent) allocated a private IP address behind a firewall is not capable of easily participating in the NSI protocol. NSI CS 2.0 utilizes asynchronous callbacks (endpoint specified in replyTo field) to deliver confirmation and failure messages to requesting clients. The firewall will block these asynchronous callbacks if not properly configured. To help this type of isolated client, the asynchronous callback has been made optional, but a new synchronous method of querying reservations must be provided to allow for an isolated client to poll reservation status. Discussion of Issue: Issue and solution was discussed in weekly OGF NSI working group meeting on January 23 2013. The slide package NSI-Synchronous-Query-v1 found at https://redmine.ogf.org/dmsf_files/13015?download= provides a detailed description. Resolution of Issue: Introduce a new querySummarySync message that has the behaviour for the summary query, but returned the confirmation or failure message in the SOAP response to the request. -- 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 73 in ogf-nsi-project: Remove unused SAML XSD import from ogf_nsi_connection_types_v2_0.xsd
by ogf-nsi-project＠googlecode.com 07 Mar '13

07 Mar '13

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 73 by jmacau...(a)gmail.com: Remove unused SAML XSD import from ogf_nsi_connection_types_v2_0.xsd http://code.google.com/p/ogf-nsi-project/issues/detail?id=73 Description of Issue: Refactoring of common NSI header attributes out of the NSI CS 1.1 definition resulted in an unused import of SAML XSD definition in ogf_nsi_connection_types_v2_0.xsd. Resolution of Issue: Minutes NSI-WG conf call 23 Jan 2013 - Remove unused SAML XSD import. -- 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 69 in ogf-nsi-project: Remove the STP orientation element.
by ogf-nsi-project＠googlecode.com 07 Mar '13

07 Mar '13

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 69 by jmacau...(a)gmail.com: Remove the STP orientation element. http://code.google.com/p/ogf-nsi-project/issues/detail?id=69 Description of Issue: Questions were raised with respect to the usefulness of the STP orientation element. Discussion of Issue: GR presented on Orientation attribute: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6532 Discussion on whether Orientation attribute is needed… HTJ and GR thought not, JS thought that it was needed and will present a discussion paper. Resolution of Issue: Remove orientation attribute. -- 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 72 in ogf-nsi-project: Remove NetworkIdType definition
by ogf-nsi-project＠googlecode.com 07 Mar '13

07 Mar '13

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 72 by jmacau...(a)gmail.com: Remove NetworkIdType definition http://code.google.com/p/ogf-nsi-project/issues/detail?id=72 Description of Issue: Original NSI CS 1.0 WSDL definition had all base identifiers such as NetworkId defined as base types (NetworkIdType) to centralize the XML type definition in a single location. This made it easer to change during all the churn in naming discussions. However, there is no only a single place NetworkId is used and a request has been made to remove the separate NetworkIdType definition. Resolution of Issue: Minutes NSI-WG conf call 23 Jan 2013 - Remove superfluous NetworkIdType since there is now only one use of the type definition and include xsd:string directly in element. -- 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 74 in ogf-nsi-project: Make ServiceExceptionType variables optional in ogf_nsi_framework_types_v2_0.xsd
by ogf-nsi-project＠googlecode.com 07 Mar '13

07 Mar '13

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 74 by jmacau...(a)gmail.com: Make ServiceExceptionType variables optional in ogf_nsi_framework_types_v2_0.xsd http://code.google.com/p/ogf-nsi-project/issues/detail?id=74 Description of Issue: ServiceExceptionType includes a non-optional variables element which itself can contain zero or more variable instances. When no variables require specification the variables element is still required in current ogf_nsi_framework_types_v2_0.xsd definition. Resolution of Issue: Minutes NSI-WG conf call 23 Jan 2013 - Add a minOccurs="0" constraint on variables element in ogf_nsi_framework_types_v2_0.xsd definition. -- 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

Notification messages
by Tomohiro Kudoh 06 Mar '13

06 Mar '13

All, Attached is a slide deck including description of data plane related notifications. Tomohiro

1 0