[Nsi-wg] NSI specific topology recommendation for plug fest.

[Jerry Sobieski]

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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110826/fb31c3c9/attachment.html