- Nsi-wg - lists.ogf.org

Topology Use-Case
by Jeroen van der Ham 21 Dec '11

21 Dec '11

Hello, One of my action points for the NSI meeting was to draft a use-case for topology descriptions. The goal is to have both proposals describe in detail the approach for topology description and how that would support pathfinding. My proposal is that both approaches outline the following: - Define a topology description for the Automated GOLE topology as was used during SC11 (10 networks, 4 VLANs, and their interconnections), diagram attached. - Describe how a pathfinding algorithm would consume the above-mentioned topologies, and then find path candidates from UvA to KRLight, and finally how to select one of the listed candidates in the following three scenarios: 1) none of the networks have VLAN retagging, 2) Only Netherlight supports VLAN retagging, 3) All network support VLAN retagging. - A *short* analysis of how complex this solution is for the topology. - A *short* analysis of how the solution would extend to multi-layer descriptions. The goal of these proposals is to inform the NSI group on the proposals, their complexity, and their future-proofness. I propose that we have a 3 page limit on the descriptions in order not to burden the rest of the group too much. Suggestions? Jeroen.

3 7

NSI CS document updated to v1.1
by Guy Roberts 20 Dec '11

20 Dec '11

I have updated the NSI connection service protocol document to reflect the WSDL and other v1.1 changes. This is available here: https://forge.ogf.org/sf/go/doc16045?nav=1 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 call
by Guy Roberts 19 Dec '11

19 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 * NSI Face-to-face confirmed for 14th-16th March in Oxford * 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

extended NSI face to face meeting at OGF34
by Guy Roberts 16 Dec '11

16 Dec '11

Hello NSI team, A meeting room has been arranged in Oxford for an extended NSI face-to-face meeting from 14th-16th March. This meeting is timed to fit straight after the regular OGF working group sessions. The agenda for this meeting is to agree the functionality for NSI version 2.0. I hope to see you there. Guy -----Original Message----- From: Alan Sill [mailto:alan.sill@ttu.edu] Sent: 16 December 2011 08:59 To: Guy Roberts Cc: Alan Sill Subject: Fwd: extended NSI meeting in Oxford FYI Begin forwarded message: > From: David Wallom <david.wallom(a)oerc.ox.ac.uk> > Subject: Re: extended NSI meeting in Oxford > Date: December 16, 2011 2:07:28 AM CST > To: "Sill, Alan" <alan.sill(a)ttu.edu> > > Room Is booked > > DW > -- > > ++++++++++++++++++++++++++++++++++++++++ > Dr David Wallom > Associate Director Innovation, Oxford eResearch Centre Technical > Director, UK NGS VP Communities, OGF > > Oxford eResearch Centre > 7 Keble Road > Oxford > OX1 3QG > UK > > Tel: +44 1865 610601 > ++++++++++++++++++++++++++++++++++++++++ > > > > > On 15/12/2011 10:17, "Sill, Alan" <alan.sill(a)ttu.edu> wrote: > >> >> David is checking on the extra day on the 16th. The rest falls in the >> interval of OGF34 already scheduled, and should be fine. >> >> Hope this helps, >> Alan >> >> >> On Dec 14, 2011, at 2:13 PM, "Sill, Alan" <alan.sill(a)ttu.edu> wrote: >> >>> Hi Guy, >>> >>> Thanks for the note. It's good to hear about the plans for the >>> extended meeting. >>> >>> I'll pass this on to David Wallom as our host for the Oxford >>> meeting, and I'm sure that Joel has taken note of this request also. >>> David and Joel, can we help arrange this? >>> >>> Alan >>> >>> On Dec 14, 2011, at 12:06 PM, Guy Roberts wrote: >>> >>>> Hi Alan, >>>> >>>> The NSI working group would like to hold an extended meeting in >>>> Oxford at OGF34. For this we would like a meeting room for a full >>>> 3 days in addition to the normal OGF meetings. This would most >>>> likely be on the 14th-16th March. >>>> >>>> I was wondering if you can help me arrange our own meeting room >>>> directly with Oxford e-Research Centre? Who is the contact person >>>> at Oxford e-Research Centre that I should discuss this with? >>>> >>>> Regards, >>>> Guy Roberts >>>> >>>> ___________________________________________________________________ >>>> __ >>>> >>>> ** 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 >>>> D A N T E United Kingdom WWW: http://www.dante.net >>>> ___________________________________________________________________ >>>> __ >>>> >>> >

1 0

NSI face-to-face meeting
by Guy Roberts 15 Dec '11

15 Dec '11

In today's NSI conf call we proposed holding the face-to-face meeting to discuss NSI v2.0 straight after OGF34 on the 14th-16th March in Oxford. I expect that the OGF meetings will be held on Monday and Tuesday (12th and 13th) and we would like to hold the face-to-face meeting on Wednesday through Friday (14th-16th). Could you please give me some feedback on whether this arrangement would be practical for you? Regards, 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 _____________________________________________________________________

4 3

NSI conf call minutes
by Guy Roberts 14 Dec '11

14 Dec '11

The minutes from today's NSI conf call are available here.... http://forge.gridforum.org/sf/go/doc16369?nav=1 Please take time to review the action points. 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

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