Hej Henrik... see comments in line.

On 12/7/12 5:35 AM, Henrik Thostrup Jensen wrote:

Hi

On Thu, 6 Dec 2012, Vangelis Chaniotakis wrote:

I hope these are productive suggestions:
- let's name it something akin to "GlobalConnectionId"
- let's make it mandatory,
- let's specify the desired immutable behavior

( Ideally I'd also really like to take another page from the commercial world and have something like those 6-character strings used for airline reservations assigned to the end-to-end connection.. but that's not necessarily an NSI feature I suppose - can be part of a meta-service)

How about this:

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.   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.   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.

If someone wants to us UUIDs as their local CID, fine, as long as they are locally unique for each segment. If someone else wants to use other key information n their CIDs - let them do that.   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.

Every NSA does this.   And every NSA keeps track of the mapping of their Connection ID with that assigned by the parent/child of the Reservation request. These are exchanged in the ReserveReq()/ReserveConfirm() initial msg exhange.

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.

In a detailed Query() (albeit one that meets all authorization down the tree), the response will expose the NSAs and CIDs of each node in the Service tree.   The leaf nodes provide the data plane path.

- This creates a single identifier for the whole connection for both
users and any other third part that must use the connection.

I don't think so. We can carry a tag along with the Reservation. And keep that tag and query against it. But it can't be used to identify a specific segment. If can only be used to identify segements ...that have that tag. What if someone else issued a request with the same tag? If the tag is intended to be unique - globally unique - how do you validate that? It is not enough to mandate it, if you cannot check it then it is subject to hack. If you cannot validate it, then you cannot trust it. Even a UUID can be fraudulent - it must be validated to be reliable and in the standard. If the standard cannot validate its global uniqueness, and does not require that it be validated, then it is simply optional and a best practice... and subject to a million hackers who would love to mess with you.

- If an NSA receives a request with a (global) connection id the request
is rejected, as the client should feel bad.

Hehe.

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?

This means:

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?

You need a means of identifying uniquely each segment of a connection -differentiating it from other segments within a domain, from other segments in the same connection, and from segments in all other connections. An end-to-end tag is only cosmetic. Functionally, within the software, the globalid/endtoend tag requires a lot of care and feeding in order to insure that it is a valid tag (see above about validation.)

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?

Thanks!
Jerry

Thoughts?

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