Peoples, Can I propose we support three Query operation types? Currently we have two (Summary and Details) or which no one has implemented the recursive Details. I think we should revise the definition to the following: Summary - Will query reservation summary information held in the target NSA only. Details - Will query reservation detailed information held in the target NSA only. This will include child NSA connection segment information (new connectionId, path segment, etc.) and the target NSA's version of the connection segment state. Recursive - Will perform a recursive query to build detailed reservation information for all child NSA involved in the connection path. Sound good? John.
Ooops, used the wrong e-mail address. Dang Mac Mail. On 2012-05-16, at 11:16 AM, MacAuley, John (John) wrote:
Peoples,
Can I propose we support three Query operation types? Currently we have two (Summary and Details) or which no one has implemented the recursive Details. I think we should revise the definition to the following:
Summary - Will query reservation summary information held in the target NSA only.
Details - Will query reservation detailed information held in the target NSA only. This will include child NSA connection segment information (new connectionId, path segment, etc.) and the target NSA's version of the connection segment state.
Recursive - Will perform a recursive query to build detailed reservation information for all child NSA involved in the connection path.
Sound good?
John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Johns Why differentiate between a "detailed" query and a "recursive" query? They return the same thing. If you only want detail to a particular level, then put a depth parameter on the Query so that it knows to only go so deep recursively. If you only want detail from a single NSA, depth=0 (or 1 depending on how you want to interpret it). The recursion stops when the stack gets so deep. Are you planning to walk the tree yourself? The reason we defined the recursive query was that the notion of walking the tree via independent agent got roundly criticized in Salt Lake City - no one wanted to do that. People were upset that they would have to work to get path information. So we landed on a recursive query where authorization would follow the same criteria down the tree and the whole result would be returned with one pretty bow on it. J On 5/16/12 11:16 AM, MacAuley, John (John) wrote:
Peoples,
Can I propose we support three Query operation types? Currently we have two (Summary and Details) or which no one has implemented the recursive Details. I think we should revise the definition to the following:
Summary - Will query reservation summary information held in the target NSA only.
Details - Will query reservation detailed information held in the target NSA only. This will include child NSA connection segment information (new connectionId, path segment, etc.) and the target NSA's version of the connection segment state.
Recursive - Will perform a recursive query to build detailed reservation information for all child NSA involved in the connection path.
Sound good?
John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
The summary query as defined returns the globalReservationId, connectionId, connectionState, path, and some of the other reservation information. This is fine for a Requester Agent that just wants to see the current status of the reservation. Basically, it can determine the current state of the connection as understood by the Provider NSA. The existing detailed query does the recursive traversal of the reservation tree with each NSA populating its view of the reservation. Remember that each NSA has a completely different set of connectionIds for the overall reservation, which each NSA will put into the query response as it goes up the tree. Your comment of the summary query being a depth=0 is true, and the detailed (recursive) query is depth=n where n is the number of NSA in the longest branch of the reservation tree. When I say "Will query reservation detailed information held in the target NSA only. This will include child NSA connection segment information (new connectionId, path segment, etc.) and the target NSA's version of the connection segment state." I do not mean a detailed (recursive) query of depth=1. I still mean depth=0, but we want to return the connectionId information the provider NSA created when fanning the connection segments out to the children NSA. This is not returned in the summary query, but is important if someone wants to walk the tree. I could put this information in the summary query, but I thought keeping it lean would be better idea. John On 2012-05-16, at 4:47 PM, Jerry Sobieski wrote:
Johns
Why differentiate between a "detailed" query and a "recursive" query? They return the same thing. If you only want detail to a particular level, then put a depth parameter on the Query so that it knows to only go so deep recursively. If you only want detail from a single NSA, depth=0 (or 1 depending on how you want to interpret it). The recursion stops when the stack gets so deep.
Are you planning to walk the tree yourself? The reason we defined the recursive query was that the notion of walking the tree via independent agent got roundly criticized in Salt Lake City - no one wanted to do that. People were upset that they would have to work to get path information. So we landed on a recursive query where authorization would follow the same criteria down the tree and the whole result would be returned with one pretty bow on it.
J
On 5/16/12 11:16 AM, MacAuley, John (John) wrote:
Peoples,
Can I propose we support three Query operation types? Currently we have two (Summary and Details) or which no one has implemented the recursive Details. I think we should revise the definition to the following:
Summary - Will query reservation summary information held in the target NSA only.
Details - Will query reservation detailed information held in the target NSA only. This will include child NSA connection segment information (new connectionId, path segment, etc.) and the target NSA's version of the connection segment state.
Recursive - Will perform a recursive query to build detailed reservation information for all child NSA involved in the connection path.
Sound good?
John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
hi john ...thanks for the additional detail. i still dont quite understand why the detail query with recursion limit would not return the same information as the target only version? If the detailed query is not returning some tidbit of information, it seems to me it should be...detailed query was intended to reveal all with appropriate auth. IMO, a detailed query will roll up *everything* the receiving NSA lnows about a connection. everything. ! then if depth is greater than zero, it will decrement depth and issue detailed queries to each child. It will roll up everything it learns from the children and return the whole bundle to the requester. It sounds like the target only query is (or should be) just a short circuited degenerate case of the detailed query...? eh? j Sent from my iPad3g On May 16, 2012, at 10:49 PM, John MacAuley <john.macauley@surfnet.nl> wrote:
The summary query as defined returns the globalReservationId, connectionId, connectionState, path, and some of the other reservation information. This is fine for a Requester Agent that just wants to see the current status of the reservation. Basically, it can determine the current state of the connection as understood by the Provider NSA.
The existing detailed query does the recursive traversal of the reservation tree with each NSA populating its view of the reservation. Remember that each NSA has a completely different set of connectionIds for the overall reservation, which each NSA will put into the query response as it goes up the tree.
Your comment of the summary query being a depth=0 is true, and the detailed (recursive) query is depth=n where n is the number of NSA in the longest branch of the reservation tree.
When I say "Will query reservation detailed information held in the target NSA only. This will include child NSA connection segment information (new connectionId, path segment, etc.) and the target NSA's version of the connection segment state." I do not mean a detailed (recursive) query of depth=1. I still mean depth=0, but we want to return the connectionId information the provider NSA created when fanning the connection segments out to the children NSA. This is not returned in the summary query, but is important if someone wants to walk the tree.
I could put this information in the summary query, but I thought keeping it lean would be better idea.
John
On 2012-05-16, at 4:47 PM, Jerry Sobieski wrote:
Johns
Why differentiate between a "detailed" query and a "recursive" query? They return the same thing. If you only want detail to a particular level, then put a depth parameter on the Query so that it knows to only go so deep recursively. If you only want detail from a single NSA, depth=0 (or 1 depending on how you want to interpret it). The recursion stops when the stack gets so deep.
Are you planning to walk the tree yourself? The reason we defined the recursive query was that the notion of walking the tree via independent agent got roundly criticized in Salt Lake City - no one wanted to do that. People were upset that they would have to work to get path information. So we landed on a recursive query where authorization would follow the same criteria down the tree and the whole result would be returned with one pretty bow on it.
J
On 5/16/12 11:16 AM, MacAuley, John (John) wrote:
Peoples,
Can I propose we support three Query operation types? Currently we have two (Summary and Details) or which no one has implemented the recursive Details. I think we should revise the definition to the following:
Summary - Will query reservation summary information held in the target NSA only.
Details - Will query reservation detailed information held in the target NSA only. This will include child NSA connection segment information (new connectionId, path segment, etc.) and the target NSA's version of the connection segment state.
Recursive - Will perform a recursive query to build detailed reservation information for all child NSA involved in the connection path.
Sound good?
John. _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Wed, 16 May 2012, MacAuley, John (John) wrote:
Can I propose we support three Query operation types? Currently we have two (Summary and Details) or which no one has implemented the recursive Details. I think we should revise the definition to the following:
I'm going to make a bold claim here: 19 out 20 queries will be for status retrieval. However that is very easy to extract from a query containing all the local information, so I don't really see the value of "give me some of the local information" vs. "give me all the local information". Just give it all, and I can extract what I need. On a side note: I have intended to look at the queryresult types before suggesting this, but haven't gotten around to it: Are the two query result types so different that they couldn't be one? (making the tree optional). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Agreed.
I'm going to make a bold claim here: 19 out 20 queries will be for status retrieval. However that is very easy to extract from a query containing all the local information, so I don't really see the value of "give me some of the local information" vs. "give me all the local information". Just give it all, and I can extract what I need.
On 2012-05-18, at 6:02 AM, Henrik Thostrup Jensen wrote:
On Wed, 16 May 2012, MacAuley, John (John) wrote:
Can I propose we support three Query operation types? Currently we have two (Summary and Details) or which no one has implemented the recursive Details. I think we should revise the definition to the following:
I'm going to make a bold claim here: 19 out 20 queries will be for status retrieval. However that is very easy to extract from a query containing all the local information, so I don't really see the value of "give me some of the local information" vs. "give me all the local information". Just give it all, and I can extract what I need.
On a side note: I have intended to look at the queryresult types before suggesting this, but haven't gotten around to it: Are the two query result types so different that they couldn't be one? (making the tree optional).
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Forgot to answer this question. Yes they could if we are now including the local information. The question is does each NSA put in its full connection map, then let the child NSA do the same thing which will result in duplicate information? For example: Parent populates: {ConnectionId=A1, Provisioned {connectionId=B1, Provisioned}, {connectionId=C1, Provisioned }} Then the children populate: {ConnectionId=B1, Provisioned {connectionId=B2, Provisioned}, {connectionId=B3, Provisioned }} {ConnectionId=C1, Provisioned {connectionId=C2, Provisioned}, {connectionId=C3, Provisioned }} On 2012-05-18, at 6:02 AM, Henrik Thostrup Jensen wrote:
On a side note: I have intended to look at the queryresult types before suggesting this, but haven't gotten around to it: Are the two query result types so different that they couldn't be one? (making the tree optional).
On Fri, 18 May 2012, John MacAuley wrote:
Forgot to answer this question. Yes they could if we are now including the local information. The question is does each NSA put in its full connection map, then let the child NSA do the same thing which will result in duplicate information?
Interesting point. However is this really duplicate information? Each state represents what an NSA things about the state, making this usefull for detecting state skew betwen NSAs. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Actually, I think the form John proposed is good. I don't think some redundant state returned is an issue if it simplifies the protocol, and it could be very useful for debugging things like state machine problems or for possible recovery processes when an NSA has been offline. My only concern is that we preserve the authorization aspects. Specifically, as I see it, there are/should be only two levels of information regarding any connection instance: a) "summary information" that reflects user specified constraints and which the user/requester is entitled to know, and b) "detail information" that the provider defines and the provider is entitled to control or limit. The PA should have the option to keep detail info private - or to expose those details selectively to agents it trusts (for example authorized monitor agents) I think the detail information is a super set of the summary information. Thus a authorized detail query should be able to include summary information. So, a Detailed query processing would check authorization as follows at each NSA: If the request presents authorized high level credentials and depth is greater or equal to zero, the local detail info is releaseed and formatted. If depth is non-zero, the depth is decremented and a detailed query is sent to the children and the childrens' responses are formatted for release. The request returns upward. If the credentials fail high level auth, they are checked against low level authorization, if they pass low level authorization then only summary info is released and formatted, no additional recursion occurs, and the request returns up the tree. If the credentials fail both high and low authorization, the request is rejected and no information is released. A Summary request is different than a Detailed request in that only summary information is *ever* returned, thus only a low level authorization check is ever made. There is no recursion for a summary request. Thoughts? J On 5/18/12 9:29 AM, Henrik Thostrup Jensen wrote:
On Fri, 18 May 2012, John MacAuley wrote:
Forgot to answer this question. Yes they could if we are now including the local information. The question is does each NSA put in its full connection map, then let the child NSA do the same thing which will result in duplicate information?
Interesting point. However is this really duplicate information? Each state represents what an NSA things about the state, making this usefull for detecting state skew betwen NSAs.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Second reply to this one :-) On Fri, 18 May 2012, John MacAuley wrote:
Forgot to answer this question. Yes they could if we are now including the local information. The question is does each NSA put in its full connection map, then let the child NSA do the same thing which will result in duplicate information? For example: Parent populates:
{ConnectionId=A1, Provisioned {connectionId=B1, Provisioned}, {connectionId=C1, Provisioned }}
Then the children populate: {ConnectionId=B1, Provisioned {connectionId=B2, Provisioned}, {connectionId=B3, Provisioned }} {ConnectionId=C1, Provisioned {connectionId=C2, Provisioned}, {connectionId=C3, Provisioned }}
I (OpenNSA) doesn't keep track of the state for sub connections. This may sound counter-intuitive, but trying to keep track of that is actually a bloody mess (I did that initially). One only needs to track the reply from the last request and then update the connection state accordingly. If you have seperate state machines (aggregator and ultmate provider) the concept of keeping track of subconnection states falls to the ground immediately. I _really_ don't think we should have the state of sub connections. In fact, I cannot see how our protocol can support this. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hmmm...maybe I don't understand what was being described... I would think that an NSA would keep a connection state for each reservation request it received from an RA ( "parent" reservations), and each child they spawned as a result (including a local segment as a child). So each NSA maintains state only for requests in which it is directly involved as PA or RA. Any state associated with grand children or grandparents is superfluous and (IMO) unnecessary. And siblings are only known by the common parent - siblings do not know of each other. As for John's nomenclature- I thought that was just a description of how the results of a recursive detailed Query were rolled up recursively and passed up the tree in a comprehensive result. ??? J On 5/18/12 9:53 AM, Henrik Thostrup Jensen wrote:
Second reply to this one :-)
On Fri, 18 May 2012, John MacAuley wrote:
Forgot to answer this question. Yes they could if we are now including the local information. The question is does each NSA put in its full connection map, then let the child NSA do the same thing which will result in duplicate information? For example: Parent populates:
{ConnectionId=A1, Provisioned {connectionId=B1, Provisioned}, {connectionId=C1, Provisioned }}
Then the children populate: {ConnectionId=B1, Provisioned {connectionId=B2, Provisioned}, {connectionId=B3, Provisioned }} {ConnectionId=C1, Provisioned {connectionId=C2, Provisioned}, {connectionId=C3, Provisioned }}
I (OpenNSA) doesn't keep track of the state for sub connections. This may sound counter-intuitive, but trying to keep track of that is actually a bloody mess (I did that initially).
One only needs to track the reply from the last request and then update the connection state accordingly. If you have seperate state machines (aggregator and ultmate provider) the concept of keeping track of subconnection states falls to the ground immediately.
I _really_ don't think we should have the state of sub connections. In fact, I cannot see how our protocol can support this.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
I do track the states against each since they indicate the messages outstanding and what has been received. For example, the reserving state indicates I have sent a message to the child NSA and am waiting for the reserveConfirmed message. Effectively, you are doing the same thing by waiting for a specific message. Once all children are in the reserved stateI can send back a reserveConfirmed to my parent. John On 2012-05-18, at 9:53 AM, Henrik Thostrup Jensen wrote:
Second reply to this one :-)
On Fri, 18 May 2012, John MacAuley wrote:
Forgot to answer this question. Yes they could if we are now including the local information. The question is does each NSA put in its full connection map, then let the child NSA do the same thing which will result in duplicate information? For example: Parent populates: {ConnectionId=A1, Provisioned {connectionId=B1, Provisioned}, {connectionId=C1, Provisioned }} Then the children populate: {ConnectionId=B1, Provisioned {connectionId=B2, Provisioned}, {connectionId=B3, Provisioned }} {ConnectionId=C1, Provisioned {connectionId=C2, Provisioned}, {connectionId=C3, Provisioned }}
I (OpenNSA) doesn't keep track of the state for sub connections. This may sound counter-intuitive, but trying to keep track of that is actually a bloody mess (I did that initially).
One only needs to track the reply from the last request and then update the connection state accordingly. If you have seperate state machines (aggregator and ultmate provider) the concept of keeping track of subconnection states falls to the ground immediately.
I _really_ don't think we should have the state of sub connections. In fact, I cannot see how our protocol can support this.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Fri, 18 May 2012, John MacAuley wrote:
I do track the states against each since they indicate the messages outstanding and what has been received.
I think that is a valid implementation approach. But it is not the only one. A state for a sub-connection can only be "what the NSA think it is", and differencing between states reserved and scheduled is not possible without assuming relatively synchronized clocks (which the protocol of course does, so it isn't that bad - afterall it is required for a sane reservation concept). Furthermore, as we currently have different statemachines for aggregator and ultimate provider this requires knowledge about what type the sub-connection is, which is not needed without.
For example, the reserving state indicates I have sent a message to the child NSA and am waiting for the reserveConfirmed message. Effectively, you are doing the same thing by waiting for a specific message. Once all children are in the reserved stateI can send back a reserveConfirmed to my parent.
As it should. But notice that the state is not actually observable by here. You just emit the reserveConfirmed. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (4)
-
Henrik Thostrup Jensen -
Jerry Sobieski -
John MacAuley -
MacAuley, John (John)