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

Half-day NSI Standards meeting at GENI on March 17th
by Inder Monga 16 Mar '14

16 Mar '14

Hi All, The GENI organization has kindly agreed to host the NSI Standards meeting on Monday March 17th from 9 am - noon. You will have to register for GENI in order to attend that. Registration is very reasonable $200 before March 1st. The link to the agenda is: http://groups.geni.net/geni/wiki/GEC19Agenda and registration website is (link off the GEC19 Agenda): https://www.regonline.com/register/login.aspx?eventID=1442572 The hotel reservation site is (code *GEC0314)*: http://www.secure-res.com/res/vn4/checka.aspx?hotelid=2871& trr=AFB636D83E5BB4&wtpid=1&scid=1&scdomainid=0&rlog=957&ri=18889&culture=1& culturename=en-US Even though NSI is officially listed on the GENI website, we need to have a tentative agenda. This is what I propose - please suggest agenda items or corrections via email: 9 - 9:10 am: OGF Standards update 9:10 - 9:40 am NSI 2.0 Brief Update/Tutorial for GENI attendees [TBD depending on attendance] 9:40 - 10:30 am NSI NSA Discovery Protocol (John MacAuley) 10:30 - 11:00 am Break 11:00 - 11:30 am Finalizing NSI Topology extensions to NML (John/Freek) 11:30 - 12:30 am TBD Thanks, inder Inder Monga | imonga(a)es.net Chief Technologist and Area Lead | http://www.es.net/inder Energy Sciences Network (ESnet) <http://www.es.net>

2 2

minutes from today's NSI call...
by Guy Roberts 12 Mar '14

12 Mar '14

.... are available here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6574 _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

1 0

Re: [Nsi-wg] Tomorrow's NSI conf call details. Note changed times in Europe and Japan!
by Guy Roberts 12 Mar '14

12 Mar '14

The documents for today's meeting are here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6581 Guy From: Guy Roberts Sent: 11 March 2014 15:46 To: nsi-wg(a)ogf.org Subject: Tomorrow's NSI conf call details. Note changed times in Europe and Japan! The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 14:00 GMT, 15:00 CET, 23:00 JST (new times in red) 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: - Preparation for Atlanta meetings next week. - John M. to present implementation discussion document on chain and tree models of messaging and _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

1 0

Tomorrow's NSI conf call details. Note changed times in Europe and Japan!
by Guy Roberts 12 Mar '14

12 Mar '14

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 14:00 GMT, 15:00 CET, 23:00 JST (new times in red) 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: - Preparation for Atlanta meetings next week. - John M. to present implementation discussion document on chain and tree models of messaging and _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK +44 1223 371316 DANTE is the project co-ordinator and operator of GÉANT, the high-speed pan-European research and education network that is transforming the way researchers collaborate. Learn more at: www.geant.net<http://www.geant.net/> Like us on: www.facebook.com/GEANTnetwork<http://www.facebook.com/GEANTnetwork> Follow us at: www.twitter.com/GEANTnews<http://www.twitter.com/GEANTnews> DANTE is the trading name of Delivery of Advanced Network Technology to Europe Limited registered in England & Wales. Registration Number 2806796. Registered Office - 9400 Garsington Road, Oxford Business Park, Oxford OX4 2HN. _____________________________________________________________________

2 1

Some perspective on the discovery service and topology
by Henrik Thostrup Jensen 05 Mar '14

05 Mar '14

Hi As promised, here is my concerns over the proposed discovery service, a long with concers over our current topology model / way of thinking about topology. Discovery service: - Essentially a mechanism to publish (and subscribe to) documents, with the documents emitted through a flooding mechanism. - Documents are signed by their creater. - It is not explained why it is better to have a flooding mechanism to distribute documents instead of distributing only the link to discovery services and subscribing directly from the source. This is despite the latter being significantly simpler, while providing the exact same functionality and with the same amount of messages send in the system. - The flooding mechanism distributes the exact number of messages / documents by pushing them around. It is not more efficient, it just adds more with lifetime, expiration, etc. - The only way to got more effient distribution is to aggregate information somehow, but that is - AFAICT - not done. - Also, I have no idea what it is this thing is trying to do/solve. Signing and distributing the documents like this, still doesn't solve the issue of transitive trust. Say a setup like this: A - B - C A trusts B. B trusts C. A does NOT trust C. A getting information from C, signed by C, does actually do anything, because cannot verify it. What is weird is that if A requests a connection service from A to C, through B, it HAS to trust B, and implicately C, to provide the service. This issue comes up practially everywhere when building networks. You have to trust your provider to deliver your data, and trust your peers to not only announce the right reachability information, but also to deliver data to end users. I'll just repeat it... Signing documents doesn't solve the issue of transitive trust. To transit into the second major issue: Distributing information like this combined with NML means one can acquire network topology descriptions. However in our current system (and way of thinking) we only export one topology per network. The discovery service system further enhances this view of the world by distributing the single description further. However network don't really work like that. They have different policies towards different other networks. I'll use the nordunet network to show how these policies work. You can see an overview of it here: http://stats.nordu.net/stat-q/load-map/ndn-map,,traffic,peak We do several things with our network: - Provide generic connectivity to our few owners/customers (the NRENs of the five nordic countries) - Peer with a number of networks, mainly at NETNOD, AMSIX, LINX, DECIX, along with several Equinix sites and CPS in the US. - We also provide US transit to PIONIER and SURFnet (which we have private links to) - We also have links to GEANT, these are used for transit towards europeans NRENs - We also have services towards RBnet and RUNNET, but I am actually not sure what we provide to them. As you can imagine this is a bit of mish-mash with a lot of policies for who can use the network in what manner. Here are some things we DO NOT allow: - SURFnet & PIONIER to send data to GEANT through us - Allow transit between GEANT and our peerings Both of these lists can be made very long. Most of this is handled with BGP communities (I assume). Essentially NORDUnet is a transit network (I guess all network are that in some sense), but how you can use our infrastructure depends on the agreement you have with us. I can fairly easily create a single topology of our network, but that topology doesn't tell anyone how they can use it. For instance our links over the Atlantic are rather heavily loaded, but additional capacity over the Atlantic costs a significant amount of money (the ANA-100 circuit is attempt of trying to reduce costs over the Atlantic for NRENs), so we are in general not going to allow connections over those link except for special arrangements. Our initial NSI peering are likely to be DeIC, GEANT, SURFnet, and possibly SUNET (Onsala). What I'd like to announce wrt. reachability is something like this: DeIC: SURFnet, GEANT, SUNET SUNET: SURFNET, GEANT, DeIC SURFnet: DeiC, SUNET GEANT: DeIC, SUNET Furthermore we have a potential user through DeIC that may want to reach SLAC which means transatlantic link, so we might announce a different reachability towards DeIC. Our agreement with SURFnet and GEANT might also differ in how other networks can reach us through them, and what they can announce other networks. But this is not really possible currently. I can start to serve different topologies depending on request IP, but that is a hack. So essentially, the problem boils down to this: In our current model, describing topology doesn't tell me how I can use it. This makes path finding rather difficult. The reasons for different policies to different networks is usally political and economical. Right now we have a model that deals mainly with technological aspects of networking, but we cannot ignore the other aspects of it. Furthermore, with networks the size/layout of NORDUnet (and GEANT, ESNet, and more) it becomes rather difficult to perform effecient path finding when having opaque networks. I've been toying with idea of being able to split network into sub-parts (nordunet would probably be nordic, eu, and us), somewhat inspired by some ideas from Jerry, but I haven't gotten around to do something concrete, and I am not entirely sure how useful it is. Anyway, this is just the tip of the iceberg. In short: The discovery service doesn't solve any problem AFAICT. In fact, it just reinforces some dogmas which I think are wrong. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

3 3

Re: [Nsi-wg] NSI Identifier format
by John MacAuley 03 Mar '14

03 Mar '14

Update based on Han's feedback. NSI has the requirement that the networkId of a resource must be parseable from the resource identifier. This is especially true for the STP identifier as we have a specific requirement that an STP identifier need not be exposed in topology, and therefore, the network identifier must be derivable from the STP identifier if the target network is to be determined. The current URN format specification document published by the NML group for use as identifiers in NML [ref] defines the resource identifier as opaque, which also implies non-parseable. We need to resolve this issue. I have captured a proposal below for an NSI identifier that removes the opaque URN restriction and imposes structure on the URN. I hope this generates positive discussions :-) <NSI identifier> ::= <prefix> ":" <organization> ":" <type> <prefix> ::= "urn:ogf:network" /* Should this be "urn:ogf:nsi". */ <organization> ::= <domainName> ":" <year> <domainName> ::= <string> <year> ::= <string> <type> ::= <nsa> | <network> | <stp> | <sdp> | <serviceAdaptation> | <serviceDomain> | <service> <nsa> ::= "nsa:" <nsaId> <nsaId> ::= <string> <network> :: = "network:" <networkId> <networkId> ::= <string> <stp> ::= "stp:" <networkId> ":" <stpId> <stpId> ::= <localId> <label> <label> ::= “?” <labelType> “=” <labelValue> | “?”<labelType> | “” <labelType> ::= <string> <labelValue> ::= <string> <sdp> ::= "sdp:" <sdpId> <sdpId> ::= <string> /* Should this be some type of source/destination stpId combination. */ <serviceAdaptation> ::= "serviceAdaptation:" <networkId> ":" <serviceAdaptationId> <serviceAdaptationId> ::= <string> <serviceDomain> ::= "serviceDomain:" <networkId> ":" <serviceDomainId> <serviceDomainId> ::= <string> <service> ::= "service:" <networkId> ":" <serviceId> <serviceId> ::= <string>

5 12