August 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

Because you have all been asking for it...
by John MacAuley 19 Sep '12

19 Sep '12

I know the anticipation has been killing some people. So without further adieu, here is the new OGF NSI CS State Machine - The Skype Sessions v4. John

4 5

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 10 in ogf-nsi-project: How will data-plane failure be handled
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Updates: Owner: thost...(a)gmail.com Comment #3 on issue 10 by guy.robe...(a)gmail.com: How will data-plane failure be handled http://code.google.com/p/ogf-nsi-project/issues/detail?id=10 (No comment was entered for this change.)

1 1

Re: [Nsi-wg] Issue 11 in ogf-nsi-project: Explicit routing object in connection request
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Comment #2 on issue 11 by guy.robe...(a)gmail.com: Explicit routing object in connection request http://code.google.com/p/ogf-nsi-project/issues/detail?id=11 Pseudo EROs are supported by the original requestor NSA splitting the connection request into individual child requests (tree model) with explicit STPs. EROs for Network internal pathfinding is not currently supported. Chin: we have an LHC use case for Network internal EROs.

1 1

Re: [Nsi-wg] Issue 19 in ogf-nsi-project: technology specific attributes - how to use
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Updates: Owner: jeroen.v...(a)gmail.com Comment #2 on issue 19 by guy.robe...(a)gmail.com: technology specific attributes - how to use http://code.google.com/p/ogf-nsi-project/issues/detail?id=19 (No comment was entered for this change.)

1 2

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