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

[Inder Monga]

Hi All,

It seems this group likes to rehash discussions every two years, so it is
not a surprise we are having this debate yet again, from Munich, Salt Lake
City OGF and now. Part of the reason  for the confusion is that the
recollection of the discussion is biased, and the arguments of the other
side are forgotten or ignored. As co-chair I will try to represent both
sides of the story. I would encourage all to start contributing detailed
descriptions to Guy so that place where answers are found are the NSI
protocol standards specification. I am sure all agree with my frustration
here in getting the specification written.

Let me point to Fedex or UPS as an example, a scalable system of packet
delivery end-to-end.

a) Scenario with per-hop connection ID as the only way being suggested:
If the sending customer, say John, sends a package, he will get a tracking
ID. Every time a logical point to point delivery happens, a new ID is
generated. so when the Fedex store sends the package to the local
warehouse, the local warehouse generates a new ID, and then the plane flies
to another town and package enters an intermediate warehouse, a new ID is
generated. Lets assume to make this case consistent with NSI, that there is
not one company, and each leg is managed by a different administrative
entity.

For the customer to track, he has to
    1) Get the topology of the entire packet delivery, assuming he has
authorization. That is a chicken and egg problem because he does not know
which domains or service providers his packet is going to go through as
Fedex may have many sub-service providers. He can spend months trying to
figure that out, but maybe his local store can query and try to figure it
out for him
    2) Then he has to send a query to try to get the tracking ID from each
of those service providers.
    3) and then he sends a query to each service provider to find out if it
left origin point of that service provider to the end point of that service
provider.
    4) and then maybe he finds out where the delivery is at, if it did get
delivered and where the problem could have been if it didnt.

I simplified the above since I did not want to type all the possibilities
where things would fall apart, but I am sure you can insert that.

b) Scenario with a Global Connection ID , the way tracking really happens

The sending customer delivers his package to a store and gets a global
connection ID. He comes home and can query against that. He can share the
global connection ID to whomever he authorizes and they can get status on
the package, third party services like Jeroens don't need special
authorization for every package sent and from every customer (it works now
in AutoGOLE because there is no security). It is his package. but in order
to cancel it he has to provide authorization that only he can (a secure
token or cert based authentication)

Every step of the way, the global connection ID is scanned and recorded.
Regardless of the administrative provider, there is one consistent ID that
can track the package and it is easy for him to know where it is.
Isn't that a much better service interface?


The reason for the confusion around GlobalConnectionID (and the name can be
improved - please suggest and let the group decide), is because it is not
mandatory. Because of that the "prototype" NSAs don't fill it out.

My $0.02 representing the other side,

Inder





On Thu, Dec 6, 2012 at 4:19 AM, Jerry Sobieski <jerry at nordu.net> wrote:

>  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> <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 listnsi-wg at ogf.orghttps://www.ogf.org/mailman/listinfo/nsi-wg
>
>
>
> _______________________________________________
> 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/41c915d4/attachment.html>