December 2011 - Nsi-wg - lists.ogf.org

today's NSI call
by Guy Roberts 14 Dec '11

14 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: * NSI topology * Time and location of NSI face-to-face meeting in February * 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 _____________________________________________________________________

1 0

GLIF Performance Verification Task Force
by Jerry Sobieski 13 Dec '11

13 Dec '11

Hi all- I am glad to announce the GLIF Performance Verification Task Force is [finally] getting underway. The GLIF PV architectures task force was established at the September 2011 GLIF workshop in Rio de Janiero. The intent was to begin defining an architecture for performance verification and fault localization related to emerging light path services. This neccessarilly will include a host of related issues. The objective is a summary statement of recommendation on how such capabilities may be designed and deployed in emerging OLE and hybrid environments. --- Attached you will find the task force charter alluding to our purpose and direction. --- A mailing list has been created: *glif-pv(a)nordu.net* Interested individuals may subscribe in the normal listserve fashion, or you may go to http://listsrv.nordu.net/cgi-bin/wa?A0=GLIF-PV to register and subscribe. --- We will begin regular conference calls soon... We will allow folks a chance to subscribe to the list and then schedule the first call via the list. --- The co-chairs are Steve Wolff (Internet2) and Jerry Sobieski (NORDUnet). We look forward to the discussions! If you have any questions please feel free to contact me. Thanks! Jerry Jerry Sobieski Director, Int'l Research Initiatives NORDUnet Skype: jerry.sobieski Mobile: +1-301-346-1849 Email: jerry(a)nordu.net

1 0

Re: [Nsi-wg] Topology Abstract sent to Terena
by Jeroen van der Ham 13 Dec '11

13 Dec '11

Hello, I have the feeling this discussion is not going anywhere. We have been trading arguments for a couple of months now, and neither side seems to be moving. I have the feeling that it may be better to put this to the vote. Jeroen. On 11 Dec 2011, at 23:09, Jerry Sobieski wrote: > Hey Jeroen - I will try to make my discussion more succinct:-) > > On 12/11/11 12:36 PM, Jeroen van der Ham wrote: >> Hi, >> >> Jerry, please make shorter arguments. I think this is an important discussion, but I cannot dedicate all my time to reading your emails. Your point below could have been made a lot more succinctly. >> >> Mapping different labels and/or layers (VLANs in this case) to different network representations has been studied before.[1] It has the advantage of making pathfinding somewhat simpler, at the cost of generating those representations. There are two problems with it: >> - it makes the network representation a lot more complex, making it a lot harder to diagnose problems. > The topology *is* complex - simplification means topology hiding and delegation. Keep in mind we are not looking for an /optimal /path - we are simply looking for any _/acceptable/_ path, one that meets a set of specific constraints provided by the RA. _/Any/_ path will do as long as it meets those constraints. Thus, we can define network regions and perform the high level interdomain path selection based upon adjacency and segment Reservations. And then go to the NSAs along a candidate path to check the resources and reserve the segments. _/The external inter-domain PF does not need to know the details/_ - we let the local internal NSA (and ultimately the NRM) deal with those. The adaptations and multilayer incompatibilities are expressed in the topology by simple connectivity at a node. You have to do it somewhere. With the proper abstractions and architecture, it all will all come out in the wash. > > As for diagnosing "problems" - I am not concerned about large topologies. That is the price of admission. If you mean just debugging a large topology file itself...well, these will be autogenerated with tools or the NSAs themselves, and built up from smaller more local views, so I am not worried about generating correct topology. I am more concerned with insuring the topological model allows large topologies to be practical (!) We need to make sure the algebra of combining smaller more manageable topology files to create larger complex topologies in both scope and detail is provably correct. And that we can hide topology where necessary or desired for scaling, security, etc. - and things still work. > > We need NSI to define the canonical form of a "Connection" and "Service Termination Point", the "Network Service" node and a generic NSI Topology model. And let the technology specific aspects be handled by the NRMs or map themselves to NSI constructs. We can leverage principles of object oriented design to define generic topological objects that expose more topologically significant functions while hiding hardware specific details and which present common easily modeled nodal functions for external pathfinders. I look forward to this as it will allow us to encode network nodes that do encapsulation/decapsulation, stacking (virtual layer) functions, switching, muxing/demuxing, etc. > To do this, we have to start at the high level (inter-domain) and work our way down to more detailed nodes. Yes, the topology will get bigger - but how big is too big? I dunno - but we have a ways to go before its too large. And at what detail do we stop and say...hmm, lets just define an agent to check feasibility, availability, and allocation for this topological region. At the high level, it works using the NSA as the agent, the any-to-any (A2A) transit function for NSI Networks, and the atomic check-reserve semantic of the CS ReservationRequest. >> - you get multiple representations of the same link, which have an inter-dependency. You want to represent that the link can carry 10Gb, yet not all of the VLANs can carry 10Gb at the same time. > This is an example of shared resource dependencies. Bandwidth is only one example. Common ethernet per-box VLAN scoping is another example of a resource that is shared across multiple physical links, buffer management is often shared at blade levels rather than a single physical port, Shared Risk Link Groups (SRLG), and even more complex shared resources based on authorization limits is another. > So what you point out is true, but it is a much broader issue and not solved by simply dealing with VLANs on a physical port. Even with that one example, one could easily imagine a situation where some VLANs on a port are statically routed to one network, and other vlans on the same physical port go to a different real network. (We did this very thing at the FIA demos in October !). We need a more general approach to resource mapping. > > I think the way to represent these shared resources might be to have a "grouping" node that identifies a resource (say bandwidth) that is shared among members of that group. I have been trying to think this through... As we have the NSI Topology defined now, such sharing is magically handled by the NSA, its all done internal to the respective networks. > > Best regards! > Jerry >> >> Jeroen. >> >> [1]: Path selection in multi-layer networks, Fernando Kuipers, Freek Dijkstra: >> http://staff.science.uva.nl/~fdijkstr/publications/multilayer-pathselection… >> >> >> On 11 Dec 2011, at 17:55, Jerry Sobieski wrote: >> >>> Hi Jeroen- >>> >>> See attached slides... (just two simple slides) >>> >>> My point was that if you cannot ever swap between two particular endpoints (portx/vlan100 and porty/vlan101) then those two particular endpoints should not be advertised as being part a network service that says it can do "any to any" switching - it can't. If you advertise this cross-connect capability (as we do implicitly), then you entice and invite remote agents to take advantage of that capability - one which internally you knew all the time was never possible - ever. That seems dis-ingenuous to me at best, and malicious in some worst case. Why not just advertise 1000 Gbps capability as well? And this actually causes the "exhaustive search" problem. >>> >>> This does not mean that the remaining flat vlan switching capability is not important and useful. Take StarLight for instance, it had four convergent physical links: JGN,KRL,NL, and ESN. Each with the four VLANs. Even though SL could not swap VLAN IDs in the process of switching VLANs, it could still switch VLANs nontheless. So, A VLAN 100 from JGN could in fact switch to either of the other three destinations KRL/vlan100, NL/vlan100, or ESN/vlan100 but it all cases it retains the same VLAN 100. So a non-swapping switch still provides important conventional forwarding/crossconnect switching capability. As it was, by advertising SL as a single physical Network rather than four separate Network Services we created the problem of 75% of advertised routes were impossible. >>> >>> So we could have defined four VLAN planes SL80, SL81, SL82, SL83 -> each as a separate NSI Network, and each would have had four adjacencies. And those established and advertised adjacencies (SDPs) will have been mapped apriori to the associated VLANs in both adjacent networks. If the adjacent network is also "VLAN challenged" the dependencies would have already been expressed in their [internal] topology in a similar fashion as well. If those adjacent networks were label swapping, then all four endpoints SL80:PS80, SL81:PS81, etc would have converged on the same NSI Network as they do now...indicating that the adjacent network can route the circuit between STPs with different VLAN IDs. >>> >>> So in fact, just because a switch or a network cannot do VLAN swapping does not mean it cannot do switching - and there is still important value in this capability. By subdividing the challenged Networks into the appropriate VLAN planes, we express the very topological routing information you want. And it did not require any changes to the PFs in other networks - and it did not actually require knowledge of the particular VLANs labels or any physical technology information. >>> >>> One last point: The mingling of impossible cross-connects is externally indistinguishable from simple internal resource exhaustion. In terms of asking for a Reservation, if the route is impossible or if there is just not enough bandwidth, we still just get a reject. So the question is: If we run out of resources and some crossconnects become "highly improbable" (but not strictly impossible) should we revoke those advertisements on the same grounds that we don't advertise impossible crossconnects? Possibly...:-) How long time will the "improbable" cross connects remain "improbable"? If a cross connect is highly unlikely (e.g. Someone has reserved all 10 Gbps on a 10G path for 6 months...) is it misleading to continue advertsing it? This is where state updates become important and a grey area comes in... >>> >>> Hope this helps. >>> Jerry >>> >>> >>> On 12/10/11 2:16 PM, Jeroen van der Ham wrote: >>>> On 10 Dec 2011, at 20:13, Jeroen van der Ham wrote: >>>>>> <tirade> >>>>>> With respect to VLAN swapping... Inability to swap VLANs is essentially saying your NSI network cannot cross connect - ever - certain STPs. If you cannot *ever* cross connect certain STPs, there is no service! I might as well advertise STPs that point to bananas - I will never be able crossconnect them either but who cares? Advertising capabilities that can never be met is a Bad Thing. It injects false and misleading topological information - it could be considered malicious(!) >>>> Sorry, I'm calling bullshit on that one. >>>> >>>> In the Automated GOLE topology we currently have 0 networks that are able to do VLAN swapping. Netherlight does have that capability, but due to how things are connected, it is not available for the Automated GOLE topology. >>>> >>>> If we cannot even provide a connection service on an existing network, then we have no connection service. >>>> >>>> Jeroen. >>> <VLAN Planes.pptx>

3 4

minutes from today's NSI conf call....
by Guy Roberts 07 Dec '11

07 Dec '11

.... are available here: http://forge.gridforum.org/sf/go/doc16364?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

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