October 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 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

Re: [Nsi-wg] Issue 17 in ogf-nsi-project: minn/Max bandwidth
by ogf-nsi-project＠googlecode.com 24 Jan '12

24 Jan '12

Comment #2 on issue 17 by jmacau...(a)gmail.com: minn/Max bandwidth http://code.google.com/p/ogf-nsi-project/issues/detail?id=17 At the moment we return a reservationInfo structure in the reserveConfirmed message to let the requesting NSA know which parameters were selected by the provider for the reservation. With min/desired/max bandwidth in the reserve request, where do we put the actually commited bandwidth rate? So we say it comes back in the desired fields, or should we define a new structure for this in the confirmed response?

1 3

Re: [Nsi-wg] Issue 34 in ogf-nsi-project: time zones - document usage
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Status: Started Labels: FixedWithUpdateR6 Comment #3 on issue 34 by jmacau...(a)gmail.com: time zones - document usage http://code.google.com/p/ogf-nsi-project/issues/detail?id=34 Changed times in the form xsd:DateTime to be a new simpleType called DateTimeType that restricts dates to have a timezone or Z. This was done in update r6. Guy will need to update the CS protocol documentation to reflect the restriction. ------------------------------------------------------------------------ r6 | jmacauley(a)gmail.com | 2011-10-14 17:03:57 -0400 (Fri, 14 Oct 2011) | 1 line Changed times in the form xsd:DateTime to be a new simpleType called DateTimeType that restricts dates to have a timezone or Z as requested in issue #34. closing issue #34. ------------------------------------------------------------------------

1 2

Re: [Nsi-wg] Issue 38 in ogf-nsi-project: push/pop attributes from SOAP layer - documenation
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Labels: -Type-Defect Type-Documentation Comment #6 on issue 38 by jmacau...(a)gmail.com: push/pop attributes from SOAP layer - documenation http://code.google.com/p/ogf-nsi-project/issues/detail?id=38 Changed this to a documentation update.

1 2

Re: [Nsi-wg] Issue 23 in ogf-nsi-project: "NsiExceptionType" change to "serviceException"
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Status: Fixed Labels: FixedWithUpdateR5 Comment #4 on issue 23 by jmacau...(a)gmail.com: "NsiExceptionType" change to "serviceException" http://code.google.com/p/ogf-nsi-project/issues/detail?id=23 Renamed NsiExceptionType to ServiceExceptionType as per issue #23. Closing issue #23. ------------------------------------------------------------------------ r5 | jmacauley(a)gmail.com | 2011-10-14 16:30:54 -0400 (Fri, 14 Oct 2011) | 1 line Renamed NsiExceptionType to ServiceExceptionType as per issue #23. Renamed messageId to errorId in ServiceExceptionType as per Issue 24. Renamed ServiceException element to ServiceException as per issue #27. Closing issues #23 and #27. Updating issue 24 ------------------------------------------------------------------------

1 2