Hi
I've accumulated a bunch of issues that I've found with the NSI2 CS
protocol and NML toplogy, as I've worked with over the last years.
* Provision/Release/Terminate
At a point in time we removed the provisionFailed, releaseFailed, and
terminateFailed messages. I think this was with the reason that these
actions weren't really allowed to fail. This is mostly true, with the
exception that with security checks the requests can fail. There is no way
to signal this back to the client AFAICT.
* State machine
Due to the above issue, aggregators can be stuck in "Provisioning" and
"Releasing", with agents further down not wanting to move into
provisioning due to missing credentials. I have solved this by adding loop
transitions, so that the following are possible:
Provisioning -> Provisioning, on provision request
Releasing -> Releasing, on release request
A second issue is that on abort/timeout it is possible for the state
machine to enter a state where it is not possible to see if resources are
allocated or not (rather interesting, as this should really be the main
purpose of the state machine - I think we focussed to much in messages,
and not resource lifecycle).
I solved this by adding an internal flag to indicate if resources are
allocated or not.
* Security/Identity flaws
The NSA identities are not tied to subject names in X.509 certificates,
and there is no way to authenticate them. Inventing new ways of
identifying services/hosts that isn't strictly tied into a CA or DNS is a
bad idea.
The whole user/group/organization SAML thing we have is pretty much
useless as there is not good way to authenticate them. The only proper
security mechanisms I can see is X.509 certificates and tokens ala OAuth2.
* No notification mechanism
Notification are only provided the requester. All other have to issue
query calls. This makes it impossible to get continous updates (long poll
/ callbacks). This is very relevant for adminstration tools / portals.
* Security headers
Currently an NSI agent currently has to keep the body of the messages for
future inspection (query). Messages (mainly the http header or soap
header), can contain credentials such as tokens which should not be kept
after they have been verified. We need a statement saying that the HTTP
and SOAP header should be discarded. Ideally we just have a log of events,
and when they occured and who did it, instead of keeping full message
bodies.
* Single-label source/destination (and STPS)
The idea that source and destination should be modelled as STPs is
probably wrong. There is some impedance mismatch at least. If a flow comes
in with ethernet+vlan+mpls it should be modelled as such. Not just as
having a VLAN xor MPLS. This also makes adaptation quite tricky.
* Static Port List
The idea that we can list all ports in a network (NML or not) isn't
realistic. In GTS/GVS, VMs are spawned dynamically, creating a new
interface on the host machine. This is a new STP. Sure it will probably
get a VLAN on the circuit of the VM host, but the endpoint is a logical
interface, and can have labels on it, e.g. Q-in-Q where vlans of the VM
are connected to difference places. This means that topology should not
try and model all possible endpoints (because it can't), but only
nodes/domains and the connectivity between these.
* Unidirectional Circuits
I've helped a lot of sites getting OpenNSA up and running, and have
typically helped out with configuration, to get them up and runnign. The
most recurring issue is the topology configuration. In particular getting
the unidirectional ports right is the thing that almost always eats the
most time. This combined with the fact that no one uses undirectional
circuits means that we have a lot of complexity with zero benefits.
* Callbacks
This isn't really a design issue, but having SOAP and callbacks is just a
huge amount complexity for protocol and state keeping. It is immensely
error prone, and makes client implementations quite complicated which is
hinder usage tremendously. I've implemented a REST interface in OpenNSA.
It doesn't have 100% feature parity, but it implements additional
functionality like long-polling for noticiations and auto
provision/commit. The protocol stack is roughly 1/10 lines of code
compared to the SOAP interface.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet
