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