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