Freek,
Given a Port identifier, a NSA wants to figure out in which Topology this Port is located, and what the NSA is for this Port identifier.
Being a perfectionist I would like to generalize the problem statement to include any identifier. But I understand the NSI-CS only requires extracting the containing networkId of an STP from the STP. It looks like your proposal for STP resolution is based on an external lookup service instead of a parsable URN. Do we think it wise to bring in a global lookup service to just resolve an STP to a network? John On 2014-01-22, at 10:45 AM, Freek Dijkstra <Freek.Dijkstra@surfsara.nl> wrote:
Hi John,
NSI has the requirement that the networkId of a resource must be parseable from the resource identifier.
I don't think this is a requirement. In this email, I'm going to: I. Try to clarify your proposal. II. Suggest what should be the question/discussion. III. Conclude that we can keep the current identifier, regardless of the answer.
What's not in this email is the solution that solves our problems, sorry about that.
I.
<NML identifier> ::= <prefix> ":" <organization> ":" <opaque-stuff> <NSI identifier> ::= <prefix> ":" <organization> ":" <type> ":" <opaque-stuff>
Right now NSI and NML uses a schema like this:
<network id="some-opaque-urn">
What you are proposing is something like this:
<resource id="network:rest-of-the-identifier">
I don't see the advantage of your proposal. The change seems syntactical only. Am I missing something?
II.
This discussion was in the wake of a discussion on topology discovery. I think the following question needs to be answered first:
Is there a fixed or loose relation between a network and resource?
In other words, is there any use case where a STP (or other resource) can be moved from one Topology to another Topology?
The use cases mentioned at OGF40 where: * NORDUnet: split one network in two (e.g. NORDUnet-West and NORDUnet-East) * SURFnet: move a port from the testbed to the production network
In the current NML schema and identifiers, there is a loose relation. If this is the requirements, we must find a good way to distribute these relations in a scalable way. (The previously proposed lookup-service may be part of the solution here, but it is unclear how well this scales)
If the requirement is that this relation is fixed, clearly it is best that is possible to find the network by just looking at the resource ID. i think that can work with both existing and your proposal:
<NML identifier> ::= <prefix> ":" <organization> ":" <opaque-stuff> <NSI identifier> ::= <prefix> ":" <organization> ":" <type> ":" <opaque-stuff>
In either case, you can extract the organization identifier. While I am aware that organization ≠ network, if the relations are strict, I think we can actually use this organization ID for path finding and topology distribution.
III.
In either case, regardless if there a fixed or loose relation between a network and resource, I don't see how a new URI syntax does not seem to fix the actual problem.
The actually problem seems to be a choice between flexibility and scalability.
I don't have a solution that provides both. So the best way forward is to clearly describe the proposals we have. I sent a (very short) draft of three proposals to Henrik last week. It is attached for your reference. I hope we can use this as a basis to discuss the merits of the different proposals.
Regards, Freek <20140115 NML-WG identifiers.txt>_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg