November 2011 - 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

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

Re: [Nsi-wg] Issue 29 in ogf-nsi-project: clarify usage of providerNSA and requesterNSA
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Comment #5 on issue 29 by jmacau...(a)gmail.com: clarify usage of providerNSA and requesterNSA http://code.google.com/p/ogf-nsi-project/issues/detail?id=29 I missed the discussion so was this change to sendingNSA and receivingNSA approved? I am not sure it provides any additional value over the existing requesterNSA and providerNSA, which at least models the NSA relationship in the message exchange. Can I assume from the "Resolution of Issue" that I can put the NSA URN into the requesterNSA and providerNSA fields again?

1 2

Re: [Nsi-wg] Issue 9 in ogf-nsi-project: The current statemachine does not confirm provisioning until start-time
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Updates: Status: Started Owner: tkudoh...(a)gmail.com Comment #4 on issue 9 by guy.robe...(a)gmail.com: The current statemachine does not confirm provisioning until start-time http://code.google.com/p/ogf-nsi-project/issues/detail?id=9 Assigned to Tomohiroh Kudoh to investigate further

1 4

Re: [Nsi-wg] Issue 49 in ogf-nsi-project: Missing information in detailed query?
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Updates: Summary: Missing information in detailed query? Comment #1 on issue 49 by guy.robe...(a)gmail.com: Missing information in detailed query? http://code.google.com/p/ogf-nsi-project/issues/detail?id=49 The basic query does not walk-the-tree. The response to the detailed query should 'walk the tree'. The returned information should include both a full list of STPs and the ability to find the segment names of a connection. summary query will give the state of the aggregator. The detailed query walk-the-tree to collect the state of all child PAs.

1 7

Issue 54 in ogf-nsi-project: Make it possible to go from auto-provision to scheduled
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Status: Accepted Owner: ---- Labels: Type-Enhancement Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 54 by thost...(a)gmail.com: Make it possible to go from auto-provision to scheduled http://code.google.com/p/ogf-nsi-project/issues/detail?id=54 It is not possible to go from auto-provision to scheduled in the current state machine. In case of a failed provision call, it is impossible to "release" the other connections, making it impossible to keep the state between connections consistent. As some will be in auto-provisioned and other will be in scheduled. Ignore failures, it should also be possible for a connection to go into scheduled mode from auto-provision to say that the connection shouldn't be provisioned, but the resources should still be reserved. Resolution of Issue: Allow transistion from auto-provision to scheduled and have a release request move a connection from auto-provision to scheduled.

1 3

Re: [Nsi-wg] Issue 32 in ogf-nsi-project: Interface version discovery
by ogf-nsi-project＠googlecode.com 16 Sep '12

16 Sep '12

Comment #3 on issue 32 by guy.robe...(a)gmail.com: Interface version discovery http://code.google.com/p/ogf-nsi-project/issues/detail?id=32 John M. has some ideas ... John to write-up a proposal.

1 2

Re: [Nsi-wg] Issue 24 in ogf-nsi-project: ServiceException needs further details
by ogf-nsi-project＠googlecode.com 16 Sep '12

16 Sep '12

Comment #6 on issue 24 by imo...(a)gmail.com: ServiceException needs further details http://code.google.com/p/ogf-nsi-project/issues/detail?id=24 Discussion on the Wed call 1. rename messageId to errorId 2. Appendix captures a list of errorId values and their meanings 3. errorId and text are both fields that are included by the entity Inder

1 3

Re: [Nsi-wg] Issue 39 in ogf-nsi-project: STP syntax
by ogf-nsi-project＠googlecode.com 16 Sep '12

16 Sep '12

Comment #2 on issue 39 by jmacau...(a)gmail.com: STP syntax http://code.google.com/p/ogf-nsi-project/issues/detail?id=39 I am confused by this agreement. An STP is defined as a OGF URN that is composed of the NSnetwork and localId already. Is this asking me to break out the STP into two discrete elements?

1 4

Re: [Nsi-wg] Issue 16 in ogf-nsi-project: drop duration from WSDL/schema
by ogf-nsi-project＠googlecode.com 24 Jan '12

24 Jan '12

Comment #2 on issue 16 by jmacau...(a)gmail.com: drop duration from WSDL/schema http://code.google.com/p/ogf-nsi-project/issues/detail?id=16 My point of view: 1. OpenDRAC supports duration in the native WSDL interface and as well as in the Fenius interface. Both implementations translate duration into an endTime (endTime = startTime + duration). This directly mirrors our scheduling GUI interface, and can really be considered a convenience function for the end user (so they do not have to do math in their head). Given the NSI protocol will be hidden from the end user behind a programatic interface, there is no value in providing a duration capability in the NSI protocol as it is just as easy for the requesting application to perform the conversion of duration to endTime. 2. A suggestion was made that perhaps we could make duration be the length of service after the network resources have been provisioned. This would result in a variable schedule (endTime = startTime + provisionTime + duration) which is not feasible in a network where guaranteed reservations times are being supported. We would never be able to accurately predict the true endTime that would allow us to guarantee the next startTime. Based on these two points I recommend removing the duration element from schedule.

1 2