Aside from the snarky comments, I guess we agree that solution #3 is best from these listed solutions:
A path computation engine needs to know in which domain a STP lies.
There are solutions to this: 1. The domain can be inferred by parsing the URN identifier of the STP. 2. Each domain announces a full list of it's STPs, and the path computation engine keeps a table of all STP-Domain relations. 3. Each connection request must not only list the URN of the STP, but the URN of the domain as well.
There is an open questions which variant to use: A connection request must contain for each endpoint ... 3a. ... a globally unique identifier of the network (*) and a STP identifier that is unique within the context of this network. or 3b. ... a globally unique identifier of the network (*) and a globally unique STP identifier. For the record, ITU-T G.800 seems to follow 3a, while NML chose 3b. The reason for NML was that 3b removed the need for scopes -- so NML would also work in a scenario where the STP identifier is known, but the Topology (network) identifier is unknown. Arguably this leads to a bit of redundancy in the identifier in this use case. I nevertheless argue that it is useful to use the same identifier as NML uses. The alternative is either to maintain a NSI-NML identifier lookup table, or a proposal to the NML group to revert the earlier choice, along with a clear definition how to identify Ports, remembering that Ports can be identified both in the scope of a network, as well is scope of a device (without further knowledge of the network). Freek (*) I use the terms "topology", "network" and "domain" interchangeably in this email. I'm referring to the concept of NML Topology or NSI Network.