[Nsi-wg] Some questions/remarks on the v2 connection wsdl GlobalID

[Henrik Thostrup Jensen]

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