December 2012 - Nsi-wg - lists.ogf.org

Re: [Nsi-wg] Issue 5 in ogf-nsi-project: Query on requester interface - is this needed?
by ogf-nsi-project＠googlecode.com 22 May '13

22 May '13

Comment #7 on issue 5 by imo...(a)gmail.com: Query on requester interface - is this needed? http://code.google.com/p/ogf-nsi-project/issues/detail?id=5 This discussion was not concluded, but I will capture the thoughts as were shared on the call: 1. Query as a separate WSDL was discussed, issue 22 has also been opened for this 2. The main use-case was monitoring or management agents that might not be NSAs. Unanswered questions are: a. Can query work if the entities querying are not NSA agents? b. Should query be a separate WSDL in any case? c. Which credentials - user credentials or peer relationships when walking the service tree? 3. There was support on the call for the need for query in both directions whether it be commercial networks or research networks scenario. This discussion was not deemed important for 1.0SC and resolution postponed till another date Inder

1 2

Issue 55 in ogf-nsi-project: correlationId is unneeded and complicates implementation significantly
by ogf-nsi-project＠googlecode.com 01 Apr '13

01 Apr '13

Status: Accepted Owner: ---- Labels: Type-Review Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 55 by thost...(a)gmail.com: correlationId is unneeded and complicates implementation significantly http://code.google.com/p/ogf-nsi-project/issues/detail?id=55 Description of Issue: The correlationId attribute in the WSDL messages is unneeded. Furthermore it requires correct implementations to persistently keep track of the correlationsIds of active requests. Discussion of Issue: The WSDL adds a correlationId to track the correspondence between a request and the subsequent update for the status. However this correspondence is unneeded as the request already contains information about the connection in question. However having the correlationId requires both the requester and provider to keep a persistent (as in on-disk) record of currently active requests, in order to be crash and restart safe, i.e., the service must be able to respond to requests that came before it crashed/restarted. The correlationId also means that state updates are not idempotent as the client can only receive a request (state update) once. However it cannot be guaranties that a message with a state update will only be send once due to the coordination of message dispatching and updating this information persistently, where there will always be a window which can lead to inconsistency, where the message must be retransmitted. Having to keep track of requests in this way, is called a state-full protocol (note that this does not mean a non state-full protocol doesn't have any state), and is usually considered a bad idea do implementation complexity and poor scalability in high-performance systems (arguably this is not what we have though), as it makes load balancing and redundancy significantly more tricky. Furthermore it must be remembered that not all requests will have a callback. E.g., a provision before start time (i.e., auto-provision) followed by subsequent terminate request, will result in a callback for terminate, but not for the provision request. Here the client must then clear all pending correlationIds, complicating the implementation (the client side issues are simple though). All this is further complicated by the fact that we haven't established if it is the provider or requester which is responsible for ensuring that correct connection state is updated. Resolution of Issue: Remove correlationId from the WSDL. This will make the state update messages (reserveConfirmed, etc.) idempotent, meaning they can be repeated. The requester will then update any state references about the remote connection to fit with the last received message (this also has problems, but none that doesn't exist in the current protocol).

1 3

Re: [Nsi-wg] Issue 41 in ogf-nsi-project: Do we replace the replyTo field with a topology/NSA configuration lookup?
by ogf-nsi-project＠googlecode.com 05 Mar '13

05 Mar '13

Comment #3 on issue 41 by takahiro...(a)gmail.com: Do we replace the replyTo field with a topology/NSA configuration lookup? http://code.google.com/p/ogf-nsi-project/issues/detail?id=41 I want to use the replyTo field. Currently, all NSA act as requester and provider. In this case, we are able to look up the csProviderEndpoint of requesters easily. However, in near future, some NSA act as only a requester, e.g. PerfSONAR and AutoEarth. It is difficult to describe and manage all requester endpoints as same as provider ones. Moreover, it causes a high barrier to publish new requesters. Therefore, a requester endpoint should be obtained using the replyTo field in the SOAP message payload.

1 7

Overly complex discovery WSDL
by Henrik Thostrup Jensen 04 Mar '13

04 Mar '13

Hi I've been looking at the discovery WSDL, and was a bit amazed with how complicated it turned up being. Now I have not been very active in NSI for the last couple of months, and have missed a couple of meeting, but I think we've ended up with something a lot more complex than what we discussed in Oxford and the mailing lists. For the request it looks like this: queryNsaRequest :: QueryNsaRequestType queryNsaRequest :: RequestType filter :: FilterType * nsaId :: NsaIdType * serviceType :: xsd:string * This is my own notation. Sorry if it is tricky to read. For the request it possibly to define summary of detailed request, but I haven't found any documentation on what should be returned for what. Secondly it is possible to have multiple filters, each specifying multiple nsaIds and serviceTypes. The parameters for each filter should be ORed, however there does not appear to be any documentation for how to deal with multiple filters. It also appears to be complete and utterly overkill as most NSAs will host 2 or 3 services. Now, for the response: queryNsaResponse :: QueryNsaResponseType discovery :: NsaDiscoveryType * # nsaId # softwareVersion # startTime # currentTime services :: ServicesType * service :: ServiceType #other :: any description :: xsd:string versions :: VersionsType * version :: VersionType # name # version # endpoint # wsdl # url # other :: any other :: any * capabilities :: CapabilitiesType * capability ft:TypeValuePairType # type :: xsd:string ! # targetNamespace :: xsd:anyURI value :: xsd:string * other :: any * Here we are dealing with a datastructure potentially 9 levels deep. Arguably, some of this is due to the ackward way XML/WSDL handles lists, but there are still 4 levels of nested lists. I won't go into any details here. I am not trying to do a witch-hunt on John here. In fact he may just have been listening to everyone, but what we ended up with here is pretty bad, and is in my opion very far from what we discussed in Oxford. I think we need to setup some review of WSDLs as well in order to ensure that these things do not spin out of control like this. Anyways, something to talk about tomorrow :-). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 3

