October 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

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

First draft of NML Schema document
by Jeroen van der Ham 04 Nov '12

04 Nov '12

Hello all, It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1". Please have a look through it and let us/me know what you think about this document. With the feedback we get, we will improve the document and we plan to finally start the process on this document next month. Thanks! Jeroen.

2 1

SC demos
by Jerry Sobieski 03 Nov '12

03 Nov '12

Hi all- Things have been very disorganized the last few weeks regarding the demos. I have been distracted on some other issues and am sorry about this. But this is the situation: The NSI version2 implementations are not all ready. And some key GOLEs will only have V1 available, or will not be able to perform aggregation functions,... and the status monitors will also need to be able to deal with two versions... And no doubt there will be some technical issues we'll need to iron out as we implement and test... so I think a comprehensive NSIv2 over the Automated GOLE fabric is going to have to be re-thought... I think it is just not realistic to have the AutomatedGOLE running V2 everywhere, and even more unlikely we would be able to have them both *interoperating* at this time. However... all is not lost... We should keep in mind that what we want to demonstrate and promote at SC is *_/*NSI*/__/*and [automated] GOLEs*/_* - not specifically v2 per se, although it would be nice. But our priority should be to demonstrate and promote a _/global NSI as the ubiquitous protocol/_...with many implementations, and its features where they are ready. Remember, many of the folks at SC have only just heard of NSI and need basic high level vision, status, and roadmap - not details about state machines or topologies, or even I suspect will they need to see a Modify() primitive actually work:-) Besides, the differences between v1 and v2 are largely internal advances and do not much present new capabilities to the end user. So if we keep this Big Picture perspective for SC12, I think we can still have a very powerful NSI + AutoGOLE demonstration despite the varying degrees of readiness for v2... ---> NSI as the common ubiquitous automated provisioning framework/protocol, and ---> Open Lightpath Exchanges (and "distributed" exchanges) as the emerging global transport architecture, ---> And the AutomatedGOLE Fabric running NSI is an existence proof and test facility for early adopters. So I would like to propose we take the following tact for SC: - We leverage the NSI "service definition" concept.. We define "ets" services as v1, and we define a new set of service domains called "etsv2". - We preserve the AutoGOLE running NSIv1 as-is using vlans 1780-1783. THis will allow us to show NSI running using the status displays we have already working. - We establish a second "etsv2" service plane consisting of NSIv2 domains - these will get VLANs 1790-1799. - Even if the ETS and ETSv2 domains cannot interoperate at the protocol layer, they can still interconnect at the data plane layer. One domain would simply be the "static" client of another... For instance, we can have the ETSv2 domains act as end systems on the edge of a ETS (v1) domain, and we set up vlans across v1 to serve the v2 domain SDPs. THis is a tunneled strategy, but it would be interesting to show the capability none-the-less. THis would then allow both V1 and V2 provisioning demos to occur simultaneously. - or We could also/instead simply manually configure the 1790-99 VLANs across the AutoGOLE between the V2 domains. THis would also allow both V1 and V2 provisioning demos to occur simultaneously. - We define the topologies accordingly. This would allow us to have both versions running in parallel, even if they do not interoperate at the control plane. And frankly, its a good migration strategy to v2 in the AutoGOLE rather than a flag day. This allows those implementations that have v2 to demonstrate v2 albeit in a somewhat constrained manner... But We can still explain the development status and roadmap for the next several quarters. And we can still present the NSI capabilities and vision and active Workging Group... If the current Huricane sitting on top of me does not take me off the air, I will try to put a couple slides out to the lists to diagramtically explain this... Thoughts? Best regards Jerry

3 3

Issue 68 in ogf-nsi-project: Renumber Discovery Service and framework components to version 1.0
by ogf-nsi-project＠googlecode.com 01 Nov '12

01 Nov '12

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-2.0.Chicago FixedInVersion-2.0 New issue 68 by jmacau...(a)gmail.com: Renumber Discovery Service and framework components to version 1.0 http://code.google.com/p/ogf-nsi-project/issues/detail?id=68 We started number of new services at version 2.0 to line up with CS-v2.0 but it was decided at OGF 36 in Chicago to start all new services at version 1.0. As a result the numbering of these components will be changed to 1.0.

1 1

Need designer info
by John MacAuley 31 Oct '12

31 Oct '12

Can everyone participating in NSA implementations please send me their e-mail addresses and Skype ids? I am no longer trusting the working group e-mail for the next few weeks. Too many failures and message delay. Thank you, John

1 0

AutoGOLE + NSI demo at Supercomputing
by Jerry Sobieski 31 Oct '12

31 Oct '12

Here are some slides how I would like to set up the demos for NSI v2 and Automated GOLE. We can discuss on NSI call ... Jerry

5 6