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

[Jerry Sobieski]

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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20121207/39ab2823/attachment.html>