[Nsi-wg] [Fwd: Re: Another NSI protocol requirement]
"Joan A. García-Espín"
joan.antoni.garcia at i2cat.net
Mon Mar 15 09:31:39 CDT 2010
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