- Nsi-wg - lists.ogf.org

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

Minutes from today's NSI conf call
by Guy Roberts 27 Apr '11

27 Apr '11

.... are available here: http://forge.gridforum.org/sf/go/doc16257?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 _____________________________________________________________________

1 0

FW: NSI-CS initial SD for Ethernet transport
by Guy Roberts 27 Apr '11

27 Apr '11

This SD looks pretty good to me - would this be ok to use as an example for NSI v1.0? Guy -----Original Message----- From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Jerry Sobieski Sent: 11 April 2011 03:24 To: nsi-wg(a)ogf.org Subject: [Nsi-wg] NSI-CS initial SD for Ethernet transport Hi Guy- I have given up for now trying to generalize a Service Definition schema. XSDs just don't provide the indirection we need for this...so I am punting on the generic SD schema for now. Instead, I have opted for an example Service Definition for an Ethernet Transport Service. The workings are the same - its just that now whoever defines the service deployment will also need to know how to edit this XSD. So be it...(for now). We may not need even the XSD if we can effectively document what an XML service definition should look like. Oh well...This will work for v1.0 Attached is the latest version of the Ethernet Transport Service service definition. Also attached is a autogenerated PDF of the same SD. The generic SD has two basic parts: the Name, and the Attirbute List. If all would look this through... The important issues that need inspecting are: --- Are the Service Attributes sufficient (what attributes are missing?) --- Are the Service Attributes defined correctly? (should the ranges be different? should defaults be differnet?... Please let me know. Jerry

1 0

today's NSI conf call
by Guy Roberts 27 Apr '11

27 Apr '11

Hi all, The following is dial-in information for tomorrow's NSI call: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 23: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 "#" 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 _____________________________________________________________________

1 0

STP
by Tomohiro Kudoh 20 Apr '11

20 Apr '11

Hi all, Here is my idea on STP. Tomohiro

1 0

today's NSI Conf call
by Guy Roberts 20 Apr '11

20 Apr '11

Hi all, The following is dial-in information for tomorrow's NSI call: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 23: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 "#" 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 _____________________________________________________________________

1 0

Some NSI topics...
by Jerry Sobieski 20 Apr '11

20 Apr '11

Hi Inder and all- I've been thinking hard on these topics below. I am still unsure as to the correctness of some of our decisions here, but I will concede several of these in order to move v1.0 forward. - underspec'd endpoints IMO: This is workable concept and very promising and I like it - but requires a considerable discussion regarding topology and endpoint semantics that we have not had yet and that will take a while to work out. I think the breadth (and power) of this concept will surprise us, so I want to do it well. So my recommendation is that we do not do something now that prevents this, but we should not try to work this out in V1.0 - this is a new feature. For v1.0, leave the endpoint to be an endpoint. I think a lot of this issue will be worked out relatively easily in conjunction with NSI topology. The CS protocol does not *need* this to be fully functional and entirely workable. ( The concerns that have been voiced are actually topology and pathfinding issues - and I think we can resolve these better and more completely in the ensuing topology discussion.) - NSA and NSI Network name equivalence I will concede this issue. I still am not certain this is the correct course to take, but since we *do* use the NSA and Network interchangeably so often, perhaps we will not run afoul of their differences. I would ask that we keep this issue in mind and if we find a compelling aspect that dictates these be separated, that we reconsider the issue. But lets assume for v1.0 that the "NSI Network name" and the "NSA_ID" are the same object. - NSA indirection I think we agree that the NSA_ID==Network Name. But the contact information for the NSA/Network is not encoded in the name itself. The NSA contact info is *associated* with the network name but requires one level of indirection (a look up) to go from <name> to <contact info>. - Network name: Opaque string or URN? IMO: Opaque string. For now. I am certain that we will have more specific requirements when we get to NSI topology and/or pathfinding discussions. If those discussions benefit from or require a specific format, I will go willingly:-) But for now, /NSI-CS/ only requires the Network name to be unique so that endpoints are uniquely mapped to one and only one NSA. The NSI-CS requirement is only uniqueness, so lets not impose more - particularly when we have other undefined protocols that may have some requirements as well. Since we do not know of other uses of the Network name, we should leave it as unspecified as possible. It is sufficient for NSI-CS to say "The Network name is assumed to be a string that uniquely identifies a single particular NSI network." Thats all we need. (This allows URNs, DNS names, ISBN numbers, ... as long as it uniquely identifies a single NSI network.) If the group does insist on specific format(s) e.g. URN, I will accept it. But then we must also specify the registry. And we should also specify how NSI verifies the name is conformant to the required format(s) since it is explicitly necessary that Network Names have those formats. - NSA/Network ID authentication We have not addressed this, but this may be necessary to insure no two NSAs claim the same [unique] network name. This goes to some of my reservations about URNs and network names - a unique name does not prevent two agents from using it. How do we insure a network name is unique - and in what context (topology representation? trust extablishment? etc.) I think this is a topology discussion. But that we will need to define a mechanism that allows an NSA to authenticate a remote NSA as the authoritative NSA for the associated network. Which implies a linkage beween the Network name and the authorization credentials. Has anyone explicitly considered this as part of the trust establishment? Does this go far enough? - simple user NSAs We do not have resolution on how a simple user RA should identify itself. Since this simple user RA has no network, what network name should it use as its NSA_ID in its messaging? Since the user NSA has no network, it has then no endpoints, and the endpoints in the request are therefore not in its "network"...therefore, no uniqueness is required unless some far remote NSA needs to contact it...Since the simple User RA has no trust with any other NSA, this seems unlikely to happen. So can we use a non-unique network name? Can we ask the PA to assign a "local Network name" to be used for this connection? Without resolving this issue, all simple user NSAs will need to acquire a globally unique network name in order to particiapte in NSI. If we could allow simple users without networks to avaod registering a unique network name, it would make it far simpler for adoption...and I don't think it would be difficult to do this or break/change the rest of the protocol. Thoughts? I hope this helps. Jerry

2 1

Some thoughts on STP
by Inder Monga 14 Apr '11

14 Apr '11

This document is not as comprehensive as I would have liked, but I wanted to put on paper some of the rationale for the discussion that came up last week and has been discussed privately with Jerry over skype. Thanks, Inder -- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3> Facebook: ESnetUpdates/Facebook <http://bit.ly/d2Olql>

3 2

Network names and authentication scaling
by Jerry Sobieski 14 Apr '11

14 Apr '11

Hi all- An issue occurs to me: First... Given that each Network has exactly one NSA, then the implication is that no two different NSAs can claim to represent/be the same network. Since our discussion today decided that the Network Name (used in tuples) and the NSA_ID (used in messages) were identical, it follows then that every NSA RA requesting a connection must be identified by an NSA_ID that being a Network name also must be globally unique. Even simple user codes just requesting an adhoc connection become RAs by definition...and therefore are required to get a globally unique NSAID. For simple user requests, this seems onerous...is this really necessary? The Network names definitely need to be globally unique as they are part of a global topology model. And by implication the NSAs representing those networks should be uniquely addressible (though I contend they need/ought not be defined as the same thing). The the CS protocol, however, only talks between PA and RA. There is no inherent global scope in this relationship, and as we concluded in Hong Kong, this relationship only needs to be locally unique. I believe it would significantly simplify user codes if user RAs could dispense with constructing a verifyably global unique NSA_IDs, and simply ask the PA to respond with a locally unique NSAID that will work for the life of this connection conversation. Second, what if an "NSA" deliberately hijacks an established Network name [NSA-ID]? How do we insure this does not occur? How do we authenticate an NSA as being the proper agent to represents a specific [real] network domain? Thoughts? (I know we have authenticated sessions between trusted NSAs, but that doesn't in itself associate a network with an NSA...or more accurately, it doesn't preclude that agent from acting as another Network.) I think we need some specific language on this... Regards Jerry

2 1