[Nsi-wg] [Fwd: Re: Another NSI protocol requirement]

[Jerry Sobieski]

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 at nordu.net> <mailto:jerry at nordu.net>
> To: 	gigi_ke at ncsu.edu <mailto:gigi_ke at ncsu.edu> <gigi_ke at ncsu.edu> 
> <mailto:gigi_ke at ncsu.edu>
> CC: 	NSI WG <nsi-wg at ogf.org> <mailto:nsi-wg at ogf.org>
> References: 	<4B9CD3AE.10405 at ncsu.edu> <mailto:4B9CD3AE.10405 at 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 at ncsu.edu 
> <mailto:gigi_ke at 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 at ogf.org <mailto:nsi-wg at ogf.org>
>> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20100314/fed7f529/attachment.html