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

today's NSI conf call
by Guy Roberts 28 Oct '14

28 Oct '14

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 BST, 16:00 CEST, 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: - All to update their progress on NSI documentation - NURN discussion follow up - OGF colocation with GEC22 (23-26 Mar 2015, Washington) possible dates: March 25-27? _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK Office +44 1223 371316 Mobile +44 7881336417 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

New NSI informational document for public comment
by Guy Roberts 23 Oct '14

23 Oct '14

Hello Greg, Please find attached a new NSI informational document. This document explains the implications for signalling and path finding when implementing NSI as described in the NSI Framework and CS protocol doucments. Could you please review and if suitable make available for public comment? Regards, Guy _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK Office +44 1223 371316 Mobile +44 7881336417 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

minutes from today NSI conf call
by Guy Roberts 22 Oct '14

22 Oct '14

.... are available here: https://redmine.ogf.org/dmsf_files/13368 _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK Office +44 1223 371316 Mobile +44 7881336417 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

ERO
by John MacAuley 22 Oct '14

22 Oct '14

Peoples, I am going to implement the ERO capability in our path finder and want to make sure we are all on the same page for how members in the order list are handled. I would also like to agree on some rules for handling both strict and loose ERO. We do not differentiate between loose and strict in the schema, so it really comes down to whether a path finder needs to do any additional resolution to satisfy the request. For this exercise I would like to use the following ports that form a valid path (I modified the ESnet ports to be compliant to the new STP format). I will assume all networks support label swapping. urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779-1799,3400-3499 urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779-1799 urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779-1794,1797-1799 urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779-1794,1797-1799 urn:ogf:network:netherlight.net:2013:production7:starlight-1?vlan=1779-1794,1797-1799 urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779-1794,1797-1799 1. A strict ERO for this path would be the following (from source to destination): urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779 urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779 urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779 urn:ogf:network:netherlight.net:2013:production7:starlight-1?vlan=1779 urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779 Each fully qualified STP identifier is provided from source to destination with no gaps. In this case I would like to agree on a restriction that if a two edge ports on a single network are provided, path finders do not try to route with anything other than resources in the network (i.e. do not try to connect two ports in a single network together by routing out of the network and back into the network). This will stop crazy routes from occurring if for any reasons those to ports cannot be connected by the domain (remember my label swapping solution on the A-GOLE). 2. A ERO with internal topology not contained in NML: urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:es.net:2013:production:internalA?vlan=1779 urn:ogf:network:es.net:2013:production:internalB?vlan=1779 urn:ogf:network:es.net:2013:production:internalC?vlan=1779 urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779 urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779 urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779 urn:ogf:network:netherlight.net:2013:production7:starlight-1?vlan=1779 urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779 In this case I also have a strict ERO based on the NML topology, but for the ESnet segment I have also supplied internal topology based in information not known to NSI path finders. In this case I would like to agree on two restrictions for this capability: a) When specifying internal topology elements you must bound them by two valid edge STP for that network from within the NML topology. In this case we have bounded the internal topology elements (internalA - internalC) by the STP in bold. urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:es.net:2013:production:internalA:1779 urn:ogf:network:es.net:2013:production:internalB:1779 urn:ogf:network:es.net:2013:production:internalC:1779 urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779 This will allow path finders to perform inter domain routing to the boundary STP, and pass the remaining elements into the uPA for resolution. b) When specifying internal topology elements not defined in your NML they must follow the standard STP format and be prefixed with the network Identifier for the network in which they are contained: urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:es.net:2013:production:internalA:1779 urn:ogf:network:es.net:2013:production:internalB:1779 urn:ogf:network:es.net:2013:production:internalC:1779 urn:ogf:network:es.net:2013:production:startap:star:1?vlan=1779 Based on this rule path finders can determine the ports are members of the bounded network and since the internal STP are unknown, pass all internal STP plus the boundary STP as an ERO to the uPA. The format of the internal STP's local part is left up to the managing network just so long as it does not violate the NURN character set. 3. A loose ERO is consider "loose" for two reasons: a) The ERO is not a complete end-to-end path when computed using the NML topology. For example: urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:icair.org:2013:topology:netherlight?vlan=1779 urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779 In this case the path finder will need to complete the path by selecting STP to filling in the gaps, specifically at the egress SDP on the ESnet/iCAIR segment. The egress STP on the iCAIR segment actually forces selection of a single STP on the ingress to Netherlight, but is still considered loose as the STP must be selected by the path finder. b) The ERO contains an underspecified STP. For example, the following STP are all under specified: i) Requires any STP from the range of 1779-1794 to be used in the reservation request. urn:ogf:network:icair.org:2013:topology:esnet?vlan=1779-1794 ii) Based on the EVTS service definition both these underspecified STP request any valid STP from the range 1779-1794,1797-1799. urn:ogf:network:icair.org:2013:topology:esnet?vlan urn:ogf:network:icair.org:2013:topology:esnet iii) When only the network identifier portion of the STP is provided it implies any valid STP within the network may be used. This underspecified STP format ill be utilized when a user would like a specific network to be used within the path. urn:ogf:network:icair.org:2013:topology For this case an ERO would be specified as follows: urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:icair.org:2013:topology urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779 iv) Should we support the ability to specify a network and label but not a specific STP? urn:ogf:network:icair.org:2013:topology?vlan=1779 3) If either a strict or loose ERO can not be satisfied the reservation request fails and a serviceException information is returned identifying the constant(s) that caused the failure. I assume I have missed some. Can anyone think of additional ones we would need to support? Thanks, John

