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