- Nsi-wg - lists.ogf.org

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

06 Nov '13

The minutes from today's NSI conf call 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. _____________________________________________________________________

2 1

today's NSI conf call (note time change in EU and Japan)
by Guy Roberts 06 Nov '13

06 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: - NSI topology issues, assigning SDs to STPs especially for groups - Security certificates - a set of requirements are needed - How the NSI topology can be validated - Switching Service for vlan label swapping: current NML cannot have multiple labels per port. NSI extension to NML are required. - Error response and query: John to provide an analysis of this issue _____________________________________________________________________ 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

"If-Modified-Since" check and version attribute
by John MacAuley 01 Nov '13

01 Nov '13

Henrik, I am using the jersey REST client in Java and just setting the header: GET https://raw.github.com/jeroenh/AutoGOLE-Topologies/master/master.xml Accept: application/xml If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT I use the epoch for the first retrieve and then whatever was returned in the "Last-Modified" header. I have also started checking the version attribute in the <NSA> element for changes. Could you also make sure that only gets updated when there is a change, restart, etc.? I have copied the NSI list so NSA owners can also start implementing the optimizations when they have time. Please let me know when/if you get it done. Thanks, John On 2013-10-31, at 10:55 AM, Henrik Thostrup Jensen <htj(a)nordu.net> wrote: > On Thu, 31 Oct 2013, John MacAuley wrote: > >> I implemented the "If-Modified-Since" check within my topology discovery code. I need an NSA that actually supports the query. > > You just need a client that supports it. curl works fine: > > htj@scandium> curl -I http://scandium:4080/NSI/topology/aruba.net.xml HTTP/1.1 200 OK > Date: Thu, 31 Oct 2013 14:53:59 GMT > Last-Modified: Thu, 31 Oct 2013 14:52:22 GMT > Content-Length: 2076 > Content-Type: text/html > Server: TwistedWeb/13.0.0 > > htj@scandium> htj@scandium> curl -I --header 'If-Modified-Since: Thu, 31 Oct 2013 14:52:23 GMT' http://scandium:4080/NSI/topology/aruba.net.xml > HTTP/1.1 304 Not Modified > Date: Thu, 31 Oct 2013 14:54:08 GMT > Server: TwistedWeb/13.0.0 > >> Does OpenNSA? > > No, I've only implemented it service-side so far. Now that someone else supports I might get around to it. > > > Best regards, Henrik > > Henrik Thostrup Jensen <htj at nordu.net> > Software Developer, NORDUnet >

2 1

Today's NSI call
by Tomohiro Kudoh 30 Oct '13

30 Oct '13

Hi all, **** NOTE: TIME CHANGE for EUROPEAN participants **** The following is dial-in information for Today's NSI call: Time: 7:00 PDT 10:00 EDT, 14:00 BST, 15:00 CET, 23: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: - Discuss topics sent to the mailing list.

1 0

Adding service definition elements to NML
by John MacAuley 30 Oct '13

30 Oct '13

Peoples, Our decision in Madrid was to associate a list of applicable service definitions against an STP within our topology definitions. The question I have is a that of procedure. At the moment there is the base NML specification (nmlbase.xsd) which we should never have to touch. Then there is the NML extensions for NSI (nsi-ext.xsd) which contains definitions for our NSA and Service entries. It is my assumption that we should we be expanding on the "NML extensions for NSI" document instead of creating an additional "NSI extensions for NML extensions for NSI". Do people agree? I had a look through the NML base definitions and it looks like we could put a serviceDefinition element into the base PortType definition through the XML ANY held in the BasePortContent group. However, we are in a bit of a pickle for PortGroup because it does not contain a direct child XML ANY element. Therefore, we will need to access indirectly through a Port element, which may confuse the meaning of PortGroup a little bit. I have included a mock example below: <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Port><nsi:serviceDefinition type="EVTS.A-GOLE"/></nml:Port> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation> The other option we have is to invert the relationship and include the member Port/PortGroup elements in a service definition element as a child of the Topology element something like this: <nml:Topology id="urn:ogf:network:example.org:2013:topology"> <nml:name>ExampleA Topology</nml:name> <nsi:ServiceDefinition type="http://services.ogf.org/nsi/2013/07/definitions/EVTS.A-GOLE"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out" /> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in" /> </nsi:ServiceDefinition> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasOutboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-out"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-in"/> </nml:Relation> </nml:PortGroup> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id="urn:ogf:network:example.com:2013:eth0-in"> <nml:LabelGroup labeltype="http://schemas.ogf.org/nml/2013/05/ethernet#vlan">1780-1783</nml:LabelGroup> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#isAlias"> <nml:PortGroup id="urn:ogf:network:example.org:2013:eth0-out"/> </nml:Relation> </nml:PortGroup> </nml:Relation> </nml:Topology> I believe that given the current limitations of the NML base schema we should probably use the second mechanism. It seem to fit a bit better and will contain the ServiceDefinition element to a single location on the Topology element. Comments? John

3 6

master.xml
by John MacAuley 30 Oct '13

30 Oct '13

Peoples. I thought I would point out the master.xml on github is invalid NML and will not parse using the nmlbase.xml and nsi-ext.xsd schemas as defined. The nsi:isReference attribute is not defined in schema, and therefore, cannot be parsed by JAXB based off the nmlbase.xml and nsi-ext.xsd schemas. There are two problems with the XML as defined: 1. There is no anyAttribute defined in the context of the Topology element from nmlbase.xml so attributes from an external namespace cannot be included. 2. There is no isReference attribute defined in nsi-ext.xsd so it cannot be used. If we intend to use this mechanism for an extended period of time I would suggest we formalize the required schema changes as part of topology distribution version 1.0. I attached what I modified to get my implementation to work correctly. These are backward compatible changes in NML, which will allow an application compiled with the new schema to read old files, however, the reverse is not true. We should probably do an update to the standard schema once we agree on how Service Definitions get supported. John

3 3

GitHub issues
by John MacAuley 30 Oct '13

30 Oct '13

Peoples, I have been testing my dynamic topology loading from GitHub and I am getting frequent errors. When I say frequent I mean over 50% of the time. Errors can be either 404 to 503. Is anyone else seeing the same issue? I have been doing some reading and I could not find anything on rate limiting, so I can't believe a couple queries a minute is going to cause problems. I am concerned that if this issue persists then demoes will become unstable. John

2 3

SwitchingService for VLAN swapping
by John MacAuley 29 Oct '13

29 Oct '13

Peoples, Those domains that can support VLAN swapping will need to add a SwitchingService entry to their topology. After a discussion with Freek on the topic we have agreed on this example: <nml:SwitchingService id="urn:ogf:network:example.net:2012:vidSwitchingService" encoding="http://schemas.ogf.org/nml/2013/03/ethernet#ieee802.1q" labelSwapping="true"> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#hasInboundPort"> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_X:1780:in"/> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_Y:1781:in"/> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2013/03/base#hasOutboundPort"> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_X:1780:out"/> <nml:Port id="urn:ogf:network:example.net:2012:nodeA:port_Y:1781:out"/> </nml:Relation> </nml:SwitchingService> This follows the standard NML pattern in that both Port and PortGroup are supported but not BiDirectionalPort. If you notice we have an issue with the ethernet namespace in that it has not been standardized, and depending on if you look at the NML standard or the A-GOLE topologies, we either using the http://schemas.ogf.org/nml/2013/05/ethernet or the http://schemas.ogf.org/nml/2012/10/ethernet namespace identifier. We need to create a formalized Ethernet document for reference and designate a namespace for our topologies. We can then capture and document the specific URI fragments (vlan, ieee802.1q, etc.). I will discuss this with Freek. John

1 0

Validating URNs in NML
by Henrik Thostrup Jensen 28 Oct '13

28 Oct '13

Hi (there is tl;dr at the end). When an NSA retrieves a topology, it has to ensure that the topology does not overwrite any existing topology entities - either accidentally or by purposely injecting identifiers to overwrite topology entities from other topologies (id clash). This is an important issue as soon as an NSA dynamically retrieves topologies, as they can no longer be manually verified. The identifier used in NML is the id attribute of XML elements, has the following structure: urn:ogf:network:nordu.net:2013:opaque Such a URN can (roughly) be split into three parts: 1: urn:ogf:network 2: nordu.net:2013 3: opaque For more details on the URN construction see GFD.202. One is not allowed to interpret URNs as such, however I believe this is concerns the opaque part. The first part is static, and we can largely ignore it here. However the second part (called ORGID in GFD.202 is very important). It is composed of two parts, a domain name, and a year (can be also year+month, or year+month+day). In order to prevent injection/override of topology entities, an NSA should only be allowed to create ids that fit its organization and relevant domain names. I.e., only NORDUnet should be allowed to publish identifiers with the nordu.net domain name (which NORDUnet of course owns). To integrate with existing security infrastructure this means matching the host name in the X509. Furthermore regular URL - certificate matching still applies. Say I publish a topology in the following URL: https://nsi.nordu.net:9443/NSI/topology/nordu.net:2013.xml The host name in the URL is "nsi.nordu.net" and hence the host name in certificate must be "nsi.nordu.net" as well. Furthermore the topology entities represented in the resource, must match with the certificate name, i.e., they should start with urn:ogf:network:nsi.nordu.net:. Right now this is not the case, it uses "nordu.net". This is actually an injection, but not a serious one. It is possible to create some complicated rules to allow such a case, however I strongly suggest going for simplicity and enforcing a strong 1:1 correspondence. Similarly, the NSA urn id, must also adhere to this principle. This, unfortunately, makes it impossible to host an NSA for which the identity does not fit the certificate host name. For the date part, extending the certificate part to hold for this is bit tricky. If I use "2013", my certificate should of course be valid for some range of the year 2013. However certificates have a limited lifetime, and are usually only valid for 1-3 years. Once the certificate have rolled over, it is no longer valid for any date in 2013, and hence the year part can no longer be verified. A somewhat weird solution for this could be to keep the old certificate and present it with the topology, however all security stacks will (and should) reject such a certificate. It is possible to the check manually of course, but this impractical, and a very bad idea. I cannot see any practical way to validate the years in URNs, meaning they do not really add any value for separating identifiers. Summary: 1: The domain name in a NML topology id URNs must match the X509 host name A. This must hold for the NSA URN as well. 2: There is no practical way to enforce the year/date segment. As a corollary of 1A, a single endpoint cannot host an NSA for an alternative domain, without coming up with a rather convoluted security model. -- Some further questions for the GFD.202 authors: URNs are supposed to be persistent. Host names are not persistent. Why put them in there? URNs are supposed to be location independent. Why put host names in there? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

1 0

minutes from today's NSI conf call...
by Guy Roberts 23 Oct '13

23 Oct '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