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

OGF34 schedule is now available
by Guy Roberts 23 Feb '12

23 Feb '12

Hi All, The OGF34 schedule is now available here: https://www.ogf.org/gf/event_schedule/index.php?event_id=23 I look forward to seeing you in Oxford. Guy _____________________________________________________________________ ** 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

Wednesday's NSI conf call
by Guy Roberts 22 Feb '12

22 Feb '12

Hi all, The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: * Agree list of topics and NSI v2.0 functions to discuss in Oxford - agree agenda: https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aK… * State machine review. * Review open issues Guy _____________________________________________________________________ ** 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 _____________________________________________________________________

2 1

NMLify of AutoGOLE topology
by Freek Dijkstra 22 Feb '12

22 Feb '12

Hi all, I've tried to NML-ify the AutoGOLE topology. I did in RDF/XML because that is probably readable by both OWL and XML folks. Below are the steps I took in detail, along with intermediate results (which may help in understanding the differences). The main changes are: - made ports and link unidirectional, per NML specs. - use explicit link object to describe the SDP (NML has no connectedTo concept) - change the urn:ogf:network identifiers to a valid syntax, the ones currently in AutoGOLE use are not valid according to proposed standard nor previous use in either GLIF or perfSONAR community. The file AutoGOLE-Topo-2012-02-22.rdf gives the result so far. Notes: 1. The resulting topology file has three layers: - NML topology - dtox NSNetwork - dtox NSA I really like the clear distinction between the data plane (NML) and control plane (dtox/NSI). However, I wonder if we should move this to two layers, perhaps merging dtox:NSNetwork and nml:topology. 2. The dtox:hasSTP relation now points to a nml:bidirectionalport. NML defines a similar "hasPort" relation between a nml:Topology and nml:Port. (and there is some discussion to differentiate between hasOutboundPort and hasInboundPort). If dtox:NSNetwork and nml:topology are merged, I recommend to use these relations. 3. Yet unclear how exactly to tie Ethernet specifics to the examples, it seems prudent to use labels and the subnetwork concept as discussed in the NML-WG in Lyon (see subversion: https://forge.ogf.org/svn/repos/nml-examples/20110922/other_examples/config…; you need a gridforge login. Drop me a line if you can't access it.) Regards, Freek Dijkstra List of steps I took: Source: AutoGOLE-Topo-2012-01-25.owl Removed owl:NamedIndividual Removed schema definitions (owl:Ontology, owl:AnnotationProperty, etc.) Removed Position comments (used by auto-gole.appspot.com) Removed unnecessary comments Result: AutoGOLE-Topo-2012-01-25.rdf Changed dtox:lat, dtox:long and dtox:Location to geo84:lat, geo84:long and geo84:SpatialThing Corrected label of Netherlight location from Copenhagen to Amsterdam (geo84 was OK) Changed dtox:STP to nml:bidirectionalport Grouped ports of a single network in a nml:topology Commented dtox:connectedTo, since this is not valid NML Added rdfs:label to all NSA and all locations Changed admin contact from string to vCard Result: AutoGOLE-Topo-2012-02-20.rdf Change urn:ogf:network identifiers to valid syntax (urn:ogf:network:<FQDN>:<date>:<opaque>) Make all bidirectional ports unidirectional Explicitly defined NML links, with sources and sinks Result: AutoGOLE-Topo-2012-02-22.rdf Possible future direction: Merge NML:topology with dtox:NSNetwork Remove the dtox:managedBy property, as there is already an inverse relation dtox:managing to find the correct dtox:NSA Added switch matrix to each NML topology Define switching capabilities for each topology. use nml:hasPort instead of dtox:hasSTP Result: (the-AutoGOLE-future-is-yet-to-be-written.rdf)

1 0

new state machine
by Tomohiro Kudoh 18 Feb '12

18 Feb '12

Hi all, Here is a slide of a new state machine. Here, prov.cf/rel.cf does not mean data plane failure, but means confirmation of delivery of a prov/rel request to all the children. I am not sure how we can handle prov.fl (and rel.fl) messages. Since they are not related to data plane, they are almost fatal. Going back to the previous state may not make sense. (In most cases, such .fl message will not be sent back, but time out will happen). Tomohiro

2 5

NSI topology
by Freek Dijkstra 17 Feb '12

17 Feb '12

Hello Guy, Inder, Tomohiro, cc: NML and NSI groups Last week Roman Łapacz (PSNC) took Jeroen's AutoGOLE network description and turned it into an XML format. (Thanks Roman!) In that process, we discovered a few differences how AutoGOLE and NML describe a network model. The main differences are: * NML links and ports are unidirectional, AutoGOLE links are bidirectional * NML uses links and ports to describe network connections (a proposal to describe only links, not the ports was not followed up), AutoGOLE only describes the ports (the links are described as connectedTo between the ports, but have no identifier of their own) Of course there are some commonalities: * Both implementations focus on logical connections, not physical connections. * Both implementations have provisionings to ensure a layer of abstraction in case attributes of a link or port change (in NML: the identifiers are opaque strings and have no inherent attributes; in AutoGOLE and NSI: the distinction between SDP and STP) In yesterday's NML conference [1], we briefly discusses these differences and commonalities. Now, I do not know to what aspect the NSI working group is building on the AutoGOLE work, and what the current issues are. I don't want to interrupt the considerable progress the NSI group is making, and certainly don't want to get in the way of more great demos such as previous year's AutoGOLE demos by interrupting their implementation timelines. I think it would be good for the NML group to: - educate the NSI working group participants on these differences. - listen to the NSI group if there are any problems with the topology as we specified. I realise that the above may take some valuable resources of the NML working group, but I am dedicated to make sure our groups are aligned. My question to you (as NSI co-chairs) is if you think the above is useful, and if so, when we can best discuss this. Would it be useful to discuss this with the whole NSI group, or a subset? I propose that we dedicate a timeslot for this work, and am happy to use the NML break-out slot for this purpose (if you like it earlier, we can see if we can ask Joel to re-arrange some slots). We can also use a NSI or NML telephone call to discuss this. Part of that work means for NML-WG to provide example topology descriptions (which can be done within a few days). But also means making code contributions, which I don't think the NML-WG has the resources for on short term notice. What is your recommended way forward? Regards, Freek Dijkstra [1] http://www.ogf.org/pipermail/nml-wg/2012-February/000815.html

1 0

Agenda for NSI workshop in Oxford
by Guy Roberts 17 Feb '12

17 Feb '12

Hello All, I have created a template to help us prepare an agenda for our face-to-face meeting in Oxford, this is available here on google docs: https://docs.google.com/document/d/1y0a3X66qAoXRaXyDxGy-xiL_aIfidVaIJP1-_aK… Could everyone please take a look and add any topics that you would like to discuss relating to v2.0 issues? This agenda will be reviewed on the next NSI call. Guy _____________________________________________________________________ ** 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

Issue 57 in ogf-nsi-project: should we define an NSI-UNI?
by ogf-nsi-project＠googlecode.com 16 Feb '12

16 Feb '12

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.1 FixedInVersion-2.0 New issue 57 by guy.robe...(a)gmail.com: should we define an NSI-UNI? http://code.google.com/p/ogf-nsi-project/issues/detail?id=57 Description of Issue: The NSI WSDL has become complex leading to the observation that application developers are likely to be discouraged from implementing NSI apps. Also, current NSI design is not firewall friendly. A possible solution to this would be to define a simplified NSI to be used as a UNI. Discussion of Issue: John MacAuley has proposed the following solution: Define a simplified client-specific NSI-CS protocol interface (UNI) o A simplified subset of the existing NSI-CS capabilities. o Firewall safe. This interface should use current best practices for client API development: o RESTful definition. o JSON/XML data representations. o Useable from web-based clients. Resolution of Issue:

1 0

minutes from today's NSI conf call
by Guy Roberts 16 Feb '12

16 Feb '12

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

Wednesday's NSI conf call
by Guy Roberts 15 Feb '12

15 Feb '12

Hi all, The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Please let me know if you have any items that you would like to have added to the call agenda. Guy _____________________________________________________________________ ** 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 _____________________________________________________________________

2 1

Call Tomorrow and Agenda
by Inder Monga 09 Feb '12

09 Feb '12

Hi all, The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: 1. Firewall issues: John Macauley 2. Error Handling: Henrik 3. Other topics Thanks Inder Henrik's email attached: -- 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. -- -- Inder Monga 510-486-6531 http://www.es.net Follow us on Twitter: ESnetUpdates/Twitter <http://bit.ly/bisCAd> Visit our blog: ESnetUpdates Blog <http://bit.ly/9lSTO3><http://bit.ly/d2Olql>

3 3