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

[Jerry Sobieski]

The GlobalID was created at the request of the perfSONAR developers to 
enable monitoring - how could you determine which segments belonged to a 
end-to-end connection without each segment being tagged with a Globally 
unique identifier?    (IMO this was a situation where old ideas and 
processes die slowly.)

The proper way to do this is to just use the ConnectionID and walk the 
tree - a detailed Query().   The detailed Query() exposes the actual 
domains along the path that are actually responsible for processing the 
service request - rather than trying to find just the domains that are 
carrying the bits (think about virtualized transit domains).   The 
Query() process provides _/authorized access/_ to this information 
throughout the service tree, and it provides genuine and reliable 
associations between the ConnectionIDs assigned at each NSA for its 
children.   Using GLobalID - without descending the tree - is a 
scattershot and unreliable means of discovering which segments comprise 
a reservation, and it bypasses all security policy asserted above.  Bad 
bad bad.  The Query() command is fully authorized and so completing a 
detailed query provides all the information about the connection 
segments belonging to a reservation and does so according to 
authorization policy along the tree and according to the requesters that 
actually built (and are paying for and/or are responsible for) the 
reservation.

The only other application of GlobalID that I recall was a batch query 
possibility (not currently implemented) - the ability to obtain 
information on a whole batch of unrelated connection segments.  I.e. if 
my agent wanted to know about all the connections your NSA was servicing 
then a global ID might provide some correlation with upstream/downstream 
segments obtained similarly. Either way, this poses too many security or 
privacy issues to count...

So our compromise was to allow a tag assigned by a RA to be carried 
along the segmentation tree so that Connections that wanted to be 
monitored by perfSONAR could be - but it was optional.    For perfSONAR 
monitoring purposes - this tag needed to be globally unique - thus its 
moniker.

As Vagellis observes - if each NSA in the tree wishes to assert their 
own GlobalID downward, then the GlobalID from above gets overwritten, or 
ignored altogether.  (I don't recall - it may be the case that if the 
GID is present, it was supposed to be replicated down - but this then 
prevents intermediate aggregator RAs from asserting a GlobalID 
themselves. )   If we want all GLobalIDs to be carried downward, the 
field must be able to carry multiple GlobalIDs, possibly from each 
network along a path (think hop-by-hop "chain" provisioning).  And if 
the field can carry multiple GLobalIDs, why limit each NSA to only 
inserting a single globalID? Why not let each NSA insert multiple 
tags?   Indeed, is there really any requirement for the tag to be 
globally unique in some way? It was only perfSONAR that required a 
globally unique identifier.

Now two years later, I don't know that there has been any perfSONAR 
tools modified to actually monitor NSI connections, much less to utilize 
the GlobalID field to do so.    Does any one know?    Are there any 
other tools that expect/require the GID to be present? or to be globally 
unique?  (and how easy will it be to break those tools? :-)

Given that NSI has the detailed Query() function that reliably and 
_/securely/_ exposes the end-to-end segmentation, I do not think the 
GlobalID field is required any more.  Does anyone have 
continuing/additional reasons for having it?

Unless there is a specific and compelling reason to retain the field as 
a general purpose communications field preserved in the Reservation 
record, I propose we should deprecate it and simplify the protocol.   As 
a general practice for standards, we should *NOT* retain it simply "just 
in case"...to retain it we need a specific and compelling reason to 
include it that makes it worthwhile for every implementation to support 
it.  "optional requirements" is a oxymoron.  Eitehr we need it, or we do 
not.    If we retain the field, then we need to redefine it so that it 
can carry multiple tags and so those tags can be recognized/parsed by 
generalized other agents, and the field should be constrained in size 
(don't want MPG4 movies being carried in the signaling messages.)

One last indirectly related note:  The ability of Query() to serve 
generalized agents -besides the uRA- will rely upon these agents issuing 
a detailed Query() to an NSA that is NOT the first hop PA at the root of 
the service tree.  For instance, a NORDUnet perfSONAR agent will see a 
local Connection ID it needs to monitor - how does it discover which NSA 
is the first hop?  And should it need to? Why can't the local agent 
issue a detailed Query() directly to the local NSA PA - and let the 
local NSA PA walk it *UP and OVER* in the service tree as well as down 
the service tree?   This is a "flooding" detailed Query().   The Query() 
functions the same way as it does now, only that the Query() is passed 
up to the parent RA as well, and the parent/child link from which the 
Query() came (if it came from a parent/child NSA in this connection's 
service tree) is pruned from the recursive flooding - it just gets the 
result.

By tweeking the Query() in this fashion, we enable a much more powerfull 
ability to manage the reservation.  This will also be an important 
capability for Notify() functions - an error condition could be flooded 
to all NSAs in the service tree using a similar flooding model thus 
being able to notify all NSAs upstream and downstream in the data plane 
of local interuptions.    Of course, we won't be able to use the current 
funky WS respondTo process for these upward bound messaging...we'll need 
a real symmetric session MTL model to do this.   But we already know this.

Jerry


On 12/6/12 5:06 AM, Jeroen van der Ham wrote:
> Hi,
>
> On 5 Dec 2012, at 18:24, Vangelis Chaniotakis <haniotak at es.net> wrote:
>
>> Oh, speaking of globalreservationid!
>>
>> we're only passing it around and persisting it not doing anything with it AFAICT.
>>
>>
>> - it's supposed to be a way to tie this connection with external services, right?
>> - if so, the name is not quite descriptive of its function
>> - it's also optional, while the name sounds terribly important
>> - why a URI instead of a string? or key-value pair
>> - there's only one of them, why not allow for a set?
> It is supposed to be the ID for the global reservation. The aggregator NSA receives a request, generates an ID and uses this global ID to make connection requests to each of the participating NSAs. They generate a connection ID for their segment, but must be able to relate that to the global reservation ID.
>
> So yes, it does perform a very important global function :)
>
> It is indeed also meant for tieing in to other services. The URN is used to make it very clear that this is a network global reservation ID.
>
> Jeroen.
>
> _______________________________________________
> 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/20121206/db1425ba/attachment-0001.html>