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
_______________________________________________