[Nsi-wg] [Fwd: Re: Another NSI protocol requirement]
Gigi Karmous-Edwards
gigi_ke at ncsu.edu
Mon Mar 15 08:46:54 CDT 2010
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