[Fwd: Re: Another NSI protocol requirement]
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@nordu.net> To: gigi_ke@ncsu.edu <gigi_ke@ncsu.edu> CC: NSI WG <nsi-wg@ogf.org> References: <4B9CD3AE.10405@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@ncsu.edu <mailto:gigi_ke@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@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
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@nordu.net> <mailto:jerry@nordu.net> To: gigi_ke@ncsu.edu <mailto:gigi_ke@ncsu.edu> <gigi_ke@ncsu.edu> <mailto:gigi_ke@ncsu.edu> CC: NSI WG <nsi-wg@ogf.org> <mailto:nsi-wg@ogf.org> References: <4B9CD3AE.10405@ncsu.edu> <mailto:4B9CD3AE.10405@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@ncsu.edu <mailto:gigi_ke@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@ogf.org <mailto:nsi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/nsi-wg
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@nordu.net> To: gigi_ke@ncsu.edu <gigi_ke@ncsu.edu> CC: NSI WG <nsi-wg@ogf.org> References: <4B9CD3AE.10405@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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@nordu.net> To: gigi_ke@ncsu.edu <gigi_ke@ncsu.edu> CC: NSI WG <nsi-wg@ogf.org> References: <4B9CD3AE.10405@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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@nordu.net> To: gigi_ke@ncsu.edu <gigi_ke@ncsu.edu> CC: NSI WG <nsi-wg@ogf.org> References: <4B9CD3AE.10405@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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
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@nordu.net> To: gigi_ke@ncsu.edu <gigi_ke@ncsu.edu> CC: NSI WG <nsi-wg@ogf.org> References: <4B9CD3AE.10405@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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
"Joan A. García-Espín" -
Gigi Karmous-Edwards -
Jerry Sobieski