[Nsi-wg] NSI Identifier format

[John MacAuley]

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 at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg