Hi all-

Just a point of reference: Prior protocols addressed this by having each agent (the user and network) assign their own ID as part of the request signalling.   Thus you always had unique ids because they only needed to be unique for the agent creating them.   The other agent in the protocol would simply assign a mapping from their unique ID to the neighbor's unique ID.

Since an agent always new who it was speaking to, it would also know which id to use when speaking to that agent.   So essentially this amounts to a two level ID a globally uniq part (the NSA ID) and a localy unique part.   These can be munged together, or kept as two separate data elements in a compound object.

This sounds a bit convoluted, but it is really quite simple and solves the problems of maliciously chosen duplicate IDs, and allows third party agents to reference the ID without confusion.

To use this method, the RA assigns a locally (RA) unique ID and send the reservation request to the PA, who will assign a local (PA) unique ID to the connection and return that with the reservation response.    As long as the formal connection ID includes the NSA ID and the local part, you know deterministically that the CID is globally unique and that it won't conflict at any NSA.

Jerry

On 8/22/12 4:42 PM, Inder Monga wrote:

Global ID is currently optional, and is specified by the client, so it cannot be used for anything in this.

Why cannot Global ID be used? If people want monitoring, they can make it mandatory to populate that . In fact we wanted to make this non-optional and mandatory.

Inder
_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg