1. Identifiers should not change. Otherwise the 'isAlias' connection between domains is not going to work.
I am not a big fan of this requirement. I have no issue if an identifier changes when a port changes a network. Part of the migration would be informing peers and end users of the change. The isAlias would be addresses as part of this migration. I understand what you are trying to achieve, but introducing the additional infrastructure overhead to do the location independent resolution may not be worth the effort. Of course, this is just my opinion and I would love if other people weighed in on the topic. On 2014-01-23, at 8:03 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
On 22-01-2014 23:13, John MacAuley wrote:
It looks like your proposal for STP resolution is based on an external lookup service instead of a parsable URN.
That is correct.
Do we think it wise to bring in a global lookup service to just resolve an STP to a network?
That's indeed the question.
So far I made two premises:
1. Identifiers should not change. Otherwise the 'isAlias' connection between domains is not going to work.
2. STP (and perhaps other resources) may migrate from one Topology to another. See the two use case in my previous email [*]
From this I reasoned that we need a lookup service (though 'global' can still mean distributed or delegated, just like DNS and Handle).
If you can convince me that either one of my premises is wrong, or that there are other solutions that can cope with these requirements, please do.
I think the reasoning by Henrik is that premise #2 is wrong.
What do you think?
Regards, Freek
[*] * NORDUnet: split one network in two (e.g. NORDUnet-West and NORDUnet-East) * SURFnet: move a port from the testbed to the production network
-- Freek Dijkstra | Group Leader & Network Expert | Infrastructure Services | SURFsara | | Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 | | Freek.Dijkstra@surfsara.nl | www.surfsara.nl |
Available on Mon | Tue | Wed | Thu | _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg