January 2012 - Nsi-wg - lists.ogf.org

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 26 in ogf-nsi-project: UUID format for ConnectionId
by ogf-nsi-project＠googlecode.com 24 Jan '12

24 Jan '12

Comment #2 on issue 26 by guy.robe...(a)gmail.com: UUID format for ConnectionId http://code.google.com/p/ogf-nsi-project/issues/detail?id=26 Jerry: the discrepancy is not a problem, so everything stays unchanged.

1 3

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

AutoGOLE-Topo-2012-01-23.owl
by Jerry Sobieski 23 Jan '12

23 Jan '12

Hi all- Here is first new topo file for 2012: "autoGOLE-Topo-2012-01-23.owl" I will get it posted as a web doc shortly and then simply announce new versions, but for now here it is by email. (Previous base: SC11 v5F) Changes: - Updated NorthernLight csProvider endpoint to reflect TLS port. Jerry

1 0

NSI failure handling
by Henrik Thostrup Jensen 20 Jan '12

20 Jan '12

Hi everone I've finished up the first draft of the describing failure scenarios. I've tried to keep it fairly high-level instead of trying to obsess over all possible corner scenarios. The main contribution is a recommendation for semantics of the initial reply, and a clear division of responsibility between provider and requester, wrt. to changing connection state. It is likely that not everyone will agree with these, but at least we can get a discussion started, and trying to formalize things a bit (which is necessary if we want predictable failure handling). -- Failure scenarios and recovery for the NSI protocol version 1.0 and 1.1 == Introduction == The main focus will be on the control plane interaction, and how to deal with message loss, crashes, and how to recover from them. With the exception of the forcedEnd primitives, all NSI control plane message interactions happens like this: Requester NSA Provider NSA operation -> <- operation received ack <- operation result operation result ack -> The main idea between the separation of the operation and operation result is that they may be separated by a significant time, especially the provision operation which can be separated with several days or months between the operation and the result. For failure scenarios, the loss of any of the four messages should be considered along with crashes of one or both of the NSAs at any point in time. These failure scenarios can be generalized into the availability of an NSA, i.e., it does not matter if it is the network or NSA that is down, the distinction is if the NSA received the message or not. In general the problem is to ensure that the (intended) state of a connection is kept in sync. There are two significant problems in the current protocol: * No clear semantics for the operation received ack * No clear division of responsibility between requester and provider Both of these are semantic issues (i.e., behavior), and hence solving them should not require any changes for the wire-protocol. >From a theoretical point of view and assuming an asynchronous network model (note that async means something else in distributed systems than in networks) the problem is impossible to solve. Taking a slightly less pessimistic view (i.e., a partial synchronous network model), it becomes possible to recover some failures. Taking a pragmatic approach most errors are recoverable, given that the network and NSAs becomes functional at some point in time. == Control Plane Failure Scenarios & Recovery == The following will go through a range of failure scenarios, and describe how to recover from them. Note that some of the scenarios can be solved in multiple ways. I've taken the approach that it is the responsibility of the requester to ensure that the connection at the at the provider is in the required state. A: Requester NSA did not receive the operation received ack. Note: This failure is equivalent to not being able to dispatch the message (here there failure just occurs earlier). Note: If the operation result message is received within the timeout, this case can be ignored. Potential causes: Message loss, network outage, provider NSA is down If the requester NSA after a certain amount of time have not received the operation received ack it must assume that the connection cannot be created or the state change. This can be dealt with in multiple ways: 1. Do nothing (hope it comes up again) 2: An alternative circuit can be found. 3: Tear down the connection and send operation failure up the tree. Which strategy to choose here is policy dependent and is up the individual implementation and organization. OpenNSA currently does 3. For the sake of preventing stale connections, the requester can keep a list of "dead" connections. The status of these connections can then be checked at certain intervals via query and a control primitive for fixing the status send if needed. B: Provider NSA could not deliver the operation received ack This situation is a special case of scenario A, but seen from the provider point of view. Repeated delivery attempts can be tried, but this an only an incremental improvement/optimization and does affect the end result. The provider should not try and change the state of connection, besides the latest received primitive from the requester (do the least surprising thing). It is up to the requester to discover the current state (via query) and change it if needed. Since it is the responsibility of the requester to discover the state, there is no need for the provider to perform "reverse query". In fact, using the reverse query, for connection state update may cause more harm than good, as having the provider change the connection status automatically may not be what the provider wants (he might have compensated somehow) and does not follow the element of least surprise, and leaves the control of the connection at two parties. Alternatively, a "Hi, I'm alive; sorry for the downtime" primitive be introduced from provider to requester, which the requester can then use to fire off any controlling primitives. This is, however, just an optimization. C: Provider NSA could not deliver the operation result message This case should be handled as described in scenario B. D: Requester NSA did not receive the operation result message. This case should be handled as described in scenario A. E: Operation result ack was not received. This case should be handled as described in scenario B. == Data Plane Failure Scenarios & Recovery == Data plane failures are somewhat different from control plane failures. I am not well-versed in networking and NRMs, but will try to come up with a strategy: In general, I see two sorts of failures: 1. The failure is happening in my local domain. 2. The failure is happening outside my local domain. This might be an overly simplistic view of things. We assume that any fail-over, etc. have also failed, so the failure cannot be corrected (if it can be corrected quickly, it probably should). The further handling of a data plane failure will probably be policy dependent. For some users the network, might be completely unusable after a failure, where some would like to try and have it repaired. However trying to decide / figure out where and how this policy should be enforced is a rather tricky process, and probably out of scope of NSI for now. Instead I would suggest sending terminate messages downwards and forcedEnd upwards. Once this propagates to the initial requester a policy-correct action can be taken. I.e., convert a data-plane failure into a control-plane issue. == Recommendation / Action items == * Make the exact semantics of the operation received ack clear Recommendation: - The message has been received (duh) - The request is sane - The request has been serialized (crash safe). - The specified connection exists (for provision, release, terminate) - The request was authorized This has the following implication: - Once the operation received ack has been received by the requester, the connection should show up on a query result. If we cannot expect the connection to show after the receival, the primitive should be removed as it has no semantic value. - Failing early will save message exchanges and time. * Make it clear which of the NSAs has the responsibility for what Recommendation: - The provider is the authority for connection status (duh) - Keeping connection state synchronized is the responsibility of the requester This has the following implication: - Any (non-scheduled) connection state change must only be done at the initiative of the requester - The requester query interface is not needed. -- Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> NORDUnet

1 0

minutes from today's NSI conf call...
by Guy Roberts 18 Jan '12

18 Jan '12

... are available here: https://forge.ogf.org/sf/go/doc16375?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

Re: [Nsi-wg] Issue 33 in ogf-nsi-project: getting WSDL from servers
by ogf-nsi-project＠googlecode.com 18 Jan '12

18 Jan '12

Updates: Labels: -FixedInVersion-1.1 FixedInVersion-2.0 Comment #4 on issue 33 by guy.robe...(a)gmail.com: getting WSDL from servers http://code.google.com/p/ogf-nsi-project/issues/detail?id=33 GR: some question about real benefit of this - coding needed to to use WDSL TK: this is needed to be a real Web-service compliant solution. Resolution: re-visit in release 2.0

1 2

Re: [Nsi-wg] Issue 15 in ogf-nsi-project: XML/WSDL name spaces documentation needed
by ogf-nsi-project＠googlecode.com 18 Jan '12

18 Jan '12

Updates: Status: Started Comment #3 on issue 15 by guy.robe...(a)gmail.com: XML/WSDL name spaces documentation needed http://code.google.com/p/ogf-nsi-project/issues/detail?id=15 Henrik : please add examples of SOAP payloads so that it is possible for the coder to see what is required to be sent to aid the development of new implementations. John to provide Guy with examples for documentation purposes

1 2

Re: [Nsi-wg] Issue 31 in ogf-nsi-project: Namespace issues
by ogf-nsi-project＠googlecode.com 18 Jan '12

18 Jan '12

Updates: Status: Duplicate Mergedinto: 15 Comment #2 on issue 31 by guy.robe...(a)gmail.com: Namespace issues http://code.google.com/p/ogf-nsi-project/issues/detail?id=31 (No comment was entered for this change.)

1 0

Re: [Nsi-wg] Issue 18 in ogf-nsi-project: defect handling & timeouts need refinement
by ogf-nsi-project＠googlecode.com 18 Jan '12

18 Jan '12

Updates: Owner: thost...(a)gmail.com Labels: -FixedInVersion-1.1 FixedInVersion-2.0 Comment #2 on issue 18 by guy.robe...(a)gmail.com: defect handling & timeouts need refinement http://code.google.com/p/ogf-nsi-project/issues/detail?id=18 Assigned to Henrik to prepare a proposed solution to this issue. This is associated with issue #5. Also this is changed to a release 2.0 issue.

1 0