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

Mon Mar 15 05:52:57 CDT 2010

Hi Gigi, Jerry, all,

I pretty much agree with Jerry's comments: NSA should be unaware of  
their position in the service plane as a whole* in order to allow high  
modularity and easy re-planning of the service plane; although a given  
implementation may make them aware of it for specific purposes or  
optimisation, but not as a general rule.

In any case, a response is needed. The question, in my viewpoint, is  
the level of details to be included in the response. From the app  
side, is it good to have a detailed response? What must be included  
there? Did you also have this in mind, Gigi? Jerry's suggestion is a  
good basis and it is not blocking either synchronous or asynchronous  
messaging implementations.

* Although local awareness is needed. Note that this does not mean  
that they don't know who they are and what their role is w.r.t. their  
neighbours.

My best regards,
--
Joan A. García-Espín
CTX, i2CAT Foundation

El 14/03/2010, a las 16:48, Jerry Sobieski escribió:

> 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>
>> To:
>> gigi_ke at ncsu.edu <gigi_ke at ncsu.edu>
>> CC:
>> NSI WG <nsi-wg at ogf.org>
>> References:
>> <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> 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
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg