On 01-08-2012 17:52, Guy Roberts wrote:
I quote:
• NML group are not happy with rejection of their proposal to have unidirectional STPs only and bidirectional connections as a grouping of 2 unidirectional STPs. This will cause problems with mapping to NML and make mulit-point connections more difficult…. Most NSI wg participants prefer to keep bidirectional. Not resolution to this issue.
To clarify: I don't regard multi-point connects as a necessity, so that's not a problem to me. What is problematic is that NSI and NML (1) do not use the same identifier, and (2) even do not describe the same resources. This makes translations between the two not so much "problematic" but more "outright impossible". I do hope there is a way forward, but I do not see how with the current proposal, and I am not aware of anyone else who has a solution for this. This means that OGF will shortly produce two standards that are incompatible, and it is no longer possible to easily correlate the monitoring data to a provisioned path. I am very worried by this situation. Note that I am not saying that the NML proposal is the only solutions. In fact, the tuple (network URN, STP URN) is also in my opinion a "hack". However, given the requirements (NML compatible and possible to find the network for a given STP) this seemed the solution that had most support (I earlier mentioned other solutions, like a dynamic delegation discovery system, RFC 3402, but had the impression that that was deemed overly complex). I'm also happy to try to support any requirements NSI has in NML. Just as we did earlier by the introduction with the PortGroups, the addition of the alias relation, or the change in our proposal to map a STP to two instead on one unidirectional NML Ports so that the STP can remain bidirectional. I'm most willing to contribute to any solution, but with the current proposal I just don't see how. Regards, Freek