These responsibilities are inhenernt to every NSA though.   Tere are a couple issues here GiGi:

First, from the provider NSA's point of view, how does he know he is "the first" providerNSA?   The request that the provider receives is no different than the request(s) he will issue down the service tree.  So one has to ask the question of the NSA's receiving the "second Request" ...How do they know they are not the first?  ...   IMO, a provider NSA *generally* bears a responsibility to provide some response to the requester no matter what  level in the processing tree it occurs.  

As for translation from the user to NSI protocols, the NSI does not deal with that.  NSI *only* deals with the transactions between the requester NSA and the provider NSA  - by definition the NSI Protocol.   And there is no basis here for indicating that a request somehow is first in the service processing.

So while I whole heartedly endorse a requirement that the provider NSA is a one-stop shop for the request it receives, and must address that entire request as a unit, and respond likewise, I do not see any speacial responsibiliy in that for a "first" NSA.  

My recommendation is that the service request must receive one of the following responses:  1) Confirmed.  2) Rejected  3) Processing.  The Confirmed response should be obvious.  The Reject response would arise form a rejection of the resource constraints somewhere down the line - or a "not responding" timeout.   The "Processing" response says "I am getting responses back from my sub-requests, but I don't have them ALL just yet".  The "Processing" response is sent when a timeout occurs just to let the user know its still actively being pursued, albeit slowly.   If no  responses come back from downstream for a configured period of time, then the request has failed and a "reject" is returned with some sort of "timeout" response to the user.

This works for either tree or chain processing, and would apply for all (any) NSA request (i.e. it matters not if this is the first NSA or the 47th.)

Hope this makes sense...
Jerry
Gigi Karmous-Edwards wrote:
Hi Jerry,

I do think that the initial NSA provider bears some extra responsibility in replying back ....

Imagine a chain model where the request was made by a user and then somehow the messages got lost or never made it th the "next-hop" , there may be a case where the information back to the user is lost with no real "responsible party".  In my opinion, the initial NSA should carry a little extra of a load in this, after all, it is the point where translation from user request to network resource request occurs. The end user must have one point of contact for each request she or he makes. It will be very difficult for the user to keep up with all the other NSA-NSA calls that are made on behalf of the one request.

Thanks,
Gigi

-------- Original Message --------
Subject: Re: [Nsi-wg] Another NSI protocol requirement
Date: Sun, 14 Mar 2010 10:15:14 -0400
From: Jerry Sobieski <jerry@nordu.net>
To: gigi_ke@ncsu.edu <gigi_ke@ncsu.edu>
CC: NSI WG <nsi-wg@ogf.org>
References: <4B9CD3AE.10405@ncsu.edu>


Hi Gigi

Makes perfect sense!  I thought we had this already in one of the reqs. 

Issue:  the provider must always respond back. There is no "initial' NSA-NSA always thinks he is first/only NSA working on this request. 

J

Sent from my iPhone

On Mar 14, 2010, at 8:16 AM, Gigi Karmous-Edwards <gigi_ke@ncsu.edu> wrote:

All,

As I mentioned on the call last week, I think we need another NSI protocol requirement as following:

The provider agent involved in the initial NSI request from an NSI requesting agent  (in these cases, the requester agent acts as an end user or application), must take on the responsibility of replying back to the end user the result of the request. That is either a failure or success with the correct pointers or Global Identifiers. This needs to be true regardless of weather the initial provider agent uses chain or tree model to reserve a path.

This requirement will have implications on the intermediate messaging that take place between the requesting agents and provider agents along the path. I can also imagine that the messaging to uphold this requirement will be different for tree vs chain.

I hope this makes sense...

Kind regards,
Gigi
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg