March 2015 - Nsi-wg - lists.ogf.org

NSI topology distribution voting procedure?
by Hans Trompert 17 Mar '15

17 Mar '15

Hi, What is the NSI topology distribution voting procedure? Will the definite list of answer documents or a compilation thereof be sent to the list? Is there already a date on which the vote will take place? How will the vote be conducted? And who will be allowed to vote? Cheers, HansT.

2 2

No NSI meeting (Mar 11), NSI topology distribution requirements/feature checklist
by Chin Guok 16 Mar '15

16 Mar '15

Hi all, We will cancel the NSI meeting tomorrow (Mar 11) so folks have some time to work on the NSI topology distribution requirements/feature checklist. Attached is a pointer to the Google doc: https://docs.google.com/document/d/1875gI8x101SFAGkpq6ZV2WgjQh3qHnFV9a73PFd… This document includes NSI core requirements, topology distribution requirements (as presented and discussed at the NSI-WG in Oxford Jan 2014), as well as additional requirements discussed in the weekly calls and subsequent face-to-face meetings (relating to recent policy enforcement issues). The document cannot be modified, but anyone who has the pointer above has permissions to leave comments. The co-chairs will try and address any comments as necessary. For folks who have submitted a proposal, kindly make a copy of the document and fill it in accordingly. Please be brief and succinct with your answers (you can assume that anyone who wants more information can refer to your proposals), and share a link with the working group when you are done. We would like everyone to have their documents done by Mon Mar 16. Tentatively we plan to have a final Q&A session next week during the regular NSI call and finalize the voting process. Thanks! - Chin -- Chin Guok NOC: (510) 486-7600 Network Engineer (800) 333-7638 ESnet Network Engineering Group (AS293) Lawrence Berkeley National Laboratory

4 6

NSI Agent Description document
by Guy Roberts 11 Mar '15

11 Mar '15

Hello All, NSI Agent Description standard is open for public comment until March 20. Comments should be posted here: https://redmine.ogf.org/projects/editor-pubcom/boards I would like to encourage everyone to review the document and post your comments. This will help the OGF standards editor get the document through the publication process. Thanks, Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect GEANT Limited Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net> Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 GEANT Limited is part of the GÉANT Association Networking. Services. People Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/> GEANT Limited registered in England & Wales. Registration Number 2806796. Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ _____________________________________________________________________

1 0

GEC22 / US Ignite / OGF 43 / GLIF final agenda
by Sill, Alan 09 Mar '15

09 Mar '15

