No. This is a lousy time to unilaterally start adding new features! We only need topology for Rio. If we want to do a more complex topological process for the control plane, you should bring it to the working group. We don't want to confuse or add additional work for all the implementers now as we are headed to an interop. Please... Don't throw stuff into the Rio topology mods unless they are essential for Rio. If they are not essential for Rio, and not a part of the CS standard, take them offline as a personal project. I don't mean to be gruff here, but adding this stuff causes unnecessarily confusion and work. Thanks Jerry On 8/26/11 1:22 PM, John MacAuley wrote:
I put it in so we can start to try some intelligent routing of messages in a more complex NSA topology. I do not assume all NSAs are connected to all other NSAs since I do not think this will be true for anything other than our demo. Being able to build an NSA tree to determine message routing needs some investigation, and since this isn't covered by the NSI CS protocol, it is a good time to start investigating for the next version of the protocol. People can ignore it if they want but I am going to do some prototype code to use it.
John.
On 2011-08-26, at 11:23 AM, Jerry Sobieski wrote:
Hmm... Why the "connectedTo" for NSAs? This was something John mentioned and I don't understand. What does the connectedTo relation describe when between NSAs?? NSAs are control plane agents, and any NSA can contact any other NSA. This relation seems unnecessary for now, and until/unless we change the session model between NSAs.
??
Jerry
On 8/26/11 11:16 AM, Jeroen van der Ham wrote:
Hi,
I've updated the editor again, adding:
- connectedTo for NSAs (note that a top connectedTo blob only connects to a bottom connectedTo blob and vice versa) - contactInfo for NSAs - hasSTP to link NSNetworks and STPs (was added yesterday)
Jeroen.