[Nsi-wg] NSI Identifier format

[Freek Dijkstra]

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
-------------- next part --------------
Problem
=======

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.

Use cases
=========

* ...
* NORDUnet: split network in two parts with other Topology ID
* SURFnet: move a Port from testbed to production network
* ...

Assumptions
===========

The following proposals all make the following assumption:
* Port and Topology identifiers MUST use urn:ogf:network identifiers.

Proposal 1 (Henrik)
===================

          string rewrite               lookup in full table
Port ID ------------------> Topology ID ------------------> NSA URL
        (extract prefix and            (build by distribute
      add the word 'Topology')      reachability between peers)

Limitation of proposal 1:
* Port can't be placed in another Topology later
* Max 1 Topology ID per prefix (though it's possible to work around by further interpretation of the URN)
* All NSA need database with all Topology IDs
* Adds limitations on the syntax of URN:ogf:network identifiers (organisations can't freely pick their Topology ID)

Proposal 2 (Freek)
==================

             extract                   lookup service
Port ID ------------------> prefix ---------------------> NSA URL
                                  \ 
                                   \--------------------> Topology ID
                                   (lookup by prefix in
                                   global lookup service)
                                
Limitation of proposal 2:
* Port can't be placed in another Topology later
* max 1 NSA per prefix      (though 1 organisation can have multiple prefixes)
* max 1 Topology per prefix (though 1 organisation can have multiple prefixes)


Proposal 3 (Freek)
==================

             extract               lookup service                       lookup service
Port ID ----------------> prefix --------------------> Lookup Service -------------------> NSA URL
                                 (lookup by prefix in                \
                                global lookup service)                \------------------> Topology ID
                                                                   (lookup by Port ID in 
                                                                    home lookup service)

Note: this can be combined in 1 step if the global lookup service extracts the Port ID itself, and redirects to the home lookup service.

Limitation of proposal 3:
* Requires one lookup per Port ID, rather than one per prefix or per Topology.

Advantage of proposal 3:
* Easier to later extend for different (non urn:ogf:network) identifier, since only the global lookup service (gLS) needs to be updated, not all NSA.