- Nsi-wg - lists.ogf.org

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

summary of Ad-hoc NSI f2f meeting at Joint Tech 2012 Winter:
by Tomohiro Kudoh 01 Feb '12

01 Feb '12

Ad-hoc NSI f2f meeting at Joint Tech 2012 Winter: Present: Chin Guok Hans Trompert Jeroen van der Ham Jerry Sobieski John MacAuley Tom Lehman Tomohiro Kudoh Xi Yang There was consensus on the following: 1. An STP can have 0 or more <type,value> tuples => STP (<network_id>, <local_id>, <type_1,value_1>, .. , <type_n,value_n>) - e.g. STP (NetA, EndPt1, port, 1000, vlan, 123) - open question on how tuples can relate to one another, e.g. port 1-4 have vlans 1-4 The STP specification incorporating the <type,value> tuples is still just a STP *identifier*. I.e. this in itself does not imply that these values are in any way related to specific technology or hardware features. On the other hand, <type,value> tuples can be used to define capabilities. The capabilities can describe technology, hardware, policy, or other limitations. The value of the "type" string is not defined as part of the NSI CS standard, i.e. it is defined as part of the service definition. The NSI CS standard only codifies the presence of <type,value> pairs as part of the STP identifiers. It is up to the provider (PA) to define them. However, we do expect that there will be a best-practices document describing some <type,value> combinations and capabilities. 2. The <value> filled can be an individual value or a range - if a <value> is a range then it is a "STP_Bundle" I.e., these tuples may also be used to specify constraints that identify a set of STPs. 3. Open question on how we can describe constrains for STPs, e.g. STP (NetA, EndPt1, <port, $1>, <vlan, $2>) STP (NetA, EndPt1, <port, $3>, <vlan, $4>) Capabilities: $1 != $3, $2 = $4 => no vlan translation 4. Open question on how we can describe and bundle SDP

1 0

NSI paper acceptance @ TNC'12
by Radek Krzywania 27 Jan '12

27 Jan '12

Dear all, I am happy to announce that the Network Service Interface paper that many of you contributed to was accepted by TNC'12 Programme Committee. The presentation should take place on Mon 21st May in session starting at 4pm. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

7 7

3 NSI sessions at OGF34
by Guy Roberts 26 Jan '12

26 Jan '12

Hi All, I have requested 3 NSI sessions at OGF34 in Oxford. I have proposed either Monday afternoon or Tuesday morning as preferred times for these sessions. The NSI v2.0 workshop will be held on Wed-Fri. Please let me know if you would like me to change the session times preferences. Also, don't forget to register.... Guy From: wg-all-bounces(a)ogf.org [mailto:wg-all-bounces@ogf.org] On Behalf Of Alan Sill Sent: 26 January 2012 16:49 To: OGF Work Groups Subject: [wg-all] REMINDER: Call for session proposals due Jan. 29; early bird / regular registration deadlines for OGF 34 Dear OGF community, This is a reminder that the Call for Session Proposals<http://www.ogf.org/OGF34/cfp.php> for OGF 34, to take place March 12-15, 2012 at Oxford, is open at the link below http://www.ogf.org/OGF34/cfp.php In addition, Registration<http://www.ogf.org/OGF34/registration.php> is open also with the following schedule for early, regular and on-site or late registrations: http://www.ogf.org/OGF34/registration.php OGF34 Event Registration Costs: Advance Registration (until February 18, 2012) Member Fee Non-Member Fee Full Conference $395 $495 One Day $195 $245 Student $275 $275 Full Registration (February 19 - March 8, 2012) Member Fee Non-Member Fee Full Conference $495 $595 One Day $245 $295 Student $325 $325 On-Site Registration (March 9 - March 15, 2012) Member Fee Non-Member Fee Full Conference $595 $695 One Day $295 $345 Student $375 $375 Note that all costs are in US Dollars. See the above page for further details. We have already received several requests for special sessions, which are being coordinated by Joel Replogle and our host for this event and VP for Community, David Wallom. We look forward to full and active participation by our community and encourage you to submit your session requests as stated by January 29, 2012 using the link above. Thanks. Alan Sill, Ph.D Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Drane 162, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu<mailto:Alan.Sill@ttu.edu> ph. 806-834-5940 fax 806-834-4358 : ==================================================================== Alan Sill, Ph.D Senior Scientist, High Performance Computing Center Adjunct Professor of Physics, TTU Vice President of Standards, Open Grid Forum ==================================================================== : Alan Sill, Texas Tech University Office: Drane 162, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu<mailto:Alan.Sill@ttu.edu> ph. 806-834-5940 fax 806-834-4358 : ====================================================================

1 0

AutoGOLE Topology 2012-01-25
by Jerry Sobieski 25 Jan '12

25 Jan '12

Hi all- New topology file... - corrected the csProvider Endpoint for NortherbLight to reflect HTTPS Jerry

1 0

no NSI conf call this week
by Guy Roberts 24 Jan '12

24 Jan '12

Due to the attendance of many NSI participants at the Joint Techs meeting in Baton Rouge, there will be no NSI conf call this week. 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

NSI WSDL version 1.1
by John MacAuley 24 Jan '12

24 Jan '12

Peoples, I am making changes to the WSDL this week to close some of the open issues for version 1.1. I would also like to restructure the message definition to simplify the handling code we have written. There was a lot of feedback that the XML definition forced coders to write duplicate code to handle common attributes. This restructuring would clean up the compiled objects so there would be less duplication of code. My proposed changes would not modify the contents or behaviour of the messages, just restructure them a bit to pull out the common attributes into dedicated named structures. I have two possible approaches to this problem: 1. Place the common attributes into the SOAP header and place the operation specific data into the SOAP body. This would be more in line with the intended protocol structure. Common framework header parameters in the SOAP header, and NSI CS operation specific data in the body. 2. Continue to just use the SOAP body and restructure the message definition so that the WSDL compiler generates common code for the common NSI parameters, which will be included in the operation specific XML type. Does anyone have issues accessing data in the SOAP header? Delayed at the airport for 4 hours :-/ Thanks, John.

2 1

Re: [Nsi-wg] Issue 48 in ogf-nsi-project: Addition of a Failed state into the state machine.
by ogf-nsi-project＠googlecode.com 24 Jan '12

24 Jan '12

Comment #4 on issue 48 by jmacau...(a)gmail.com: Addition of a Failed state into the state machine. http://code.google.com/p/ogf-nsi-project/issues/detail?id=48 Add a reason field to the terminated state returned in a query so we can determine the reason for a reservation reaching the terminated state. For example, the reservation is in a terminated due to a schedule end, canceled message, forced_end event, failure.

1 1

Issue 49: Missing information in detailed query?
by John MacAuley 24 Jan '12

24 Jan '12

All, I investigated the current data returned by the query operation. The QuerySummaryResultType contains the overall connection state as viewed by the NSA being queried. It also contains a PathList that provides a summary of the STPs. This may be a pair of STP associated with the connection, or a more detailed path list of STP. However, it does not contain information about the children NSA involved in this connection. To get the detailed path information you must issue a recursive query to get a QueryDetailsResultType back with the detailed list of NSA involved in the request tree. Is it desirable to modify the QuerySummaryResultType to return the list of immediate children to the queried NSA involved in the connection reservation? Thanks, John.

1 0