3 4

NURN proposal
by Freek Dijkstra 21 Oct '14

21 Oct '14

Dear members of the NSI community, In last call, I promised you an alternative proposal for identifiers. Here it is. In addition, I've included a FAQ to explain the reasoning behind the current NURN (the urn:ogf:network identifiers). We have to change the currently used URNs, so my proposal is as follows: Encode the network identifier in the FQDN. E.g. currently (No Network ID in the NURN): urn:ogf:network:surfnet.nl:1990:port:surfnet6:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1 Uppsala proposal (Network ID in the OPAQUE part): urn:ogf:network:surfnet.nl:1990:surfnet6:port:production:2677 urn:ogf:network:es.net:2013:manlan:aofa:1 change it to: urn:ogf:network:surfnet6.surfnet.nl:1990:port:production:2677 urn:ogf:network:manlan.es.net:2013:aofa:1 My apologies for Submitting Yet Another Proposal, John. It is clear that the Uppsala proposal violates the GFD.202 standard (which states that the OPAQUE part of the NURN should not be interpreted), but it took me till this weekend to come up with a counter proposal that did not contain some other drawbacks. The advantage is that this proposal does not violate the existing NURN specification. It is actually possible to keep existing URNs the same, if so desired. I can't think of any disadvantages compared to the proposal that was put forward in Uppsala. That said, the two proposals still shares some disadvantages, but those are inherent to the choice on URNs for identifiers (as I said privately and publically earlier, in retrospect I think we should have chosen the Handle system instead of the URN system. That would have prevented us from re-inventing the idea of a document exchange service.) For those interested, I wrote the FAQ below to help me rethink this problem. FAQ # What is a NURN? NURN stands for "network URN". It is an identifier of the form urn:ogf:network:*. It is defined in GFD.202. # What is the syntax of a NURN? NURN = "urn:ogf:network:" ORGID ":" OPAQUE-PART *1QUERY *1FRAGMENT with ORGID, the ID of an assigning organisation. ORGID = FQDN ":" DATE # What are the properties of a URN? (and thus of a NURN)? * It is globally unique (no name collisions) * It is persistent (not re-used) * It is an identifier (without meaning) # What is an identifier? A label, without meaning, to uniquely identify something. It should not be confused with an address (which tells you where to find this thing) or a route (which tells you how to get there). # Why can't an identifier have a meaning? A resource has properties. If these properties are encoded in an identifier, the identifier is no longer persistent if these properties change. For example, the port number are properties that may change if you buy a new switch, and should in general not be part of an STP identifier. (You don't want to change STP just because you do some internal changes in the network that are irrelevant to your network peers). # Why is the local part OPAQUE? To prevent users from adding volatile properties to the identifier, or worse, parse the identifier to extract these properties, only to find out that the identifier object no longer holds these properties. # How is a NURN globally unique? To avoid global naming collisions, each entity that assigns URNs gets it's own prefix, the ORGID. Each entity (the assigning organisation) is responsible to avoid local naming collisions. # Who assigns ORGID prefixes? It is not assigned, it can be generated. Usually, a naming authority is established. For example, IANA is responsible for the "urn:" namespace, and OGF is responsible for the "urn:ogf:" delegated namespace. For "urn:ogf:network:", we didn't want to devise a new formal organisation within the OGF, which at the time was already in decline. So we decided to simply re-use an existing naming authority: DNS. # Why does ORGID contain a FQDN? We originally thought we could use this as a topology exchange system: given a NURN, find the FQDN, do a DNS lookup for the SRV record for the appropriate service, and fetch it from the returned URL. # Why does ORGID contain a DATE? We quickly got feedback for the IETF URN community that a DNS name is globally unique, but not persistent. It may change over time. To compensate, we simply added a DATE: the owner of a FQDN is unique for a given moment in time. This way we avoid naming conflicts, even if a DNS zone is transferred to a different owner. # What happened to the idea of the topology exchange using the FQDN? It became moot with the addition of the DATE, as the FQDN would no longer have to be unique. At the time, we thought this was good idea, as we liked the idea of an identifier with less meaning. See the question on "Why can't an identifier have a meaning" above. In retrospect, this should have been the time to look at other identifiers schemas which contain both properties: no meaning, and yet a lookup service (e.g. ARK or Handle). # But what's the meaning of the ORGID? Nothing. It has no meaning (anymore). It is just a unique prefix. It could have been randomly chosen. In retrospect, perhaps we should have used the SHA-2 of FQDN + DATE. In the above proposal, it would regain a meaning: that of the network identifier. # Why does the NURN currently not contain a Network ID? Because of flexibility requirements. At the time this was drafted, there was a need for subtopologies, merging of topologies, splitting of topologies, and the option of migrating STPs from one Topology to another (e.g. from the testbed to production). This is non-trivial with the current proposals (although I can think of some ways to add this functionality). # What's the disadvantage of the no-meaning doctrine? Well, since identifier have no meaning, any attributes and relations need to be made explicit. # Why not a hierarchical schema? We thought of a schema along the line of network_ID:node_ID:port_ID:link_ID, but decided against it, particular to avoid meaning in the URN. Such schema would disallow a multi-homed setup. Instead, we thought that a lookup system and explicit relation would be better. # Without a hierarchy, how to I know if two identifers are related? You don't. So it is fully possible in NML to create a two VLAN on a link and use two wildly different identifiers for the two VLANs. This is ugly indeed, but we though this disadvantage would be outweighed by the advantage of flexibility. # How to group two or more VLANs? Use a PortGroup or LinkGroup in NML. # How to select a VLAN in a group? Originally, this was very bad in NML. It entailled looking up the different Ports in a PortGroup, and checking the Label of each Port. This did not scale, as each identifier may be wildly different, so each network would have to publish a large Topology file. Instead, we used a trick: the query component. Just take the URN of the PortGroup, add a query component somehow selecting a specific Port within that group (e.g. by its label), and you have the right Port. # Is the query component part of a URN? Yes and No. No, it is not part of the PortGroup URN. Yes, it is part of the URN that 'selects' the Port URN from the PortGroup URN + Query component. It is not part of the Port URN. E.g. urn.ogf.network:example.net:2011:portgroup:312?vlan=42 may return urn.ogf.network:example.net:2011:port:312_42 # Are query coponents allowed in a URN? First of all, it can be argued that the query component is not formally part of the PortGroup URN, Not yet, but we expect it will be published shortly. https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn#section-4.3 # Why is there a vlan in the query component, not the label? This was not really thought-through. Pick your answer: - to allow for PortGroups with multiple labels (e.g. create a PortGroup with all VLANs in multiple WDM wavelength. You can now select the Port by VLAN + wavelength.) - this was a mistake, it should have been <portgroup ID>?label=<label> instead of <portgroup ID>?vlan=<label>. # What kind of lookup systems do exist? For URN, I'm only aware of Dynamic Delegation Discovery System (DDDS) (RFC 3402), but I haven't come accross any implementation. Handle has a lookup service. E.g. resolve 10.5240/5868-409E-7BFB-536A-6067-E (movie record), 10.1016/j.future.2006.03.007 (publication) or 11230/f461a01a-9254-11e3-ba1c-d89d6771dd88 (scientific data) at any of the existing lookup services. E.g. hdl.handle.net or dx.doi.org. I'm not familiar enough with ARK to know those lookup services. # Why a URN instead of Handle system? Because we made a mistake. # Why not the handle system after all? Every proposal in the NSI faces Much Discussion. I lost the energy. We're good at re-inventing the wheel. Let's continue doing that. -- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra(a)surfsara.nl | www.surfsara.nl | Available on Mon | Tue | Wed | Thu |

4 5

minutes from today's NSI meeting...
by Guy Roberts 15 Oct '14

15 Oct '14

.... are available here: https://redmine.ogf.org/dmsf_files/13366 _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK Office +44 1223 371316 Mobile +44 7881336417 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

The POODLE attack on SSLv3
by Henrik Thostrup Jensen 15 Oct '14

15 Oct '14

Hi Some of you have probably seen this: http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiti… As we have mandated use of TLS 1.0 (which is the successor to SSLv3), an NSI implementation should not be vulnerable. *** If you are responsible for an NSI implementation, please double check that SSLv3 is not allowed (the default contexts often allow this). *** AFAICT even NSI agents supporting SSLv3 are not vulnerable to the attack as we authenticate the client and do not use HTTP session keys (the POODLE attack uses single-byte leaking to grab a session key by inserting requests into a unencrypted side-channel and reusing it in a new session). Further, there is some rumor mongering concerning TLS 1.0/1.1 being disabled some places. These two have a lot of similarity to SSlv3, but are NOT vulnerable to the same attack. While I don't think they can be vulnarable to a similar attack (but I am not really qualified to guess), a lot of clever people will be looking into creating variants of this attack in the next months. So consider supporting TLS 1.2 sooner rather than later. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

1 0

Wednesday's NSI conf call
by Guy Roberts 14 Oct '14

14 Oct '14

The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 BST, 16:00 CEST, 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: - All to update their progress on NSI documentation - Review STPiD proposal from John _____________________________________________________________________ Guy Roberts PhD Senior Transport Network Architect DANTE Cambridge, UK Office +44 1223 371316 Mobile +44 7881336417 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] Meeting Minutes: October 8, 2014
by John MacAuley 14 Oct '14

14 Oct '14

All, I have attached a revised version of the minutes containing the updates to the URN proposal. John > > From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of John MacAuley > Sent: 14 October 2014 14:46 > To: NSI Working Group > Subject: Re: [Nsi-wg] Meeting Minutes: October 8, 2014 > > Thanks to Chin for noticing I missed the DATE component on: > > 3. urn:ogf:network:caltech.edu: > > Obviously, this should be urn:ogf:network:caltech.edu:2014: > > This gives me another example. I will update the text. > > Thanks, > John

1 0

Meeting Minutes: October 8, 2014
by John MacAuley 14 Oct '14

14 Oct '14

Attendees: Tomohiro Henrik Hans John Freek Chin Minutes: 1. Agreement was made to wait until after SC2014 for any planned URN conversions. 2. John presented a draft of the network and STP identifier proposal as discussed at the NORDUnet conference. An exciting discussion ensued with a heated debate. I have included below the revised proposal based on comments from the call. Please read it over to make sure we are in agreement. 3. Freek decided he would #SYAP (Submit Yet Another Proposal) for URNs to keep the local part opaque as per the NURN specification. He was thoroughly stoned by an agitated NSI working group. Proposal promised for Friday October 10th if he had recovered from the stoning. It has not come out so I guess he is still nursing his wounds. There were no new items so we ended the meeting. John REFERENCES [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141bis] Sait-Andre, P., "Uniform Resource Name (URN) Syntax", draft-ietf-urnbis-rfc2141bis-urn-07, January 2014 (Expired). [RFC5890] Klensin, j., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6453] Dijkstra, F., "A URN Namespace for the Open Grid Forum (OGF)", RFC 6453, December 2011. [GFD202] van der Ham, J., "A URN Namespace for Network Resources", GFD.202, April 2013. Network and STP identifier Syntactic Structure A network resource URN (NURN) identified by the "urn:ogf:network:" prefix is defined in [GFD202]. NSI utilizes NURN formatted URNs in the P2P service definition, and within NML topology describing NSI network constructs. The NSI Connection Service Protocol specification [OGF-NSI-CS] puts a specific requirement on the Service Termination Point Identifier (stpId), defining the stpId as a three-part identifier composed of a network identifier part, a local identifier part, and a qualifying label part: <STP identifier> ::= <networkId> “:” <localId> <label> <label> ::= “?” <labelType> “=” <labelValue> | “?”<labelType> | “” <labelType> ::= <string> <labelValue> ::= <string> To maintain syntactic correctness with the NURN specification such that an stpId is also a valid NURN formatted URN, we define a specific Augmented BNF [RFC 5234] to restrict the format of the NSI Network and STP identifiers such that they remain NURN compliant, but provide the needed imbedded structure for separating the networkId and localId components. To to do this we must also relax the following NURN restriction: "OPAQUE-PART is opaque, and must not be parsed or interpreted by any organization except for the organization that assigned the URN." NSAs within the connected control plane are permitted, when needed, to parse an NURN into component parts as defined below. NSAID = "urn:ogf:network:" ORGID ":" LOCALPART NETWORKID = "urn:ogf:network:" ORGID ":" LIMITEDLOCALPART STPID = NETWORKMEMBER SERVICEDOMAINID = NETWORKMEMBER SERVICEADAPTATIONID = NETWORKMEMBER SERVICEDEFINITIONID = NETWORKMEMBER ORGID = FQDN ":" DATE ; ID of assigning organisation FQDN = 1*(ALPHA / DIGIT / "-" / ".") ; Domain name DATE = YEAR *1(MONTH *1DAY) ; Date of creation of ORGID YEAR = 4DIGIT MONTH = 2DIGIT DAY = 2DIGIT LIMITEDLOCALPART = *(ALPHA / DIGIT / SYMBOL) ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 SYMBOL = "+" / "," / "-" / "." / ";" / "=" / "_" NETWORKMEMBER = NETWORKID ":" LOCALPART *1QUERY *1FRAGMENT ; LOCALPART = *(ALPHA / DIGIT / OTHER) OTHER = ALLOWED / EXTENSION ALLOWED = "+" / "," / "-" / "." / ":" / ";" / "=" / "_" EXTENSION = "!" / "$" / "(" / ")" / "*" / "@" / "~" / "&" QUERY = "?" *QFCHAR FRAGMENT = "#" *QFCHAR QFCHAR = ALPHA / DIGIT / OTHER The full length of an ID must not exceed 255 characters as defined in [GFD202]. ALLOWED and SYMBOL characters may be used for the assignment of NURNs. EXTENSION characters should not be used to assign NURNs. To allow for future extensions, parsers should accept NURNs with EXTENSION characters as per [GFD202]. The QUERY part is used by NSI to specify technology specific labels as part of the NURN as per [OGF-NSI-CS]. The FRAGMENT parts must not be present in any assigned NURN and is reserved for future standardization as per [GFD202]. An NURN must not contain percentage-encoded characters ("%" HEXDIG HEXDIG). It should also be noted that the following characters (which are either allowed by the URI or URN specification) must not be used in the LOCALPART or LIMITEDLOCALPART of an NURN: "%", "/", "?", "#", and "'". DOMAIN is a fully qualified domain name (FQDN) of the URN assigning organisation in LDR format [RFC5890]. Valid examples are example.net and example.xn--jxalpdlp. DATE is a date (either year, year+month or year+month+day). The combination of DOMAIN and DATE forms the organisation identifier, ORGID. Examples The following are examples of legal network identifiers: 1. urn:ogf:network:grnet.gr:2013:topology 2. urn:ogf:network:surfnet.nl:1990:production7 3. urn:ogf:network:caltech.edu: The following are examples of illegal network identifiers: 1. urn:ogf:network:es.net:2013 2. urn:ogf:network:cipo.rnp.br:2014 3. urn:ogf:network:example.net:2013:production:east In example #1 and #2 there is no following colon after the DATE component. This is required even when there is no LIMITEDLOCALPART. In example #3 the LIMITEDLOCALPART contains a colon ":" which is not a member of the character set. The following are examples of legal STP identifiers for a network identifier of "urn:ogf:network:example.net:2013:topology": 1. urn:ogf:network:example.net:2013:topology:CLIENT_port 2. urn:ogf:network:example.net:2013:topology:EAST_PORT_TO_CUSTOMER:in 3. urn:ogf:network:example.net:2013:topology:PORT+TO-CUSTOMER:east:bidirectional The following are examples of legal STP identifiers for a network identifier of "urn:ogf:network:example.net:2013:": 1. urn:ogf:network:example.net:2013::CLIENT_port 2. urn:ogf:network:example.net:2013::EAST_PORT_TO_CUSTOMER:in 3. urn:ogf:network:example.net:2013::PORT+TO-CUSTOMER:east:bidirectional The following are examples of illegal STP identifiers for a network identifier of "urn:ogf:network:example.net:2013:topology": 1. urn:ogf:network:example.net:2013:client_port 2. urn:ogf:network:example.net:2013::client_port 2. urn:ogf:network:example.net:2013:topology:client_port:xe-8/2/0:* In example #1 and #2 the network identifier's LIMITEDLOCALPART is missing from the STP identifier. In example #3 the "/" and "*" characters are illegal LOCALPART characters based on the NURN definition.

2 1