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
All, I had a long discussion with Chin on the request to bound internal topology element with the visible inter-domain STP (2a below). He has a specific customer requirement where they only want to specify a source STP and a single internal link, but do not care about the rest of the path used. This is done to manually guide traffic around different sides of a ring based on congestion. I was worried about the external AG path finder choosing a less than optimal path with a lack of internal topology knowledge. By forcing the specification of ingress and egress STP with the internal topology I thought we could avoid this issue. It will be up to local uPA policies to decide if a proposed ingress or egress STP is non-optimal for the internal topology provided, rejecting the reservation request with an STP unavailable serviceException to force the selection of an alternative STP. Revisiting the (2a) example to show Chin's user case, a user could specify the source and destination STP, plus a single internal topology element to guide the initial path: urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:es.net:2013:production:internalA:1779 urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779 The AG path finder would then be responsible for stitching together a proposed end-to-end path that interconnects networks "urn:ogf:network:es.net:2013:production" to "urn:ogf:network:netherlight.net:2013:production7". Another interesting side effect of this, and something I did not remember until after my discussion with Chin, is that none of the three STP listed above need to be in NML topology since the source and destination STP are UNI-N ports with no associated SDP. More path finding goodness. John On 2014-10-16, at 1:24 PM, John MacAuley <macauley@es.net> wrote:
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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi John, Not sure if this has been discussed before in the NSI WG. The ERO is a great way of specifying resources to be included in the path, but is there also a way of specifying resources to be excluded from a path? I'm thinking about the avoidance of specific peering points or maybe whole domains for example. Cheers, HansT. On 17/10/14 17:05, John MacAuley wrote:
All,
I had a long discussion with Chin on the request to bound internal topology element with the visible inter-domain STP (2a below). He has a specific customer requirement where they only want to specify a source STP and a single internal link, but do not care about the rest of the path used. This is done to manually guide traffic around different sides of a ring based on congestion.
I was worried about the external AG path finder choosing a less than optimal path with a lack of internal topology knowledge. By forcing the specification of ingress and egress STP with the internal topology I thought we could avoid this issue. It will be up to local uPA policies to decide if a proposed ingress or egress STP is non-optimal for the internal topology provided, rejecting the reservation request with an STP unavailable serviceException to force the selection of an alternative STP.
Revisiting the (2a) example to show Chin's user case, a user could specify the source and destination STP, plus a single internal topology element to guide the initial path:
urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:es.net:2013:production:internalA:1779 urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779
The AG path finder would then be responsible for stitching together a proposed end-to-end path that interconnects networks "urn:ogf:network:es.net:2013:production" to "urn:ogf:network:netherlight.net:2013:production7".
Another interesting side effect of this, and something I did not remember until after my discussion with Chin, is that none of the three STP listed above need to be in NML topology since the source and destination STP are UNI-N ports with no associated SDP. More path finding goodness.
John
On 2014-10-16, at 1:24 PM, John MacAuley <macauley@es.net <mailto:macauley@es.net>> wrote:
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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hans, The ERO itself is very basic with no extension capabilities, so I do not think we can use it for exclusions. There are two options we can look at to achieve this capability. The first is to use the P2PServiceBaseType "<parameter>" element to come up with an attribute encoding for exclusions within the reservation request. The second option would be for us to define a generic excludes element for inclusion into P2PServiceBaseType <any ##other> element. We would need the ability to not only exclude STP and networks, but other routable attributes we have discussed in the past like SRLG values. John On 2014-10-20, at 8:02 AM, Hans Trompert <hans.trompert@surfnet.nl> wrote:
Hi John,
Not sure if this has been discussed before in the NSI WG. The ERO is a great way of specifying resources to be included in the path, but is there also a way of specifying resources to be excluded from a path? I'm thinking about the avoidance of specific peering points or maybe whole domains for example.
Cheers, HansT.
On 17/10/14 17:05, John MacAuley wrote:
All,
I had a long discussion with Chin on the request to bound internal topology element with the visible inter-domain STP (2a below). He has a specific customer requirement where they only want to specify a source STP and a single internal link, but do not care about the rest of the path used. This is done to manually guide traffic around different sides of a ring based on congestion.
I was worried about the external AG path finder choosing a less than optimal path with a lack of internal topology knowledge. By forcing the specification of ingress and egress STP with the internal topology I thought we could avoid this issue. It will be up to local uPA policies to decide if a proposed ingress or egress STP is non-optimal for the internal topology provided, rejecting the reservation request with an STP unavailable serviceException to force the selection of an alternative STP.
Revisiting the (2a) example to show Chin's user case, a user could specify the source and destination STP, plus a single internal topology element to guide the initial path:
urn:ogf:network:es.net:2013:production:ps:sunn:1?vlan=1779 urn:ogf:network:es.net:2013:production:internalA:1779 urn:ogf:network:netherlight.net:2013:production7:dlp01?vlan=1779
The AG path finder would then be responsible for stitching together a proposed end-to-end path that interconnects networks "urn:ogf:network:es.net:2013:production" to "urn:ogf:network:netherlight.net:2013:production7".
Another interesting side effect of this, and something I did not remember until after my discussion with Chin, is that none of the three STP listed above need to be in NML topology since the source and destination STP are UNI-N ports with no associated SDP. More path finding goodness.
John
On 2014-10-16, at 1:24 PM, John MacAuley <macauley@es.net> wrote:
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
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi On Thu, 16 Oct 2014, John MacAuley wrote:
1. A strict ERO for this path would be the following (from source to destination):
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).
+1
2. A ERO with internal topology not contained in NML:
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.
This seems overly restrictive, but AFAICT you have already made a counter-argument for this in the follow-up email. It could be used for specifying usage over an internal project-specific link[
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:
When are STPs allowed not to follow the standard STP format. That seems a bit weird.
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:
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.
+1 (but is is very loose restriction (pardon the pun) )
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.
IMHO an underspecified STP is not enough to call the ERO loose. It still has to follow the path, it is mainly a question on how things are labelled in transit.
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
I think I am okay with this. Do we require STPs supporting the EVTS service to be marked with labels? (I hope the answer is yes, and then I reckon it should be okay)
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.
If we have the ability of specifying networks (which is okay), does that mean that it exludes other networks if the networks can are connected in the order? Specifying that these networks have to be crossed is not particularly useful in itself IMHO. I could see this being useful as mechanism to direct the circuit through certain networks, and hence excluding all other networks.
iv) Should we support the ability to specify a network and label but not a specific STP?
I completely fail to see the usefulness of this. (Assuming all networks can do label swapping, if not it can be usefull, but it is still weird).
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?
My main concern is that we are starting to have a lot of options for the workflow in setting up a circuits. Combine EROs with chain and tree, and path finders are starting to become quite complicated (and pathfinders do not have be complicated, they can be quite simple actually). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (3)
-
Hans Trompert -
Henrik Thostrup Jensen -
John MacAuley