October 2013 - Nsi-wg - lists.ogf.org

Issue 113 in ogf-nsi-project: Change provisionState machine to be mandatory.
by ogf-nsi-project＠googlecode.com 14 Jan '14

14 Jan '14

Status: Accepted Owner: jmacauley Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 113 by jmacauley: Change provisionState machine to be mandatory. http://code.google.com/p/ogf-nsi-project/issues/detail?id=113 Decision was made to instantiate the provisionState when the first reserve request is received for a reservation. This makes it consistent with the other state machines. However, it should be noted that a provision request cannot be received until the first version of the reservation has been successful committed. If a provision request is received before the first version of a reserve has been created, then it must be rejected with an error. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

3 4

Issue 109 in ogf-nsi-project: Align STP Label definition closer to similar types within NML.
by ogf-nsi-project＠googlecode.com 10 Jan '14

10 Jan '14

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium FoundInVersion-2.0 FixedInVersion-2.0 New issue 109 by jmacauley: Align STP Label definition closer to similar types within NML. http://code.google.com/p/ogf-nsi-project/issues/detail?id=109 The NSI STP definition was originally intended to be a generic attribute type/value pair mechanism but morphed into a Label type definition. At the moment it is too complex for the role it is performing. In addition it is not in alignment with the NML definition for LabelType. These definitions need to be normalized. Also, NML has separate definitions for LabelType (a single label) and LabelGroupType (a range of labels). Both are applicable to the STP definition and should be incorporated. For example, using an STP to specify a SONET service would require the specification of a set of timeslots associated with the service on the STP. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 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

"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