[Nsi-wg] Some topology stuff for Glif
Henrik Thostrup Jensen
htj at nordu.net
Mon Sep 30 04:10:51 EDT 2013
Hi
Some notes from implementing NML, and some input for the topology
discussion at Glif.
There is no bandwdith/capacity attribute in NML. This means we cannot do
capacity matching in pathfinding Is this something we need? (insert usual
disclaimer about advertised bandwidth being different from avaible)
NML does not have anything to denote available service definitions - per
network or port. This again, makes pathfinding rather tricky and full of
assumptions. While one can match labels with labels used in a service
definition, there might be certain semantics which is not supported. Is
this something we need to add?
The NML model is quite different from the original network+port model of
NSI. The role of a topology corresponds roughly to a network, but this is
a restriction/policy that we have made (which I am perfectly fine with,
but we just need to be explicit about this). This also means the way NML
and NSI reference ports are different. In NSI we use a network id (which
maps to a topology in NML) and a local id which maps to a fully qualified
port name in NML, like this:
<sourceSTP>
<networkId>urn:ogf:network:aruba.net</networkId>
<localId>urn:ogf:network:aruba.net:ps</localId>
</sourceSTP>
In NML, one can reference ports directly, like this:
<nml:PortGroup id="urn:ogf:network:bonaire.net:bonaire.net:arb-in" />
There is something to be said for both models, but not really about having
both at the same. The network id in NSI is really redundant. I talked to
to John about this in Madrid, and while he agreed he just couldn't get
himself to remove (and I agree with this, the whole thing just feels so
goddamn clumsy). Right now we essentially have 1½ topology model. There
are some ways
Then there are some security aspects. How do I control that no one injects
services / topologies / servies into the topology? In OpenNSA, I do the
following in the configuration:
peers=example.org at http://example.org:9080/NSI/topology/example.org.xml
This enables me to check/filter for identifiers in the retrieved topology.
A basic way could be to match the hostname of the base identifier (like
nordu.net:2013) against a certificate (can the the one of the TLS session
or via a signed topology). However AFAICT, there is no way to establish
exactly what the base identifier is. Furthermore the certificate is not
likely to match the base identifier, e.g. nordu.net:2013 vs nsi.nordu.net.
The NML year model also falls somewhat apart here, as someone announcing
with a certain year would need to have a valid certificate for that year,
however certificates where the current time is not within the valid period
are by default invalid (and with good reason).
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet
More information about the nsi-wg
mailing list