- Nsi-wg - lists.ogf.org

Issue 52 in ogf-nsi-project: time-out time - how to set timeouts
by ogf-nsi-project＠googlecode.com 07 Dec '11

07 Dec '11

Status: New Owner: guy.robe...(a)gmail.com Labels: Type-Review Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 52 by guy.robe...(a)gmail.com: time-out time - how to set timeouts http://code.google.com/p/ogf-nsi-project/issues/detail?id=52 Description of Issue: TK: how do we set time-outs? Discussion of Issue: JS: possible option is to add heart-beat message RHJ: does not recommend putting the onus on the user to determine time-out Henrik: no easy solution with current protocol design. Suggest that we could have policy on expected response times...? Jeroen: currently reservation requests can take around 1 minute and up to 2 minutes for provisioning. So we are often getting time-out issues in demo. JE: proposes using the existing query to check state. Radek: Need to add timer definition to the state machine to make this work Resolution of Issue: Some kind of exchange between RA and PA needed to find if PA is still processing request correctly. No clear resolution to this issue, needs further investigation

1 2

Issue 53 in ogf-nsi-project: confirmation messages for all state tranistions?
by ogf-nsi-project＠googlecode.com 07 Dec '11

07 Dec '11

Status: New Owner: ---- Labels: Type-Review Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 53 by guy.robe...(a)gmail.com: confirmation messages for all state tranistions? http://code.google.com/p/ogf-nsi-project/issues/detail?id=53 Description of Issue: Henrik: do we need a universal confirmation from PA to RA for all state transitions? Discussion of Issue: TK: could add a large burden of unnecessary messages? Resolution of Issue: The implications of the change needs to be reviewed.

1 3

Issue 48 in ogf-nsi-project: Addition of a Failed state into the state machine.
by ogf-nsi-project＠googlecode.com 07 Dec '11

07 Dec '11

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.Rio FixedInVersion-1.1 New 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 Description of Issue: There is no way within the existing NSI state machine to determine if a reservation in the "Terminated" state reached that state through a successful execution or through a failure. Discussion of Issue: For example, a reservation is modelled by a state machine once a reserve.rq is sent and the state machine transitions from the "Initial" to the "Reserving" state. If the reserve.rq fails the existing state machine transitions into "Cleaning" and then to a final rest state of "Terminated". Likewise, a successfully executed schedule reaches the final rest state of "Terminated". An observer using the query operation would not be able to distinguish the failed schedule from the successful schedule after the fact. It can be even more confusing in that one schedule may have failed do to a second schedule, but there is no way to tell which after they have completed. There are two possible solutions: 1. Add a new "Failed" state to the state machine. 2. Add an informational field to the state machine / reservation record that tracks the reason for transition into the "Terminated" state. We could model a successful schedule that reached endTime. A manual terminate. A forcedEnd received from a child or local NRM. A reservation failure (could store the ServiceException). I do not believe the argument that this is an OAM issue and needs to be solved separately is valid in this case. We need additional information. Resolution of Issue: I would recommend option #2.

1 1

Issue 42 in ogf-nsi-project: Query details and summary
by ogf-nsi-project＠googlecode.com 07 Dec '11

07 Dec '11

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 42 by thost...(a)gmail.com: Query details and summary http://code.google.com/p/ogf-nsi-project/issues/detail?id=42 I don't quite understand why we cannot just have one query mode, instead of the Summary and Details mode. Why not just have a single mode, which returns all the information? AFAICT none of the information requires a recursive query. Furthermore the current scheme actually prevents one from getting the current connection state and the list of children, which is rather unfortunate as that is exactly what I would like to have for the connection visualization tool. Is there any reason these two modes cannot be conslidated into one?

1 2

Topology Abstract sent to Terena
by Jeroen van der Ham 07 Dec '11

07 Dec '11

Hello, Jerry and I quickly slapped together the following abstract for Terena on Topology handling in NSI. I've attached it below. Jeroen. At two recent events, the GLIF meeting in Rio de Janeiro and SuperComputing11 in Seattle, many parties collaborated to create the first interoperable automated inter-domain circuit provisioning demonstration. The demonstration showed that seven different implementations could successfully communicate to exchange path reservations, queries and requests. In the demonstrations at GLIF and SC11 we have used a static centrally managed global topology description for a very small and very simple network. This description was expressed using a simple OWL[OWL] ontology. This ontology allowed domains to describe themselves, and express their edgeports, (the service destinations inside each network). The domain description also contained a description of the Network Service Agent responsible for that network domain, including its address, and perhaps most importantly – the adjacencies that existed between the networks. This information was minimally sufficient, but we learned – even from this very small pilot project – that a more powerful and automated topology model is critically important. Over ten different networks provided resources for this Automated GOLE testbed. The topology for this testbed was provided before the demonstration and remained static throughout. Several issues have been identified in this demonstration concerning topology handling: · Topology distribution · Path Selection and Allocation · Security and Trust Topology Distribution The central, static topology description for the fulfilled the needs of the demonstration, however in a practical application the topology will need to be distributed in a different manner. Domains must be able to define and advertise their own topology, which may be somewhat different than their actual physical infrastructure. The difference between the actual physical infrastructure inside a network, and the publicly advertised topology is important for scaling and summarizing purposes, and often perceived to be a security or privacy issue. The global scope and complexity dictates a distributed approach to topology discovery and exchange – which introduces concerns about coherency and convergence of topology information. Further, the form in which the topology information is passed around - the ontology and representation – is critical for common exchange and shared interpretation of the information contained in the topology. These issues are complex, but they are not intractable. The NSI WG is exploring these aspects and how the inter-relate to NSI Framework and protocol(s). Path Selection and Allocation Conventional switching technologies such as Ethernet or MPLS employ multiplexing of streams over underlying links by creating “labels” to identify packets belonging to particular flows. These labels could be a timeslot, a VLAN identifier, wavelengths, etc. When such labels cross network boundaries, NSI considers them to be abstract service stitching points for concatenating connections between adjacent network domains. Several important features of NSI are 1) its abstraction of “connections” to be technology agnostic pipes, 2) its introduction of “tree” mode path segmentation and reservation which separates of path selection and resource confirmation into remote and local functions respectively. On the other hand, given the current network technologies, the NSI protocol must be able to provision connections between ports using specific labels (e.g. VLANs, timeslots, wavelengths). We can either model these implicitly by mapping topologies, or explicitly in the topologies: • In the implicit case the connection abstraction does not recognize physical hardware features such as VLANs, Wavelengths, VCGs, etc . -- “labels” in a general sense – just inter-domain adjacencies. To NSI labels are part of the termination points, “endpoints” for circuits across each domain. And with tree mode path selection, NSI introduces the notion of remote pathfinding – where inter-domain path selection is done remotely by external agents but the path (resource) reservation is still done locally by each network along the selected path. This last point creates a serious quandary for the NSI topology description as it introduces a potentially very large search space for available transit points. • When modelled explicitly the label is described as part of the endpoint specification. This label can still be specified in a technology agnostic abstraction. The domain topologies will have to describe available labels on their ports. While this decreases the path search space, it does add the label dimension for pathfinding and messaging. These issues inter-relate in that they pose challenges not just for path finding, but impact the abstraction model and the protocol(s) as well. The NSI WG is must consider these aspects carefully in order to maintain the power of the technology agnostic abstractions and service models, while at the same time finding the appropriate topological representation and semantics that make for an efficient, generalized and scalable path finding process for both chain and tree mode connection handling. Security and Trust Creating a globally available network for circuit provisioning also raises security considerations. This has been a key requirement of NSI from day one and has been designed into the NSI service model and the CS protocol. Each and every service request is authorized at each network boundary, and communication between each network service agent is authenticated and similarly authorized. However, while the mechanisms are in place to pass security credentials among cooperating agents, the specifics of those credentials – how they apply to the service requested is more complex. This is the “security profile”. The roles of various entities requesting or providing services, the value or class of the information that may be exchanged in a service request or the function performed itself, and the local policies of each network must be considered and some minimal set of security profile agreed to in order for efficient inter-domain authorization to work reliably. These security concerns apply equally to topology exchange. It should not be possible, for instance, for attackers to disrupt operations by injecting malicious information into the system, while at the same time allowing legitimate agents to provide appropriate A comprehensive topology architecture will carry a wide array of information besides simple data plane connectivity...it may contain peering relations at the service plane, it may carry policy descriptions, it may contain varying amounts of state information. So the topology exchange process must be provably secure so that participating agents are authenticated, and the actual content of the expressed topology should be verifiable and “valid” in context of other known topology. Topology is key to pathfinding, and so being able to rely on the veracity and timeliness of the topology information – trust- is critical to a secure and reliable global inter-operability. These are just a few of the topics that must be considered for a comprehensive Distributed Topolgy Exchange architecture.

1 0

Wedesday's NSI call
by Guy Roberts 06 Dec '11

06 Dec '11

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: * Time and location of NSI face-to-face meeting in February * IT issues: Gridforge and Mailing list and GFD.173 problems * NSI topology * Other 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 _____________________________________________________________________

5 5

Minutes from today's NSI conf call
by Guy Roberts 04 Dec '11

04 Dec '11

Please find minutes of today's NSI conf call attached. _____________________________________________________________________ ** 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

NSI Interim Face-to-Face meeting
by Inder Monga 03 Dec '11

03 Dec '11

The demonstrations and progress on the protocol have been tremendous, thanks to your active participation. Now is the time to plan for the next steps, finish the standards specification, and tackle topology. In order to go over these detail oriented and/or contentious issues, we would like to organize a 3-day interim meeting where the NSI participants can get together and make focused progress. Please respond with your preferences below so we may choose the best possible week and location. If you have trouble viewing or submitting this form, you can fill it out online: https://docs.google.com/spreadsheet/viewform?formkey=dHZXZ01STk1CLWYyQ0UxSV… NSI Interim Face-to-Face meeting Please click on your preferred week * * Feb 6 - 9th * Feb 13 - 17 (overlaps with APAN meeting in Thailand) * Feb 20 - 24th * Feb 27 - March 2nd (ON*VECTOR likely at San Diego) * Mar 5 - 8th (Overlaps with OFC/NFOEC in LAX) * March 9 - 15 (Combine with OGF meeting in Oxford Please add your preferred location * Which place can you travel to? * Japan * Berkeley * Washington D.C. * Cambridge * Some other location! Please enter your comments If none of the above work for you, please suggest alternatives. Powered by Google Docs <http://docs.google.com> Report Abuse <https://docs.google.com/spreadsheet/reportabuse?formkey=dHZXZ01STk1CLWYyQ0U…> - Terms of Service <http://www.google.com/accounts/TOS> - Additional Terms <http://www.google.com/google-d-s/terms.html>

2 2

Capabilities of NSI Connection Service
by Jeroen van der Ham 01 Dec '11

01 Dec '11

Hello, I'm breaking our discussion out into two separate emails, because I would like to have some more participation in this particular issue. We need to identify the capabilities that NSI CS aims to have. On 1 Dec 2011, at 00:44, Jerry Sobieski wrote: > On 11/30/11 5:30 AM, Jeroen van der Ham wrote: >> Hello, >> >> I think it's most important to identify the requirements that we have for the topology, and work from there: >> >> - We need to have some distribution method for topology >> - This method must be maintainable for changes in the network, so it should allow updates. >> - It must be possible to request a connection from port A with VLAN X to port B with VLAN X. >> - It must be possible to request a connection from port A with VLAN X to port B with VLAN Y. > The first two I am in agreement with. The second two I will argue are not real requirements of topology - they reflect some conventional notions of traditional signaling protocols and assume specific technology. Try to remember that the objective of NSI is to build *connections* - not VLANs per se. In NSI we have an abstracted model of a "connection" as a conduit for transporting payload data between two endpoints. These connections simply ride atop the infrastructure whatever it is. So the VLAN itself is not critical to NSI. Note that I have specifically said that *NSI* must make it possible to do this. I did not say anything about the topology model, or the underlying service model. The current reality is that (my estimate) 95% of connections over the GLIF network are built on top of VLANs. Bandwidth on Demand in Internet2, ESnet, and SURFnet are based on VLANs. The other 5% consist of timeslots and wavelengths, which are basically labels that have to be coordinated between adjacent networks as well. If the NSI cannot support these kind of operations to begin with, we have a broken model and we will not get any adoption. > I assert the following: > - In an *ethernet* environment and traditional protocols you might expect this to be necessary, but its not a broad based requirement for NSI. We need to generalize the sentiment in order to keep the abstractions. > - We *can* reserve a connection from a specific port and VLAN by associating the switch, port, vlan etc with and STP. As long as the RA somehow maps the VLAN to the STP then the RA places that STP as the endpoint. Simple. The CS protocol can do this. > True, but this comes at a certain cost. We need to identify the models and their associated cost in order to make an informed decision. >> >> Nice to haves: >> - Dynamic availability information for both links and labels. > As stated above, unless you have this "availability" information for your labels (or *any* termination point), you will end up guessing at their availability - which means you still have not solved the exhaustive search problem. We cannot solve that problem since we are in a distributed environment. However, we can try to minimise its impact. >> Do we also want to include a connection from port A to port B where you don't care about the label? > This suggestion is not really a topology issue but a CS Protocol issue - it breaks the "specific endpoint" (point to point) semantics of the Connection request. Do you want a raw unlabeled connection? or a labeled connection but where you don't care which label? Will a stacked label be acceptable (e.g. QinQ)? What if the port is not a basic ethernet port, e.g. what if the port is a WDM port carrying many differnent colors each with different framing? What would you specify as the "endpoint" for a "Connection" request? If you don't care, then why can't the RA take the responsibility to simply select one regardless of the underlying labeling? And thus you leave it to the local NRM to engineer the connection internally to its network between the two *specific* endpoints requested by the RA. The easy answer here is to for the RA to not use tree segmentation at all but to specify a downstream endpoint and a chain request and let the local PF decide the local egress point. The requirements I mentioned above were meant to get a feel for what the NSI connection service is trying to accomplish. Topology and Protocol will have to go hand in hand to solve this problem. > - We also need a means of expressing basic abstract topological objects (e.g. nodes, ports, links, agents) that allows for recursive relational descriptions and maintains the strict technology agnostic abstractions NSI Framework requires, yet allows us to complement this basic ontology with enhanced detail - under local advertisement control of course. Remote PF implementations can leverage whatever detail is available to optimize the PF/Reservation process. Thoughts? Abstraction is fine. The current GLIF DToX model is already an abstraction of a domain topology. I would rather have that it contains the internal transfer function as well, since that makes it easier for inter-domain pathfinding. Jeroen.

1 0

Re: [Nsi-wg] NSI abstract at TNC'12
by Radek Krzywania 01 Dec '11

01 Dec '11

Hi all, In the attachment there is "final" version of the document, including all changes. We exceeded 1200 words limit by over 100 so I needed to cut some parts. The main change is the cut of the paragraphs on NSI agents (RA and PA), which did not bring much new to the abstract. I get down to 1199 :) I've already submitted this version just in case, but it is still possible to update it at any time before 5pm. So if anyone have some more comments - please speak now, or forever hold your peace. Again - authors please double check addresses and affiliations. And if someone has copies of two referenced documents, please check the references. 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 ________________________________________________________________________ > -----Original Message----- > From: Radek Krzywania [mailto:radek.krzywania@man.poznan.pl] > Sent: Wednesday, November 30, 2011 1:14 PM > To: nsi-wg(a)ogf.org > Subject: NSI abstract at TNC'12 > > Hi all, > So far so good :) We have almost final version of the abstract (see > attachment). I cleaned the document from track changes, and put last edits > from Jerry and John. Since we have 9 authors by now, I've put a table with all > of them to fit on one page. I will mark we want to put a full paper (if TNC will > accept the abstract), which has chanced to be published then in some > recognizable media, so there will be even more work but more space to get > into every (well, most) aspect of the NSI in details. > Authors - please verify affiliations, I took addresses from web pages! > I am still missing the references - ogf is still migrating and I can't access > gridforge! Does anyone have copies of architecture and NSI CS specifications? > I would appreciated the title and authors list ASAP. > I am now closing alone in a room to the final overall reading. This is the last call > for changes! The submittion deadline is 5pm but TNC servers are quite heavy > utilised at that time and someone can fail to submit ;) so further changes may > not be uploaded for evaluation. > > 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 > ____________________________________________________________ > ____________ >

1 1