May 2011 - Nsi-wg - lists.ogf.org

nsaAddress semantics
by John MacAuley 10 May '11

10 May '11

Peoples, There was a proposal to use the nsaAddress field to hold the protocol specific endpoint. This would allow the removal of the "replyTo" field in the WSDL. I originally had concerns about the lack of endpoint decoupling of the confirm and failed messages from the request endpoint, however, I am over the concern now and do not see a reasonable reason for an NSA to need this decoupling. So if there are no concerns from the group, I would like to simplify things by removing the replyTo element and instead utilize the nsaAddress element. Comments? John.

1 0

minutes from today's NSI call
by Guy Roberts 08 May '11

08 May '11

The minutes from today's NSI call are available here: http://forge.gridforum.org/sf/go/doc16256?nav=1 _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

5 11

Forwarding to NSI group - from NML group
by Inder Monga 07 May '11

07 May '11

Please review the draft documents and send comments to Freek or NML mailing list. Inder > ------------------------------------------------------------------------ > > *From:* Freek Dijkstra <Freek.Dijkstra(a)sara.nl> > *Date:* May 7, 2011 1:44 PM > *To:* Network Markup Language Working Group <nml-wg(a)ogf.org> > *Subject:* [Nml-wg] urn:ogf:network specification > > > All, > > I finally written or updated three documents: > > 1. Delegation of urn:ogf to the OGF > 2. Procedure for registration of namespaces within urn:ogf > 3. Specification of urn:ogf:network (also attached) > > All documents can be found in the repository at > http://forge.ogf.org/svn/repos/urn-ogf-docs > > Only document #3 is in scope of the NML working group. > I welcome feedback for all documents though. > > Delegation of urn:ogf to the OGF > ================================ > See http://tools.ietf.org/html/draft-dijkstra-urn-ogf > > Please sent comment to me off-list or to the urn-nid(a)ietf.org mailing list. > > Procedure for registration of namespaces within urn:ogf > ======================================================= > See http://forge.ogf.org/sf/go/artf6478 > > Please leave comments at this artifact or sent them to me off-list. > > Specification of urn:ogf:network > ================================ > See http://forge.gridforum.org/sf/go/doc16260 > > Please sent comments to the NML-WG mailing list or sent them to me off-list. > > I certainly appreciate feedback on the following two issues. > > Compatibility with GLIF and perfSONAR usage > ------------------------------------------- > > The current syntax is compatible with both current usage, although it is > now specified that recipients of a URN SHOULD NOT interpret the local > part. This is a change from the existing use. > > Also, the document specifies that the following two URNs are NOT lexical > equivalent. I have no opinion on this. Should this be equivalent or not? > - urn:ogf:network:example.net:path:2011-0418 > - urn:ogf:network:domain=example.net:path:2011-0418 > > International Characters > ------------------------ > > No international characters are allowed. I actually worked out a solid > schema (using RFC 5982 and NFKD normalisation that would allow quite a > few code points, but still have a very simple URN comparison -- no > decoding required.), but decided not to use it. > > I was finally convinced NOT to allow international characters by the > following comments on the urn(a)ietf.org list: > > If you allow people to assign URNs as they prefer, they always > tend to "invent" some semantic rules. > > At the end you have your database full of Identifiers like: > [institution]-[division]-[collection-name]-[date]-[item-number] > > This goes fine many years. > Till the day the collections are renamed or two divisions fusion > under another name or renaming of the institution or ... > > Experiences like those are the reason why many colleagues with > Long Term Archiving background propagate Identifiers without > semantics --meaningless strings just for machines. > > IMHO that is the problem and not if those meaningful-names written > in Kanji, Chinese, Arabic or Krill. > > Seriously I would allow ONLY numbers and 3-4 separator chars if I > could define a new generation ID system. That is NOT "restrictive" > but functional and problem free. > > (source: http://www.ietf.org/mail-archive/web/urn/current/msg01564.html) > > > Regards, > Freek > _______________________________________________ > nml-wg mailing list > nml-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/nml-wg

1 0

Comments on NSI CS WSDLs and XSD
by Chin Guok 04 May '11

04 May '11

Feedback on the NSI WSDL's: NSI Connection Interface WSDL ------------------------------------------- - The names of messages should be discussed. It is suggested that opposites be chosen to make the function of the messages more obvious for example Provision and Unprovision, Reserve and Unreserve, etc. In any case, before we finalize the 1.0 specification, some more thought needs to be put into the naming. - The replyTo in the NSI CS request message contains the callback SOAP address. Does it places constraint if the RA is behind a NAT'ed address? We may need implementation guidance on this scenario [there are multiple options like SOAP proxy, Broker etc.] - transaction ID: the soft guidance on the transaction ID does not help since if there is a possibility that the ID is not global, the software cannot take advantage of it if it is globally unique. The group should decide on one or the other i.e. either mandate it Global or do not provide any guidance (other than the fact that it should be locally unique). - Notification message for out of bound messaging from the PA to RA should be considered as a way for the network to notify the RA of exceptions. A Notify message with restrictions on CS Service oriented notifications only should be put in place as a general notification service is not yet defined, and may not be standardized for a while. NSI Connection Types XSD --------------------------------------- - Need to understand better the rationale between choosing the current format of NsiExceptionType as a concatenation string with variables. Wouldn't key/value pairs be more useful and easily allow interpretation at both ends through standardized key-value pairs? - nsaAddress should be defined. Can it be used as a callback URI? It will be nice to have it as the same format as the replyTo address above. - Bandwidth should not be mandatory. This is a connection service, bandwidth should be optional. - For the NSI Message Types, the ReserveType (for example), stands for both ReserveRequest and ReserveResponse. Should there be a ResponseType that is different? - Can names of the states as defined in ConnectionStateType be "normalized" to better reflect the messages, e.g. there is canceling, but terminated is used instead of canceled Thanks ESnet OSCARS developers

2 2

NSI call today?
by Radek Krzywania 04 May '11

04 May '11

Hi, Do we have a call today? Didn't see any notification from Guy recently. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

2 1

TNC2011 BoF "Provisioning infrastructure services on-demand (ISOD): beyond Grids and Clouds"
by Yuri Demchenko 02 May '11

02 May '11

Dear NSI/NML members, I thought that some people from NSI/NML will be interested to know about the TNC2011 BoF "Provisioning infrastructure services on-demand: beyond Grids and Clouds" (ISOD-BoF) that will held on Monday May 16th from 9:00-12:30 (two sessions with break). The BoF's goal is to present to the TERENA community developments in the area of on-demand infrastructure services provisioning that are currently going on in a number of projects, standardisation bodies, in particular OGF, and other international initiatives. Clouds are also positioned as on-demand services provisioning environment and discussion of the related activities on Cloud architecture and provisioning models development will also take place at the BoF. BoF description is available at https://tnc2011.terena.org/core/event/6 and appended below for your convenience. Agenda drafting is in the final stage. If you are interested to present your work at the BoF please contact me. We have a couple of slots available. Hope to see somebody of you at the BoF or during the conference. Regards, Yuri ----------------------------------------------- TNC2011 BoF - https://tnc2011.terena.org/core/event/6 9:00-12:30 Monday, May 16, 2011 Title: "Provisioning infrastructure services on-demand: beyond Grids and Clouds" Modern e-Science applications and high-technology industry regularly deal with large volumes of data that must be stored, processed and visualized. This requires dedicated high-speed network infrastructures, which can be provisioned on-demand to support all potential application scenarios. Most Grid/Cloud usage scenarios for collaboration can benefit from combined network and IT resources provisioning. This notion of provisioning an infrastructure on-demand not only improves performance, but also can address such issues as application-centric manageability, consistency of security services, and energy efficiency (which is emerging as a forefront issue). The infrastructure on-demand provisioning model requires that a number of services and resource management systems interoperate at different stages within the whole provisioning process. However, in current practice, different systems and provisioning stages are not connected into a single unified workflow what impedes the definition of a whole provisioning model. This results in a set of inconsistent, disjoint services that then require a significant amount of human intervention to manually integrate them into a single cohesive service. The problem of better supporting collaborative groups of people and wider user communities at all layers of networking and applications infrastructure remains unsolved. The BoF will try to look at future developments and future technologies to solve this problem. This BoF will provide a venue to discuss a wide spectrum of research and technology problems in provisioning infrastructure services on-demand, existing frameworks to support on-demand infrastructure services provisioning, and new emerging business models for infrastructure virtualisation, such as Cloud Infrastructure as a Service (IaaS). The BoF will host presentations from EU projects and activities such as GEANT3, GEYSERS, NOVI, OGF ISOD Research Group and facilitate information and experience dissemination and exchange with TERENA community.

1 0

NSI CS protocol v1.0
by Guy Roberts 02 May '11

02 May '11

This is a reminder that the NSI connection service protocol message primitive/attributes and associated state diagram are now stable and close to being fixed for v1.0. This is described in the attached documents: 1. NSI WSDL (includes Connection type, Connection service and Connection interface) 2. A sample service definition (in both .pdf and .xsd formats) 3. Service state-machines Note: these are not new version of these documents - all have been distributed separately in previous mailings, but are combined here for review purposes. As the v1.0 connection service is now being written up, this is your chance to provide feedback to the working group. . . so please take time to review these documents and send your comments to the list. A draft Connection Service Protocol document should become available for comment in the next few weeks. Regards, Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

2 1