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