Final agenda attached below. As suggested by Wolfgang and ok'ed by Guy, we have dropped the additional NSI Friday sessions (but left time for a joint and a spare session with GLIF) and added a Cloud Standards roadmap session and other sessions that can be used by the Cloud Plugfest. I'll set up the schedule page on the OGF web site for this event to point to this, and to add additional details where we have them on the content of these sessions. Alan Begin forwarded message: From: "Vicraj Thomas" <vthomas(a)bbn.com<mailto:vthomas@bbn.com>> To: "angelamc(a)gwu.edu<mailto:angelamc@gwu.edu>" <angelamc(a)gwu.edu<mailto:angelamc@gwu.edu>>, "Cindy Spitzer" <spitzerc(a)gwu.edu<mailto:spitzerc@gwu.edu>>, "Kara Gillespie" <kara_gillespie(a)email.gwu.edu<mailto:kara_gillespie@email.gwu.edu>> Cc: "Sill, Alan" <alan.sill(a)ttu.edu<mailto:alan.sill@ttu.edu>>, "Zhenya Henderson" <zhenders(a)bbn.com<mailto:zhenders@bbn.com>>, "Donald DuRousseau" <ddurousseau(a)email.gwu.edu<mailto:ddurousseau@email.gwu.edu>>, "Joe Kochan" <joe.kochan(a)us-ignite.org<mailto:joe.kochan@us-ignite.org>>, "jennifer.mott(a)us-ignite.org<mailto:jennifer.mott@us-ignite.org>" <jennifer.mott(a)us-ignite.org<mailto:jennifer.mott@us-ignite.org>>, "Kevin Meynell" <meynell(a)glif.is<mailto:meynell@glif.is>>, "bensor(a)gwu.edu<mailto:bensor@gwu.edu>" <bensor(a)gwu.edu<mailto:bensor@gwu.edu>>, "Henry Yeh" <hyeh(a)bbn.com<mailto:hyeh@bbn.com>> Subject: Re: GEC22 registration report 3.6.15 Corrected versions attached. On 3/9/15 10:58 AM, Vicraj Thomas wrote: Hi everyone, Attached is what I hope is the final agenda in: 1. Excel format 2. png format 3. pdf format The icons that go on the agenda are in the png and pdf formatted files. Pl. use one of those for printing the agenda that goes in the welcome packets (with extra copies at the registration desk). < Vic On 3/8/15 9:30 PM, Vicraj Thomas wrote: Hi Angela, Cindy and Kara, Attached are: 1. A spreadsheet with the latest agenda and room setup, 2. The agenda graphic in png format, 3. The agenda graphic in pdf format. Unless somebody objects, this should be the final agenda and room assignments. < Vic On 3/6/15 11:32 AM, Sill, Alan wrote: Vic, I'm ready to discuss final meeting room assignments. Can you supply a phone number so we can go over them directly? Thanks, Alan On Mar 6, 2015, at 10:02 AM, Vicraj Thomas <vthomas(a)bbn.com<mailto:vthomas@bbn.com>> wrote: Hi Angela, I'm available all afternoon except from 4pm - 5pm ET. I will check w/ Ignite on the number of people they expect on Thu and Fri. Perhaps Skyline will suffice for them for those days. < Vic On 3/6/15 9:59 AM, Angela McKinney wrote: Hello Vic: Monroe 1 and 2 is not available to us on the last day of Friday, March 27. We can go review this afternoon if you are available. Cynthia and I would like to schedule a conference call with you this afternoon. Thank you /*Angela McKinney*/ /Executive Associate, Planning and Strategic Initiatives //Division of Information Technology The George Washington University/ Office - 571-553-4262 Email - angelamc(a)gwu.edu<mailto:angelamc@gwu.edu> <mailto:angelamc@gwu.edu> On Fri, Mar 6, 2015 at 10:42 AM, Vicraj Thomas <vthomas(a)bbn.com<mailto:vthomas@bbn.com> <mailto:vthomas@bbn.com>> wrote: Hi Angela, The graphic on the geni agenda page is not the final regarding room assignments. I have not posted the final assignment since I was waiting for confirmation from you and Janice on: * The revised room assignment I sent a couple of days ago, and * The availability of Monroe for use by US Ignite on Thu and Fri. (Pl. see the tab labeled "setup".) I've attaching to this email the spreadsheet I sent a couple of days ago. This shows the current assignment. Once we confirm the rooms, I will prepare the final graphic that includes the icons for tutorials, etc. If you think a quick phone call to finalize this will be helpful, pl. let me know what time works best for you. I'm fairly open this morning. Thanks! < Vic On 3/6/15 9:31 AM, Angela McKinney wrote: Hello All Per the agenda that is on the http://www.geni.net/. Please confirm that this is the final final regarding room assignments. Also, I will attach the spreadsheet and information and details from Henry submitted March 1. I believe this was shared with everyone. Please confirm with me on the information. Thank you /*Angela McKinney*/ /Executive Associate, Planning and Strategic Initiatives //Division of Information Technology The George Washington University/ Office - 571-553-4262 <tel:571-553-4262> Email - angelamc(a)gwu.edu<mailto:angelamc@gwu.edu> <mailto:angelamc@gwu.edu> <mailto:angelamc@gwu.edu <mailto:angelamc@gwu.edu>> On Fri, Mar 6, 2015 at 10:17 AM, Sill, Alan <alan.sill(a)ttu.edu<mailto:alan.sill@ttu.edu> <mailto:alan.sill@ttu.edu> <mailto:alan.sill@ttu.edu <mailto:alan.sill@ttu.edu>>> wrote: Thanks, Zhenya. I’m pleased to see that attendance continues to grow steadily. Do you have an estimate of the expected total, based on this and any information about registration patterns that you may have from past years of this conference? Based on the growth rate that we see here and taking a look through the registered attendees, I think we can anticipate that the OGF NSI and GLIF meetings, which will be combined, will constitute the majority of our OGF attendees. We have 42 OGF registrants so far, of which the majority (34) also checked the GLIF button, and 51 GLIF attendees, 31 of which also checked the OGF button. Since there is so much overlap between the GLIF and OGF attendees, they have defined a joint agenda for most of their sessions. That is already the one on the GEC agenda page. In terms of the other OGF sessions, I will get you and Vic a final list as promised by the end of today. meanwhile, this list helps a lot to know who will be there. The only thing that I can suggest at this point is that it is very likely we will not need a room of 75 capacity for the remainder of the non-networking OGF meetings. We could for example schedule the non-NSI OGF meetings to be in a smaller room Thursday and Friday. Thanks, Alan On Mar 6, 2015, at 8:46 AM, Zhenya Henderson <zhenders(a)bbn.com<mailto:zhenders@bbn.com> <mailto:zhenders@bbn.com> <mailto:zhenders@bbn.com <mailto:zhenders@bbn.com>>> wrote: Good morning, Please find attached most recent GEC22 registration report. Thanks, Zhenya -- Zhenya Henderson GENI Project Office Raytheon BBN Technologies 10 Moulton Street | Cambridge | MA 02138 T:617.873.3211 <tel:617.873.3211> <tel:617.873.3211 <tel:617.873.3211>> | F:617.873.5386 <tel:617.873.5386> <tel:617.873.5386 <tel:617.873.5386>> <GEC22 Registration report 3.6.15.xls> [B642BE84-7E56-491C-9832-C9024F334719]

1 0

Authorization in NSI
by John MacAuley 09 Mar '15

09 Mar '15

Peoples, Before Christmas I pulled together an NSI security omnibus capturing content from Han's AAI document and discussions we had been having on the mechanisms needed to convey security information in the NSI protocol. In addition, I tried to capture the routing policy requirements we have been discussing so I could have a clear view of what issues we are trying to solve. This lead to me writing a proposal for two solutions for the enforcement of end-to-end routing policy that require no changes to the existing CS protocol. As we start preparing for the Washington meeting I have decided to break the document up into three (or four) slide packages for discussion/presentation. I have attached the first of these slide packages. This one deals with the fundamental principles of security in NSI, and the topic of end user Authorization. Included in the slide package is the definition of an "originatingId" as agreed to in Uppsala last September. It captures the identifier of the originating uRA and the identity of the requesting user/application. In addition, it shows how end user authorization information can be generically included in the NSI header for use by end uPA. Thank you, John

2 2

Minutes from Wednesday's NSI call....
by Guy Roberts 05 Mar '15

05 Mar '15

... are available here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6598 _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect GEANT Limited Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net> Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 GEANT Limited is part of the GÉANT Association Networking. Services. People Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/> GEANT Limited registered in England & Wales. Registration Number 2806796. Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ _____________________________________________________________________

1 0

today's NSI conf call
by Guy Roberts 04 Mar '15

04 Mar '15

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 ET, 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: - John to present is proposal for NSI document distribution, see slides here- https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6604 - Other topics (time permitting): o Agenda for NSI meeting in Washington - https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6602 o NSI CS namespace URLs _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect GEANT Limited Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net> Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417 GEANT Limited is part of the GÉANT Association Networking. Services. People Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/> GEANT Limited registered in England & Wales. Registration Number 2806796. Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ _____________________________________________________________________

1 0

Slides for presentation
by John MacAuley 04 Mar '15

04 Mar '15

Peoples, Here is the slide pack I will be running through on the call later today. You have seen many of them before so I hope there is nothing too shocking. John

1 0

Pathfinding and Service (a new topology suggestion)
by Henrik Thostrup Jensen 02 Mar '15

02 Mar '15

Hi (part three on security and pathfinding). This one ended up being not so much about security, and more about pathfinding and services. And quite long. Sorry about that. We currently have a number of topology suggestions. None of them can adequately describe complex transit policies. I will try to address the issues of NML and GNS (The UvA suggestion is not a topology model), suggest a new model and present some further issues which we haven't considered yet. * Overview The main policy tool of NML is the switching service, which describes how ports in a node can be connected. This approach falls short when selective transit is provided, as this cannot be described as a switching service. It also means that it is not possible to enforce this policy locally by looking at the cross connect. The GNS suggestion announces reachability to other networks, done at NSA level. Hans pointed out that it should really be per network. However there are cases where networks are connected over multiple links with different policies, meaning that reachability would have to be provided per link. This approach is then getting awfully close to that of BGP. In BGP all reachability is explicit, as IP prefixes are announced (default route is the exception, but reachability is still explicit). Further, AS paths are announced, which makes it possible to build a network model. This enables faster recovery in case of link/router failures as it is possible to re-route traffic more efficiently. This is typically only done in backbone networks. Unlike BGP, NSI does not have a mechanism for aggregating its address space (ports). Since Uppsala, we can infer the network from the port name, however there is no way indicating which ports are closer to a certain demarcation link, which makes optimal pathing difficult. However, it is possible to split a network into multiple smaller networks for this, but a metric is still needed. No good technical metric exists to announce distances, and due to link pricing and policies, a distance metric must be administrative (works well in BGP). * Network & Services Given our decision to link STPs and network identifiers it becomes possible to do path finding to a network, instead to a specific port. This drastically reduces the amount of information a path finder must be aware of, and removes the problem of connecting to newly created STPs. Path finding per network is somewhat difficult in NML as the problem of adaptation between technologies in order to get the right service requires intricate knowledge of the capabilities of the networks. IP solves this problem by being a single universal service that can live on top of different technologies. Since we want to be able to provide multiple service types through NSI, this will not work for us. We also been struggling quite a bit of tying together technology, adaptations and services in NML as the combination becomes complicated quite quickly. Recently I've talked to several persons about the ANA infrastructure. The ANA infrastructure is interesting as the hardware comes from multiple vendors, and the infrastructure must provide different services (best effort circuits, circuits with guarantied bandwidth, and the same with protected circuits). Focusing on technological capabilities becomes quite messy in this scenario. Instead the important thing is to focus on what services can be provided, and let the NSI Agents handle the service to technology mapping. This is quite different from our previous approach. In short: I think we need to move to a model that is service centric instead of focusing on the technology of the equipment. * Topology Model I suggest a model that focuses on describing capability instead of the basic resources. It is based around two principles: - Network Reachability - Service Capability The first allows us to express complex transit policies in simple and well proved way (BGP). The second allows us to abstract away technology specific models and focus on what can services can actually be provided. This model puts policy and services before technological capabilities. By describing reachability, path finding becomes simple and predictable. This is major advantage over the graph search approach in NML which can produce extremely unfortunate effects such as cross-atlantic loops. Defining reachability will require manual work, however this will always be the case when describing policies. Here is how the topology description could look like in XML: <Network id="urn:ogf:network:aruba" version="123"> <Name>Aruba</Name> <Link id="urn:ogf:network:aruba:bonaire-otn" demarcation="urn:ogf:network:bonaire:aruba-otn"> <Name>Bonaire OTN Link</Name> <Service type="EVTS"> <ReachableNetwork id="urn:ogf:network:bonaire" distance="1" /> <ReachableNetwork id="urn:ogf:network:curacao" distance="2" /> </Service> <Service type="OTN"> <ReachableNetwork id="urn:ogf:network:bonaire" distance="1" /> </Service> </Link> <Link id="urn:ogf:network:aruba:dominica-eth" demarcation="urn:ogf:network:dominica:aruba-eth"> <Name>Dominica Ethernet Link</Name> <ServiceTransit type="EVTS" /> </Link> <Service type="SwitchingService" /> </Network> The topology description is really more of a transit table for services than an actual topology description (however we have never been describing topology, only networks and demarcations). Reachability is unidirectional and cannot be turned around, however the service provided might bidirectional. The description covers what the link can be used for from outside the network. The above example describes a network (Aruba), with two links. First link is an OTN link towards the Bonaire network. This link provides two services: EVTS and OTN. The EVTS service can reach the bonaire and curacao network, where the OTN service can only reach bonaire. How the EVTS service is carried on the OTN link is up to the aruba and bonaire network. The details are encapsulated. The second link in the network is an ethernet link towards the dominica network. This link provides what is called service transit, for the EVTS service. This means that the dominica can use the link to connect to any EVTS endpoint in the NSI system. This is similar to the concept of a default route in BGP. Finally a switching service is listed in the network. This denotes the capability to create a service in the network. There are several choices and tradeoffs in the design: - Only describe demarcation links. This means significantly less data to distribute and that the data will be fairly stable. This also removes the need for complex distribution mechanisms. - For each link, the supported services and reachable network for each service is listed along with a cost. This makes path finding straightforward: Select the link that provides reachability to the desired network that has the lowest value. Cost is an administrative value. Lower is better (think hops). The service first structure was chosen as I suspect it will be the smallest, but it could as well be network first and services listed under that. If a network cannot bridge a service type from one link to another, reachability for that network is not announced on link. This encapsulates complicated technology restrictions in a simple way, that would otherwise have to be built-in to pathfinders. - A link can provide service transit. This means that all networks supporting the service type should be reachable through that link. This would typically be used by a backbone network towards its customers. A customer may have other links that it could favor for some networks. Similar to how most networks have a transit provider, but will have private peering/links to other networks. - Can describe network services Some networks may provide services that are hosted in the network. This could be a switching service which could be used to connect p2p links in order to build a multi-domain switched network (I'll refrain from debating if this is a good idea). A list of potential network services: - Switching service. Will on creation return a number of STPs that can be used to connection P2P links - Aggregation. Aggregate the data from two or more unidirectional circuits into one. - Ping service Provides an STP with a pingable address. The network may of course also supply these like today with pre-configured STP. - Perfsonar Would spawn a perfsonar instance and return an STP endpoint. Label swapping capability is intentionally left out. We should stop engineering for old technology, and underspecified STPs goes a long way towards solving the issue if it should occur. By describing services and the capabilities of the network in this way, it becomes easier to introduce new services and possible to describe policies that would otherwise be complicated or impossible to express with previous suggestions. * Pathfinding As the networks explicitly describe reachability, an NSI Agent only needs to fetch the topology (service table) document from its peers to know which networks are reachable. This means that a document-distributing system is not necessary, as the connections between networks is largely static. The reachability document would only have to be updated at low intervals. For leaf networks, an NSA would simply be setup with another NSA as its transit provider. This NSA would then leave all pathfinding to be done by the backbone network. This situation is similar to how many organizations and smaller NRENs have a single transit provider, which does all their connectivity. The scheme assumes a chain-like path setup, which is intentional. Setting up a circuit in chain mode allows each NSA to verify that the transit policies of the network is enforced as it can see the destination network, and check it against announced reachability. It is not possible to perform such a check for UPAs when a circuit is setup in tree mode, as only the crossconnect is know. However chain mode will probably have to broken when crossing exchanges, as the NSI agents for such will typically be UPAs and not care about transit policies and link AUPs. Please refer to my previous email on secure crossing of exchanges for details on this. This means that we will end up with a hybrid pathfinding that does a tree with one branch being one layer deep each time an exchange is crossed. As chain pushes the decision for how to connect downstream, it does not allow the same control over the circuit (unless using EROs). However delegating this decision is likely to lead to fewer circuit setup failures. Consider the following setup: A = B = C Three networks: A,B and C. A and B are connected via two links, and similar for B and C (the = sign is two links). If A wants to create a circuit to C, it will setup a link to B and ask B to setup a cross connect into C. If one of the circuits between B and C cannot support the capacity, B can automatically choose the link with enough capacity to C. Only B and C has the knowledge about the state of their link, and are hence better suited towards taking the decision of which one to use. With explicit reachability and distances the process for setting up circuits becomes simpler and more predictable. The distance vector in particular makes sure that an optimal path is taken. This in contrast to NML that has no mechanism to prefer certain paths over others. * Handling Failure in Pathfinding Handling failure circuit(service) setup failures and attempting alternate paths (re-pathing) with only reachability information can be a bit tricky. This section covers how this can be solved. Currently we have the notion that aggregators should not try and fix failures, only return them to the UPA. If we relax this latter notion, it opens up the possibility for aggregators along the path to try alternate paths. However such attempts should be restricted to certain behavior, e.g., a backbone network can try alternative links towards a customer. Re-pathing should not use transit/peers towards customers or use transit to go to peers. If the notion of aggregators not being able to re-pathing holds, it is possible for a UPA to perform re-pathing, by constructing an ERO that doesn't take the link without enough capacity. Constructing such an ERO is likely to require more information than what is available from the topology of the peers and transit provider for the UPA. To construct the ERO it would have to fetch the topology of the backbone networks to build up a model of the network to find an alternative path. The reason only backbone networks is relevant is that end organization are typically multi-homed into the same provider, which makes smaller network largely irrelevant for re-pathing. Since the number of backbone network is relatively small and the information in their topology description is largely static, fetching them directly is simple and convenient. Performing re-pathing at the UPA is however suboptimal. Leaf networks will typically be very limited in their connectivity, where the service provider (backbone network) will have a much degree of connectivity. Hence it makes sense for the service provider to perform re-pathing. This is similar to how BGP re-routing is not done by smaller tier-2 and tier-3 networks. Re-pathing at smaller networks does not make sense as their connectivity is typically rather limited. However customers and providers can agree where and if re-pathing should be done (similar to how some IP customers get a full routing table, and others do not) Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 2