Jebus Jerry, that is a long email. On Fri, 7 Dec 2012, Jerry Sobieski wrote:
We merge the connectionId and globalReservationId (not sure on the name) - It is generated by the client and must be generated in a way where clashes should not occur (UUIDs are obvious, but I'd prefer not to force specific technology needlessly).
Respectfully, I disagree. You need to keep the local segment identifier (ConnectionID) separate from a Global identifier.
Aye, we need something to that, that is why I introduced the linkId. There are different semantics though.
Else you run into problems with loops where two segments crossing the same domain from the same connection end up with the same identifier within a single domain.
Yay, built-in loop detection/prevention. (are there any good real-life use cases for supporting loops?)
You can't distinguish them if their only identifier is a global end-to-end identifier. So you need each segment to have a unique identifier - a ConnectionID.
See linkId.
The key here is that each NSA can create a local ConnectionId that is meaningful to that NSA. And that locally issued Connection ID is only useful when used in the context of the issuing NSA. So you have another two-tuple: [global] NSAid + [local] ConnectionID = global localization.
This makes it impossible for the provider to choose a unique or meaningful identifier. This forces the provider NSA to scope the identifier within the requester identity, meaning that a requester cannot relay the identifier to a third party as the provider will scope the identifier within the identity of the third party. This is one of the issues I am trying to overcome here. Arguably there are problems with it :-).
Thus, whenever you want a third party agent to query a connection, you tell them which provider NSA built the Connection, and the Connection ID that the provider assigned. Simple.
Except that the NSI protocol does not support that right now. This can only be achieve by faking the requester identity, which has obvious security problems. It also not simple to explain to users. They create an identifier, but cannot hand it another user/program.
Additionally, each NSA must assign an identifier to a connection if (and only if) a local link is created. We can call this linkId.
Not sure what you mean... Each NSA - even if they do not have a local segment - can nevertheless segment the request into many children in other domains. Why should these have or need a different type of identifier than a local segment ConnectionID?
The idea here is that the connectionid is global. This also makes sense as a connection is typically composed of several local connections (which I call links, this may be wrong, but we have no good terminlogy here). I see your point about needing an identifier for aggregators without local links, so that should probably be relaxed.
We have one - and only - identifier to refer to the whole connection. This is the primary way of referencing the connection, and will in most cases be the only thing a user / third party will need.
Again, I don't think it will work as you envision. Do you mean a single tag that says "all segments with this tag belong to the same circuit" ? And this tag *is* or *is not* the same as the ConnectionID that identifies a specific segment within a single domain?
I assume you are proposing two separate objects: a segment unique ConnectionID, and a end-to-end connection grouping identifier (an endtoend tag) ?? How do you expect the endtoend tag to be used - speciifcally? In a provision request? query? modify? Is this just re-inventing the current globalid field?
I am starting to think that the idea of a global identifier for a connection is competely and utterly bunk.
We have an identifier for each link in the connection. Besides the obvious use of identifying connection segments individually, this can be used for contacting the NOC or similar. By allowing the NSA to assign this it becomes possible to integrate into local systems, and re-use identifiers from a local system (I have this requirement, though it is not set in stone).
Agreed. You are saying this is what we have now..right?
Not exactly. The linkId is choosen by the provider, not the requester. This makes it possible for the provider to assign a meaningful id to the link. Anyway, I was trying to solve one of three problems, which I think the NSI protocol will run into head first when seeing wider usage: 1. Not being firewall/NAT friendly. At all. 2. No easy way of handing a connection identifier from one party to another. 3. No easy way for third parties to subscribe to state changes. (this one can be solved by querying so it less serious). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet