Hi Jeroen The reason for changing the topology was a result of how we wanted the overall system to work, and then having the topology support that. Taking a step back, NSI is an extremely generic, policy-free protocol, that comes with little instructions for how things should work, i.e., how are requests broken up. It is essentially free-form wrt. control plane and data plane, tree or chain, breakup, no standard policy for what is allowed and not. This makes developing an NSA more complicated and makes a system significantly more complicated to reason about and debug. What we did was to restrict the behavior of the NSI agent in several ways, and specify a specific way the request breakout should work. This ties strongly into what we think is a reasonable service to provide to our customers and peers, along with what we are capable of operating. Unfortunately, these decisions are extremely difficult, if not impossible, to take in the NSI group. The changes we made to the topology was a result of how we wanted the overall system to work. We did not change topology, just because we didn't like it. /Henrik On Sat, 7 Dec 2013, Jeroen van der Ham wrote:
What I have trouble understanding is why you have chosen to change a working standardized system. As far as I know we have had two successful demonstrations at GLIF and SC this year, including distributed topology resources.
The only thing missing still is a lookup service, and/or distribution service.
I have not seen any compelling arguments why you would fly completely into the face of a working system.
I may have missed something, but I have also not seen any constructive discussion either in NSI or in NML on how to fix the NML-NSI topology definition so that we can meet the requirements you defined.
Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet