- Nsi-wg - lists.ogf.org

NICT booth presentation at SC13, 11:00-12:00, November 20, 2013
by Jin Tanaka 20 Nov '13

20 Nov '13

Dear all, We are sorry for late notice. Actually, we JGN-X/KDDIlabs/NICT will make a booth presentation related to A-GOLE/NSI at 11:00-11:45 today. Here are presenters: 1) JGN-X Japan : Jin Tanaka 2) SINET4, Japan : Michihiro Aoki 3) GEANT EU : Richard.Hughes-Jones So if you have a time, please visit to our NICT booth #4341. And also we prepare some novelties for A-GOLE/NSI partners. Best Regards, Jin Tanaka

1 0

Some comments for latest service definitions
by Henrik Thostrup Jensen 19 Nov '13

19 Nov '13

Hi In revision 101 label got re-added under StpType, which fits with what we agreed with on the call as far as I can remember. However sourceVLAN and destVLAN still exists in the EthernetVlanType. Is there a reason for this, or did we just forgot to take them out. Further is there a reason to keep EthernetVlanType around? If one wants a VLAN, one just specifies a label and if one wants plain ethernet, no label should be specified (right?). We also have some discrepency between NML and STPs. A Port/PortGroup in NML can only have a single label, which has a single value. Our StpType can have multiple labels. Furthermore a label can have multiple values, which confuses me a bit, but it might be related to the next issue. Overqualifying labels is something that isn't really documented anywhere AFAICT. In NML we specify ranges with "start-end" and AFAIK, can also be comma-seperated. In NSI I reckon we should do the same when overqualifying, and only have a single value in the label. Furthermore we should have it written down... somewhere... how to overqualify a label with the "start-end" semantics. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 1

NML Security Requirements
by Henrik Thostrup Jensen 14 Nov '13

14 Nov '13

So, requirements for secure topology distribution. Personally, I don't quite believe in "requirements", as system design inherently contains tradeoffs between functionality, complexity, security, and usability (we usually only focus on the first). However it is topic that deservices some more light. Some basic stuff: * An NSA should be able to publish its topology, and others NSAs should be able to retrieve it in such a way that it has not been tampered with. * There should be a mechanism to prevent (well filter/detect) NSAs from publishing topologies, where ids overwrite other ids (injection). Any further requirements depend on what functionality it is we want have in topology distribution and how topology and path finding should work (which is, at least to me - still up in the air). One thing, I think we should start making clear is what it means when an NSI XML document has multiple (NML) topologies in it? * Does it mean that it administrates the topology (I believe we agreed on this) * That it peers with the NSAs of the respective topologies (and can hence setup circuits on it) * That it is simply relaying information somehow One solution that have come up to prevent injection / to allow an NSA to publish topologies for altnernate domains (those two things are more or less the same, but with very different intentions) is to sign the nml:Topology element. E.g., the NORDUnet NSA could announce both the nordu.net topology and the deic.dk (the danish NREN) topology. However, NORDUnet and DeIC are different adminstrative organizations, and NORDUnet should not have their certificate (hence I cannot use SUNET as an example). Certificates should not be thrown around like that. Of course DeIC could publish their own topology, but it is difficult to see what is gained by having NORDUnet relay it. Furthermore we do not have an everyone-trusts-everyone model in NSI (which is a good thing), but instead have transitive trust. There is no guarantie that anyone else than your peers (whatever that means), actually knows your certificate. Further questions: * Can topology information be sensitive? I.e. have limited distribution? Since topology is - inherently - meant for distribution, it is difficult to restrict the distribution of it. I suggest we try not to deal with this. Remember, that termination points should not have to be listed, as there might be an awful lot of them, and that the core point of topology exchange is to facilitate pathfinding. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

4 3

minutes from today's NSI conf call
by Guy Roberts 13 Nov '13

13 Nov '13

.... are available here: https://redmine.ogf.org/dmsf/nsi-wg?folder_id=6529 _____________________________________________________________________ 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

QueryNotification changes
by John MacAuley 13 Nov '13

13 Nov '13

All, Please find a modified presentation from Maastricht on the topic. I have added slides 13 - 20 describing the proposed changes. John

1 0

today's NSI conf call
by Guy Roberts 13 Nov '13

13 Nov '13

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: - Preparation for SC13 - Action points from last week - Getting NSI CS specification finalised this year. _____________________________________________________________________ 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

dynamicKL status
by 이경민 13 Nov '13

13 Nov '13

Dear Gerben and all I will let you know dynamicKL status 1. dynamicKL(NSIv2.0) implementation is complete! 2. and also dynamicKL working as a aggregator - anybody can use dynamicKL as a aggregator 3. in case of request to surfnet,g-lambda-a,kddi-labs, I received confirm message well - Could you confirm that NSI message is correct? - the other site is not recheachable 4. I need confirm as a provide, please anybody request to dynamicKL 5. vlc server is ready for sending and receiving. we need vlan number and port(vlc) number. 6. Vlans are all ok between krlight and StarLight Best regards. -------------------------------------------------------- Korea Institute of Science and Technology Information(KISTI) Networking Service Development Team Lee KyoungMin Mobile : 82+10-9958-8979 e-mail : tsoc(a)kisti.re.kr

2 1

Suggestions for revised NML XSD schema
by Henrik Thostrup Jensen 12 Nov '13

12 Nov '13

Hi It seems we need a rehash of NML XML schema for support NSI. Here are some further suggestions for how to improve the schema. The changes should not change the semantics of NML, but just make it easier to parse. * Any element in PortGroup This is the main problem. John already has a fix for this. Should probably go through the NML schema and check that it is on everywhere. * Bidirectional ports after unidirectional ports In the current model a bidirectional port is composed of two unidirectional ports. When building a datastructure representation, this means that one has to construct a temporary value/object to track this mapping, as the data structure representing the undirectional ports have not yet been created. Having the bidirectional ports after the unidirectional removes this need, making the parsing simpler. * Replace nml:Relation The nml:Relation constructs are not very "XML". I suggest that instead of <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> one would use: <nml:InboundPorts> Several elements would have to be constructed for this though. * Identical List constructs The way list of bidirectional ports and unidirectional ports are created are different. Bidirectional ports are repeated in the topology element, where as unidirectional ports are contained under an element. I.e: <nml:Topology id=...> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id=...> ... </nml:PortGroup> <nml:PortGroup id=...> ... </nml:PortGroup> </nml:Relation> </nml:Topology> There isn't really a wrong or right way to do this, but I think doing both is the worst option. I understand that bidirectional ports are a somewhat special things in NML, but they could still easily be contained in an element. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

3 3

Encoding & Labeltype
by Jeroen van der Ham 12 Nov '13

12 Nov '13

Hi, This is the decision regarding encoding and labeltype that was made for NML: https://forge.ogf.org/sf/sfmain/do/go/artf6577 : > NML has currently a one-to-one relation between the layer encoding (a URI to define the layer of sublayer of a specific > Port of Link) and the label type (a URI to define the resource label of a technology). > > Proposal: (was: Option 4). Use "encoding" for layer encoding and "labeltype" for label type > > <nml:Port id="...."> > <nml:encoding> > http://schemas.ogf.org/nml/2013/10/ethernet#802.3</nml:encoding> > ; > <nml:label labeltype=" > http://schemas.ogf.org/nml/2013/10/ethernet#vlan > ">1780</nml:label> > </nml:Port> There is not a one-to-one correlation, because encodings (such as Ethernet) still allow traffic without labels at all. Jeroen.

5 22

Some recommendations about layer adaptations
by Jerry Sobieski 11 Nov '13

11 Nov '13

Hi folks - Attached is a document that was posted to the NSI list almost two years ago about the complexities of adaptations. It is still 98% accurate and relevant. This topic of adaptation and switching capabilities does not seem to me to be an urgent issue. And its complexities are becoming quite evident. I understand why some engineers want to be able to hop layers - but while I understand it, IMO its just unnecessary. I strongly assert that we are putting a lot of hacks into the topology, the service descriptions, and NSI to do this before we have really thought all the issues through and that what we are inserting into this NSI standard will not in fact do what you expect or hope it will. I suggest that we shelve the issue as part of v2 and address the issue more formally in v3. So, in V3 we should create a feature called "service adaptation for automated pathfinding" and define its real use cases/needs - and from those use cases identify a set of basic and fundamental requirements that must be met - in the NSI protocol, in NML, in Service Descriptions, in Best Practice, ... And then decide how best to implement them in a way that scales effectively, supports provider autonomy, is secure, and above all is as simple as possible. And I would also assert that we find a way to allow these services to become more sophisticated incrementally - too much required on Day One makes it difficult to deploy. I suspect we will find many many aspects of this [adaptation/swithcing capabilites] that break (e.g. what if a transit network does not advertise certain functions?). And many aspects that are related (e.g. looping) that must be solved in conjunction, or that pose an alternative mechanism (e.g. topology distribution) and unexpected complexities (e.g. unidirectional vs bi-directional topologies or circuit requests, multi-point circuits, etc.) The reason I suggest that the automated adaptation issue is not urgent is because we are presently already able to take advantage of multi-layer services by means of abstraction and apriori tunneled adjacencies in the topology. (See the attached document.) And we can do this with dynamic provisioning at each layer - if not between layers. This may not be glorious automated pathfinding, but it none-the-less lets us take advantage of underlying service layers for the near term and where it is truly necessary while we take a more thoughtful and comprehensive look at the actual requirements and full range of mechanisms for automated multi-layer provisioning on the global basis. I also think this issue has (yet again) polluted the NSI *Service* oriented concept by falling back into traditional concepts of hardware plumbing based thinking. We need to get away from this traditional fixation on hardware technology and stay focused on the service presentation of these network service domains. There is no real need to deal with the hardware issues at the global service layer. I strongly suggest that if we would just try to do this as utterly simply as possible -i.e flat consistent service regions - at least initially - we will find that 99% of all issues are satisfactorilly resolved. And any additional adaptation considerations are being made much more complex because we do not have an established and generalized model of a flat service regions/layers from which to make generalized adaptation extensions. We actually need these simple flat contiguous service regions as a generic foundation before we can effectively develop viable or scalable models for adaptating between these layers (right now we are thinking about hardware adaptation - not service layer adaptation!) By adding all of these hacks we are actually making adatation much more convoluted and difficult to handle and we will be rethinking it all in v3 anyway. We really REALLY need to slow down and think the issues through. If we push the adaptation issue and "switching capability" issue to V3, and for v2 commit to a simple flat contiguous service regions we do two things: We get a viable service on the air that 90% of all NRENs will be able to actually deploy and users care about, and we gain real first hand experience on what the service really needs in order to be successful on a global basis. THe adaptive switching is an optimization for which we have no established services yet to optimize. (We could go through al of these hacks onyl to find SURFnet is the only network that needs them (SURF is just an example:-).) We can use the actual experience to inform and weigh those actual uses cases that we think are so important. It is much more important at this stage that we have a single user oriented service region broadly deployed globally, than to have these adaptations - the adaptions are causing significant delays to publishing and deploying these services. And I will bet you we find that most of our traditional thinking about multi-layer adaptation breaks down in the NSI service oriented model and becomes moot - an anachronistic habit from older technologies that is no longer particularly meaningful (just like protection switching vs reliability modeling...) We are trying to recreate old solutions to old technology issues. And as I say too often - we are making the problem *MUCH* more difficult than it has to be. So please review the attached document if only for informational purposes. And I propose that we shelve the adaption/switching capabilities issues and extract them from v2, and put them on the discussion list for v3. Best regards Jerry

1 0