Query request
by Jeroen van der Ham 15 Jan '13

15 Jan '13

Hi, While thinking about a demonstration scenario for SC, we came upon an interesting use-case for the query command. We are trying to plan workflows on the infrastructure, depending on availability. For that it would actually be useful to know not only if a certain resource is in use, but also when it could become available again. Would it be possible to add capabilities for the query command to provide something like that? Jeroen.

12 45

NSI tutorial in january
by Jerry Sobieski 14 Jan '13

14 Jan '13

Hi all- I want to propose a "hands on" NSI v2 tutorial for the Techs In Paradise (TIP) 2013 meeting in Honolulu in mid January. I want to present NSI overall as the primary focus of the tutorial (not just v2 features.). Of course this will include the framework, the protocol, some internals, tools, scripting, topology development, etc. We will use v2 as the base for exercises - v2 should be fairly well developed by then. I want to utilize the AutomatedGOLE Facility for the exercises. I would also expect this will include some NML material as well. As TIP will be attended primarily by network engineers, I will focus the tutorial primarily towards service engineering and deployment issues. This tutorial will incur a fair amount of organization and prep work (class sizes, program planning, exercise development and testing, etc) I would like to hear of anyone who would be interested in helping to develop and/or present this tutorial. But I don't think it will be a lot of work at the venue - we already have done some of these in smaller settings. I expect the tutorial to be at least 4 hours (half day) - perhaps a full day (6 hours) if we think we can not overwhelm attendees. Please let me know if you are interested in helping present such a tutorial or if you have ideas/suggestions for how we should frame it - and would be willing to sacrifice a day in Hawaii to teach folks about NSI:-) We have only a short time to get the proposal in, so let me know asap. Thanks Jerry

2 1

Tomorrow's NSI conf call
by Guy Roberts 18 Dec '12

18 Dec '12

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: - Update on message handling logic - Preparation of NSI CS documentation _____________________________________________________________________ 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

Some questions/remarks on the v2 connection wsdl
by Henrik Thostrup Jensen 13 Dec '12

13 Dec '12

Hi Found a couple of things in the v2 CS WSDL. Mostly minor stuff. The types: GlobalReservationIdType ( restriction base: xsd:anyURI ) ConnectionIdType ( restriction base: xsd:string ) NetworkIdType ( restriction base: xsd:anyURI ) Seems to just be aliases. Are there any reason for having them? The file ogf_nsi_connection_types_v2_0.xsd import saml, but does not appear to use it. I'm guessing this is just a leftover from when the security attributes was in the file. Not sure of the implications of removing this, but would be nice if we could avoid breakage. OTOH we will probably have to live with these things for a while, and will probably not get another chance to fix it. Questions: Why do we need protocol version in Header? Isn't this already contained in SOAP action? Do we really need a file ( ogf_nsi_framework_headers_v2_0.xsd ) for one type? Not really important, just seemed like overkill. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

6 19

minutes from today's NSI call....
by Guy Roberts 12 Dec '12

12 Dec '12

... available here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6528 _____________________________________________________________________ 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

Error code and serviceException
by Henrik Thostrup Jensen 12 Dec '12

12 Dec '12

Hi everyone I was doing some error handling stuff in OpenNSA and realized that we probably didn't close that one properly after Oxford. These are also pretty important to get into an appendix in the standard, so we can do proper error handling in the imeplementations. Here are the error code that I presented in Oxford: PAYLOAD_ERROR 00100 MISSING_PARAMETER 00101 NOT_IMPLEMENTED 00102 CONNECTION_ERROR 00200 INVALID_TRANSITION 00201 CONNECTION_EXISTS 00202 CONNECTION_NONEXISTENT 00203 CONNECTION_GONE 00204 SECURITY_ERROR 00300 UNAUTHORIZED 00301 TOPOLOGY_ERROR 00400 UNKNOWN_STP 00401 STP_RESOLUTION_ERROR 00402 NO_PATH_FOUND 00403 INTERNAL_ERROR 00500 INTERNAL_NRM_ERROR 00501 RESOURCE_UNAVAILABLE 00600 STP_UNAVALABLE 00601 BANDWIDTH_UNAVAILABLE 00602 I _think_ we agreed to them without to much fuzz. The idea is that we can add new errors without changing the protocol and that a new resource unavailable code (say 00603, can be generalized into 00600 if the implementation does not know 00603). I think we also need a failure to indicate that a connection could not be created due to a downstream NSA being unavailable or similar. I cannot think of a good name though, but it belongs under 00200 / CONNECTION_ERROR. Maybe CONNECTION_CREATE_ERROR / 00205. Note that it is the error codes (the numbers) that should be specified in the errorId field in the nsi:serviceException. The names should not be transmitted. Previously some have used 'SVC' as a prefix to the error codes (to indicate service failure), but I am not sure if we agreed on anything for NSI2 (I don't see the need @John: Maybe you could put the error codes in the WSDL documentation. Finally, right now, variables is mandatory in nsi:serviceException, however not all errors need to be related to a variable (downstream NSA unavailable), so I suggest we make variables optional. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

3 2