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

Gigi Karmous-Edwards gigi_ke at ncsu.edu
Mon Mar 15 12:26:11 CDT 2010 

Yes Joan, this is what I think as well. This is also why I think the 
tree mode will be simpler to accomplish than the chain ( not to say we 
should not do the chain). There is a difference specifically when it 
comes to these security and NSI "session" issues.

Gigi

Joan A. García-Espín wrote:
> My view:
>
>> 1) will the user will expect a reply from any NSA, not necessarily 
>> the first NSA?
>
> In any case, the user has to get a "service id" in order to be able to 
> manage the service afterwards. So: a tentative answer is not 
> "necessarily the first NSA" as far as the user gets back the service 
> id., but we must be aware that this generates a huge impact on the 
> security connotations and, thus, the implementation of the user 
> identification and security infrastructure, as you already mentioned.
> On the other hand, NSA needs a mechanism (hand-shake?) in order to 
> decide when a given service is "confirmed". The way to implement this 
> complicates a lot if first NSA != NSA responding to the user, unless 
> some asynchronous notification infrastructure is built. In this case, 
> a synchronous implementation would be difficult, and systems operating 
> this way may not consider implementing NSI. Please correct me if I'm 
> wrong.
>
> To sum up, first NSA == responding NSA eases a lot NSI's protocol life.
>
> regards,
> -- 
> Joan A. García-Espín
> CTX, i2CAT Foundation
>
>
>
>
>
> El 15/03/2010, a las 14:46, Gigi Karmous-Edwards escribió:
>
>> HI All,
>>
>> Yes, I agree with many of Jerry's points.... Thank you for your 
>> thoughtful explanations.
>>
>> One thing I still question is : 1) will the user will expect a reply 
>> from any NSA, not necessarily the first NSA? or  2) will the replies 
>> go back up the chain to the original NSA provider for the reply back 
>> to the user?
>> If  # 2 is the case, I will assume that the first NSA will continue 
>> to reply back "processing" until a final outcome gets rippled back to 
>> it.
>>
>> If #1 is the case, will the NSI messaging contain the appropriate 
>> information for another NSA to connect to and contact the end user 
>> about the request? What if the end user does not have a trust 
>> relationship with one of the NSAs down the path, lets say NSA #47 (as 
>> in your example) but  NSA  #46 does have that trust relationship.... 
>> how will the end user receive the appropriate reply.
>>
>> I apologize for this back and forth but I do believe that these are 
>> important issues for the NSI protocol.
>>
>> Kind regards,
>> Gigi
>>
>> Joan A. García-Espín wrote:
>>> 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
>>>
>

More information about the nsi-wg mailing list