Now to respond intelligently to the substance of the concept...:-)

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.

All *NSAs* will be connected to all other NSAs...Just as any IP address can connect (in principle) to any other IP address.   Whether an NSA accepts a request is a different issue. This is policy, not message routing.

Currently, NSI message routing follows the service tree...period.   There are no intermediate NSAs.   We have not stipulated any reqirement for how an NSA chooses the next NSA it contacts to progress a service request (Indeed, we have always stated that tree or chain was a local decision, and so likewise would be which NSA to use.) A particular segmentation does not dictate a particular service tree, but a service tree is *always* constructed, and it reflects the local hop by hop policy decisions of each NSA down the tree.

So, if one wants to find the source of a *request*, one can still climb the service tree with proper credentials and discover the ultimate RA.

However, if in practice we think that a given NSA will only be willing to accept and handle service requests from a finite subset of clients [NSAs] (which I think is entirely likely), then one can also expect many NSAs will not be able to forward requests directly to the NSAs along their desired [global] path - and these will need an intermediary.   I.e. If every NSA in the world does not authorize on "jerry@nordu.net", then I need to know where to send requests that will result in the connection being made.    I need a "default NSA" for my NSI service requests. Or a set of NSAs to use under different conditions.

It sounds to me as if you want to indicate some sort of NSI message routing policy... I.e. Under these conditions, send requests to this NSA, under those conditions, send a request to that NSA. A sort of service request routing table. Is this what you mean above?
I still believe this a local implementation issue and does not affect NSI, and so need not be part of the interdomain topology.

Its an interesting discussion. Want to elaborate more on what you have in mind?

Thanks
Jerry

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.