Some questions/remarks on the v2 connection wsdl
Hi Found a couple of things in the v2 CS WSDL. Mostly minor stuff. The types: GlobalReservationIdType ( restriction base: xsd:anyURI ) ConnectionIdType ( restriction base: xsd:string ) NetworkIdType ( restriction base: xsd:anyURI ) Seems to just be aliases. Are there any reason for having them? The file ogf_nsi_connection_types_v2_0.xsd import saml, but does not appear to use it. I'm guessing this is just a leftover from when the security attributes was in the file. Not sure of the implications of removing this, but would be nice if we could avoid breakage. OTOH we will probably have to live with these things for a while, and will probably not get another chance to fix it. Questions: Why do we need protocol version in Header? Isn't this already contained in SOAP action? Do we really need a file ( ogf_nsi_framework_headers_v2_0.xsd ) for one type? Not really important, just seemed like overkill. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
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? On Dec 5, 2012, at 6:46 AM, Henrik Thostrup Jensen wrote:
Hi
Found a couple of things in the v2 CS WSDL. Mostly minor stuff.
The types:
GlobalReservationIdType ( restriction base: xsd:anyURI ) ConnectionIdType ( restriction base: xsd:string ) NetworkIdType ( restriction base: xsd:anyURI )
Seems to just be aliases. Are there any reason for having them?
The file ogf_nsi_connection_types_v2_0.xsd import saml, but does not appear to use it. I'm guessing this is just a leftover from when the security attributes was in the file.
Not sure of the implications of removing this, but would be nice if we could avoid breakage. OTOH we will probably have to live with these things for a while, and will probably not get another chance to fix it.
Questions:
Why do we need protocol version in Header? Isn't this already contained in SOAP action?
Do we really need a file ( ogf_nsi_framework_headers_v2_0.xsd ) for one type? Not really important, just seemed like overkill.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Wed, 5 Dec 2012, Vangelis Chaniotakis wrote:
Oh, speaking of globalreservationid!
It was added before I started working in NSI, but I'll give it a go.
we're only passing it around and persisting it not doing anything with it AFAICT.
Sounds right.
- it's supposed to be a way to tie this connection with external services, right?
AFAIK, yes. Essentially a way to correlate links without using the NSI query function.
- if so, the name is not quite descriptive of its function
The name could indeed be better. The term globalId or globalConnectionId would be better IMHO.
- it's also optional, while the name sounds terribly important - why a URI instead of a string? or key-value pair
At some point it was supposed to be a UUID. Then it was probably relaxed. Now it is a URI. +1 for making it a string.
- there's only one of them, why not allow for a set?
I guess one should be enough, given it purpose. On the topic of identifiers. All services (this should included NSI connections) in NORDUnet are assigned a service identifier, which the NOC can use to find information in our internal system. Note that this is just per link, not global in any way. Currently this is is more or less impossible to assign in the NSI protocol (John, did we land on anything in the connectionId assignment discussion?). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 5 Dec 2012, at 18:24, Vangelis Chaniotakis <haniotak@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.
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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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@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@es.net> <haniotak@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@ogf.orghttps://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Dec 6, 2012, at 7:22 AM, Inder Monga wrote:
Hi All,
<snip>
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?
Absolutely. 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)
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). - This creates a single identifier for the whole connection for both users and any other third part that must use the connection. - If an NSA receives a request with a (global) connection id the request is rejected, as the client should feel bad. Additionally, each NSA must assign an identifier to a connection if (and only if) a local link is created. We can call this linkId. 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. 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). Thoughts? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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
Hi Inder - Some rebuttal to your GlobalID FEdEx analogy inline. I am firmly convinced that the current GID specifications are superfluous and should be removed or at a minimum converted to the "Options" field (see below). Now read on to see how brainwashed you have been by the corporate FedEx Borg... :-) Best regards Jerry On 12/6/12 10:22 AM, Inder Monga wrote: > > 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. If John gives his package to FedEX,...is John then responsible for going to the warehouse to get a status, and then to the airfreight depot to get a status? and then to DHL to see if FedEx used them for a portion of the trip? and then to UPS? and then to Redball Express, and then try to discover which carries in Europe or Asia those guys then handed it off to? No. Users would get pissed off if FedEx just handed the package to another carrier and washed their hands of it. But this is your example. Your example is an intra-domain example. FedEx uses a single number inside their domain only. Despite their marketing name for it as a "Global Tracking Number" they have a single administrative traking system and all their systems use it. And I bet they had to com eup with an NSI analog to track shipments acorss different carriers...and those otehr carriers do not use FedEx tracking numbers in their systems. For a user to discover how his package is being shipped - and which carriers were subcontracted to do it - the user *still* needs to go to FedEx to get the information - and FedEx walks the tree to discover who they allocated it to. And even for their subs - they only get the status their subs wish to release based upon the FedEx id they used. FedEx acts as the query point for status as well as the point of service - and indeed uses its own Tracking number to query independent subcontractors or its own internal status. This is exactly what NSI does in the Query() function. But those subcontractors do not use FedEx numbers for tracking their own internal operations. You look at a package and you will see multple tracking information. THis is largely simplified for FedEx and UPS because they are essnetially a centrally managed domain within themselves across the globe. They are a google for shipping. :-) But they are not universal and the FedEx "Global tracking number" is more a marketing name - its not a globally unique identifier - except for FedEx. > > 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 Exactly - so the user queries the service provider he gave the package to - FedEx, and FedEx walks the tree. Just like NSI. > 2) Then he has to send a query to try to get the tracking ID from > each of those service providers. No - Customer does not do this - Fedex does this. Just like NSI - you send a Query() to the head PA and that agent queries down the service tree recursively and rolls up the result. One stop shopping. > 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. Sigh. When is the last time you told FedEx which transport carriers to use to ship your package? You just tell them where you want it to go. _/They decide how to get it there./_ And they assume responsibility for getting it there. Which is why you can then go to *them* to get a valid status. If you do not ask them to go end to end, then they will not give you end to end status. If you ask FedEx to just deliver a package to an exporter in New York, and tell the exporter to deliver it to Copenhagen,, FedEx will have nothing to do with the status of NYC to CPH. Not their issue. Likewise with NSI. If you give the package to FedEX, you go back to FedEx to ask for the status - and FedEx goes out and finds the status from however they arranged for it and rolls it up and presents it to you - even if they delegated delivery to another carrier. If you got a subcontractor's tracking number and asked the sub for a status - they could tell you it came from FedEx, even give you a FedEx number, and they can probably even push the query up the stack and query FedEx to get the status of the fedEx segment and roll it all up and present it to you. And this is what the detailed Query() does. (Except the query up doesn't work in NSI because we have this crazy replyTo bogsity as our sole means to send messages up the service tree.) You could not use the FedEx tracking number on the UPS system, or DHL, or GOD, or any other. Nor could you use these other carriers tracking numbers with FedEx. This is exactly what we should do with NSI - Let each NSA PA assign their own ConnectionID/ReservationID, and let the NSA PA decide how to subcontract it. The RA and PA each assign and exchange their own ConnectionIDs as part of the Reserve/Confirm process. And then if the user wants a status - he takes the ConnectionID that he is given and the NSA that assigned it, and queries that NSA for the end to end path. No GlobalID required. You still need to discover the path it took. You need more than a globally unique ID to do this. You need to know which NSA(s) are on the path - the most obvious one is the one that the RA used to start the process. So now we need to encode NSA information in the GID so you know where to start. So even if the GID contains that first NSA in the GID, you *still* need to go query that NSA to get a status and the path. Does ESnet want to honor queries from NSAs that it would not otherwise have honored a Reservation Request? If you only honor requests from "trusted" NSAs, then remote unknonw NSAs have no choice but to walk the tree to let each NSA that successfully estabslihed the reservation ask for the query. There is no guaranty that the Global ID you have was actualy passed down to the NSA you are querying - even if you know for fact that connection transits that infrastructure. Virtualization can hide this information, or the GID was not replicated down - maybe because the PA used different credentials to progress the connection. Lots of legitimate reasons why the GID is not found. And lots of ways to screw with the system (for instance - what if I deliberately send several requests that use the same GID...it doesn't even have to be one from my own namespace as it could be one I am simply replicating from a parent RA... ) We have no way of validating or verifying the vercity of the global id, so we are just sending jibberish for all we know. The one identifier we know is valid is the one each NSA tells us is the segment ID for their portion. So we recurse down the service tree walking these ConnectionIDs and construct a valid picture of the path and state. > > 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. No. He gets a tracking ID issued by the particular Carrier that he gave the package to. The Tracking ID is only "global" in the sense that the particular carrier uses that tracking number to track a shipment *they* are delivering anywhere in the world. It is not used across *all* carrier's systems, nor is it "globally unique" across carriers. > He comes home and can query against that. He can only usefully query that tracking number against the carrier that took the package. No one else. > He can share the global connection ID to whomever he authorizes and > they can get status on the package, Third party requesters can still only query the specific Carrier you gave the package to if they wish to get a status. A tracking number by itself does not indicate the carrier. You give the tracking number to a different carrier - they won't know it from Peter. So anyone with a tracking number /and the carrier that issued it/ can indeed get a status - from that carrier. This is not a function of a globally unique identifier - this is an authorization policy of that carrier. A different carrier may require you to login to the account that shipped the package. And if you gave that number to a friend without telling them which carrier it belongs to, your friend is going to go off on a random exhaustive search poking that number at every carrier he knows about to see if it happens to return a result...and hopefully it is not duplicated in another carrier's system and gives him bogus results. Now think if you had a rogue automated agent that was just probing for ESnet circuits in order to tee up a cyber attack...like the US did to Iran... On the other hand, if an arbitrary agent knows a Connection ID (not a GID) and the NSA that issued that Conenction ID, and wishes to discover where that connection originates, what rights should that agent have to go and stalk that connection, or the user who owns it? Should any agent be able to see how much traffic that connection is carrying? Should any agent be able to freely find out if it was explicitly asked to transit ESnet - and allowed to do so? and what path it tok thru ESnet? Or if it explicitly avoided CERnet or some other network? My contention is that these are *local policy decisions* and should not be backdoored simply because we have legacy software that breaks if we don't grandfather in a weak mechanism that was used in the past. If ESnet wants to let people see their circiuts, then lower the security profiles you apply. i.e. unlock the door and prop it open, don't make a big hole in the wall next to it. > 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) Sure - we can have different authorization rules for reading vs writing/modifying status.. we just define different policy rules. Some can be very lax while others very tight. But we still need to have authorization decision points that enforce policy. But what do you mean "special" authorization. If he requested a service instance, he should be able to query its status with his credentials. If the carrier decides to use internal private policy to make path decisions and potentially uses different credentials to make it happen, does Jeroen still have rights to know those decisions? I would contend he does not. Authorizing a user's request to transport data at a certain rate, does not implicitly mean that the user is entitled to know other aspects about that service that were not explicitly part of the request. At least not by default. Such access needs to be authorized by a policy - even if that policy says anyone can do this. The service was a data transport request - as long as the service is meeting that request, why should access to the engineering details be likewise available? If someone else wants to query the status of his service instance, the credentials they present should be used to allow or disallow it. Likewise for canceling the service. It has nothing to do with who's package it is - it is a function of makng sure the actions performed are authorized - always - by asserting the actor's credentials and the action they wish to perform against a policy rule. If you lower the authorization level to ...nothing... Then you are simply saying that you implement a policy where anyone's credentials can perform a any function - you don't bypass the authorization decision point. And more importantly - the level of authorization required to perform some function is a policy imposed by the administrative body responsible for those resources or services. Just because *you* in ESnet think that this information should be easily visible does not mean that NORDUnet feels the same way. And NORDUnet may give you excellent connection service performance and reliability... And just because NORDUnet might allow any academic user a great deal of latitude in provisioning services across NORDUnet does not mean ESnet will honor a similar policy. We can all mutually agree to institute very lax policy, but we should not bypass the policy decision points or the policy enforcement points. > 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? Nope. FedEx simply calls _/their /_tracking a number a "global tracking number". If I call the NORDUnet Connection ID the "NORDUnet Global Tracking ID" ...would you expect it to work in ESnet? FedEx can impose their global tracking number on themselves - across all of their international divisions. But they can't impose it on the subcontractors. Even the little guys use their own tracking number for actual operations, and simply correlate the FedEx number with their own. And they only look for the FedEx "GlobalID" when FedEx comes asking.... If those little guys also also serve UPS, they map the UPS tracking number to their internal system for UPS packages... and track UPS numbers when UPS asks. And when they are simply tracking their own operations - should they use FedEX Global ID or the UPS Internaional ID? Or could they use their own number..? > > > 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. > We need to approach the standard not as a mechanism we want to be able to work properly across /and beyond/ the academic networks. ESnet tends to be focused on the US DoE lab requirements - a relatively limited horizon. But NSI is intended to work across a wide array of network - R&E networks *AND* commercial networks. We need to keep this in mind - NSI needs to function in other network contexts - often much MUCH larger and untrustworthy. And R&E networks should not be less able to secure themselves than commercial networks. So if we elect to implement a loose authorization policy profile - this is fine. And I agree can be useful in these development activities. But we should not define a field to be something we cannot verify. E.g. if an ID appears in the GID field - what happens if it is *NOT* globally unique? Perhaps what we need is an "options" field in every message. This is akin I guess to what Chin asked about in Oxford but I think that was for just reservation request... So this field would contain arbitrary type-value pairs (or maybe TLVs.) The Options field would be mandatory, but could be empty. The contents are intended to be parameters for non-standard (i.e. implementation specific) functionality. Since these are _/optional and non-standard/_ data, the NSI standard should make no rules about how the data elements are defined or how they are handled. NSI should simply state how they are formatted within a message. And I mean *NO* rules about their usage - they are non-stanard i.e. "NOT of the standard." (!) so should not be required or referenced by any feature in the standard. The only thing that should be placed in the standard is that there is a message field that carries 0 or more non-standard parameters. Since the parameters are non-standard, we can not even stipulate when they ought to be replicated by aggregators. It is left to each particualr NSA implementations to interpret them or to ignore them altogether. Thoughts? Jerry > My $0.02 representing the other side, > > Inder > > > > > > On Thu, Dec 6, 2012 at 4:19 AM, Jerry Sobieski <jerry@nordu.net > <mailto:jerry@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@es.net> <mailto:haniotak@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@ogf.org <mailto:nsi-wg@ogf.org> >> https://www.ogf.org/mailman/listinfo/nsi-wg > > > _______________________________________________ > nsi-wg mailing list > nsi-wg@ogf.org <mailto:nsi-wg@ogf.org> > https://www.ogf.org/mailman/listinfo/nsi-wg > >
Hi Jerry, Well the length of your email was lot bigger even than the NSI WS messages so it takes time to process and respond ;) The problem with analogies is that it is an analogy and imperfect by its nature, but just attacking the analogy rather than focusing on the core principles does not help resolve the discussion. The point is the same - it is not about the an RA having one ID for the connection, but the connection having one ID. So when you talk about the user having one ID, and the downstream PA having to walk the tree to aggregate all the connection IDs to figure out all the IDs for an end-to-end connection, I don't understand how that interferes or somehow disproves the need for the global ID. You can walk the tree or use the global-id, mapping of which every domain in the path maintains, and can share with other repositories if needed. The scenarios you describe below of walking the tree successfully represents the best case - when everything works, but start putting in reality into the equation and errors into the situation and you can see how useful the single ID is. In the end, it is not an extra burden on any one NSA since connection specific IDs exist and are needed, nobody is getting rid of them. Using your analogy, each sub-tree provider will map its own connection iD to the Global ID and maintain that mapping in their domain. A global ID does not force every domain to use it, or rewrite things that hs been mentioned, just asks them to maintain that mapping so the end-to-end service has a single determinate identifier. Why you may ask? You mention about perfSONAR - that's a good reason, for most multi-domain stats collection for circuits, debugging, accounting, tracking purposes this serves a very useful purpose.Its an optional parameter. As soon as NSI goes into production, it will prove useful. AutoGOLE being a demonstration platform does not have the operational requirements or multi-domain debugging that will be required for a NSI-CS production service. Thoughts? Inder p.s. Henrik - I haven't ready your follow-on messages, trying to answer in order.
On 12/6/12 10:22 AM, Inder Monga wrote:
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.
If John gives his package to FedEX,...is John then responsible for going to the warehouse to get a status, and then to the airfreight depot to get a status? and then to DHL to see if FedEx used them for a portion of the trip? and then to UPS? and then to Redball Express, and then try to discover which carries in Europe or Asia those guys then handed it off to? No. Users would get pissed off if FedEx just handed the package to another carrier and washed their hands of it. But this is your example. Your example is an intra-domain example. FedEx uses a single number inside their domain only. Despite their marketing name for it as a "Global Tracking Number" they have a single administrative traking system and all their systems use it. And I bet they had to com eup with an NSI analog to track shipments acorss different carriers...and those otehr carriers do not use FedEx tracking numbers in their systems.
OK think about the US post office Global Express Mail - that is not Fedex and it uses many countries mail service. Don't attack the analogy - please look at the concept behind it. Yes, John gives the package to an entity for delivery, and wants to use the single tracking number from that entity. Not only that, if John shares that tracking number with the person receiving the package, his secretary or a colleague, they can all track the package based on that one ID.
For a user to discover how his package is being shipped - and which carriers were subcontracted to do it - the user *still* needs to go to FedEx to get the information - and FedEx walks the tree to discover who they allocated it to. And even for their subs - they only get the status their subs wish to release based upon the FedEx id they used.
You are talking about the Path computation and the path. I am talking about monitoring and status. Fedex may use their own algorithms to optimize the subcontract carriers they choose, their subcontract carriers may use their own tracking numbers, but for the user, only the Fedex tracking number matters. For the other subcontractors, if given the Fedex ID, they can figure out the status of that package. They maintain their own mapping of the global Fedex ID to their own tracking ID. So the user only deals with one ID. The entities providing service manage the mapping of their own service IDs to the global ID - it does not need to be shared with the user.
FedEx acts as the query point for status as well as the point of service - and indeed uses its own Tracking number to query independent subcontractors or its own internal status. This is exactly what NSI does in the Query() function. But those subcontractors do not use FedEx numbers for tracking their own internal operations. You look at a package and you will see multple tracking information. THis is largely simplified for FedEx and UPS because they are essnetially a centrally managed domain within themselves across the globe. They are a google for shipping. :-) But they are not universal and the FedEx "Global tracking number" is more a marketing name - its not a globally unique identifier - except for FedEx.
You are just proving my above point. The subcontractors may use their own tracking numbers but map it to the global fedex number. They maintain the mapping and do the translation, not the user. The user only deals with one ID.
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
Exactly - so the user queries the service provider he gave the package to - FedEx, and FedEx walks the tree. Just like NSI.
Not really - you mentioned that the user needs to be authorized at each leaf of the tree to get the status. Not just like NSI. Also, Fedex can use that global ID and query their subcontractors...the subcontractors use that one global ID to get status (and may map to their own ID), but the beauty is not only Fedex but other services or folks can use that ID with the subcontractor to query sstatus as well.
2) Then he has to send a query to try to get the tracking ID from each of those service providers.
No - Customer does not do this - Fedex does this. Just like NSI - you send a Query() to the head PA and that agent queries down the service tree recursively and rolls up the result. One stop shopping.
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.
Sigh.
When is the last time you told FedEx which transport carriers to use to ship your package? You just tell them where you want it to go. *They decide how to get it there.* And they assume responsibility for getting it there. Which is why you can then go to *them* to get a valid status. If you do not ask them to go end to end, then they will not give you end to end status. If you ask FedEx to just deliver a package to an exporter in New York, and tell the exporter to deliver it to Copenhagen,, FedEx will have nothing to do with the status of NYC to CPH. Not their issue. Likewise with NSI. If you give the package to FedEX, you go back to FedEx to ask for the status - and FedEx goes out and finds the status from however they arranged for it and rolls it up and presents it to you - even if they delegated delivery to another carrier.
If you got a subcontractor's tracking number and asked the sub for a status - they could tell you it came from FedEx, even give you a FedEx number, and they can probably even push the query up the stack and query FedEx to get the status of the fedEx segment and roll it all up and present it to you. And this is what the detailed Query() does. (Except the query up doesn't work in NSI because we have this crazy replyTo bogsity as our sole means to send messages up the service tree.)
You could not use the FedEx tracking number on the UPS system, or DHL, or GOD, or any other. Nor could you use these other carriers tracking numbers with FedEx.
This is exactly what we should do with NSI - Let each NSA PA assign their own ConnectionID/ReservationID, and let the NSA PA decide how to subcontract it. The RA and PA each assign and exchange their own ConnectionIDs as part of the Reserve/Confirm process. And then if the user wants a status - he takes the ConnectionID that he is given and the NSA that assigned it, and queries that NSA for the end to end path. No GlobalID required.
You still need to discover the path it took. You need more than a globally unique ID to do this. You need to know which NSA(s) are on the path - the most obvious one is the one that the RA used to start the process. So now we need to encode NSA information in the GID so you know where to start. So even if the GID contains that first NSA in the GID, you *still* need to go query that NSA to get a status and the path. Does ESnet want to honor queries from NSAs that it would not otherwise have honored a Reservation Request? If you only honor requests from "trusted" NSAs, then remote unknonw NSAs have no choice but to walk the tree to let each NSA that successfully estabslihed the reservation ask for the query.
There is no guaranty that the Global ID you have was actualy passed down to the NSA you are querying - even if you know for fact that connection transits that infrastructure. Virtualization can hide this information, or the GID was not replicated down - maybe because the PA used different credentials to progress the connection. Lots of legitimate reasons why the GID is not found. And lots of ways to screw with the system (for instance - what if I deliberately send several requests that use the same GID...it doesn't even have to be one from my own namespace as it could be one I am simply replicating from a parent RA... ) We have no way of validating or verifying the vercity of the global id, so we are just sending jibberish for all we know. The one identifier we know is valid is the one each NSA tells us is the segment ID for their portion. So we recurse down the service tree walking these ConnectionIDs and construct a valid picture of the path and state.
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.
No. He gets a tracking ID issued by the particular Carrier that he gave the package to. The Tracking ID is only "global" in the sense that the particular carrier uses that tracking number to track a shipment *they* are delivering anywhere in the world. It is not used across *all* carrier's systems, nor is it "globally unique" across carriers.
He comes home and can query against that.
He can only usefully query that tracking number against the carrier that took the package. No one else.
He can share the global connection ID to whomever he authorizes and they can get status on the package,
Third party requesters can still only query the specific Carrier you gave the package to if they wish to get a status. A tracking number by itself does not indicate the carrier. You give the tracking number to a different carrier - they won't know it from Peter. So anyone with a tracking number *and the carrier that issued it* can indeed get a status - from that carrier. This is not a function of a globally unique identifier - this is an authorization policy of that carrier. A different carrier may require you to login to the account that shipped the package. And if you gave that number to a friend without telling them which carrier it belongs to, your friend is going to go off on a random exhaustive search poking that number at every carrier he knows about to see if it happens to return a result...and hopefully it is not duplicated in another carrier's system and gives him bogus results. Now think if you had a rogue automated agent that was just probing for ESnet circuits in order to tee up a cyber attack...like the US did to Iran...
On the other hand, if an arbitrary agent knows a Connection ID (not a GID) and the NSA that issued that Conenction ID, and wishes to discover where that connection originates, what rights should that agent have to go and stalk that connection, or the user who owns it? Should any agent be able to see how much traffic that connection is carrying? Should any agent be able to freely find out if it was explicitly asked to transit ESnet - and allowed to do so? and what path it tok thru ESnet? Or if it explicitly avoided CERnet or some other network? My contention is that these are *local policy decisions* and should not be backdoored simply because we have legacy software that breaks if we don't grandfather in a weak mechanism that was used in the past. If ESnet wants to let people see their circiuts, then lower the security profiles you apply. i.e. unlock the door and prop it open, don't make a big hole in the wall next to it.
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)
Sure - we can have different authorization rules for reading vs writing/modifying status.. we just define different policy rules. Some can be very lax while others very tight. But we still need to have authorization decision points that enforce policy.
But what do you mean "special" authorization. If he requested a service instance, he should be able to query its status with his credentials. If the carrier decides to use internal private policy to make path decisions and potentially uses different credentials to make it happen, does Jeroen still have rights to know those decisions? I would contend he does not. Authorizing a user's request to transport data at a certain rate, does not implicitly mean that the user is entitled to know other aspects about that service that were not explicitly part of the request. At least not by default. Such access needs to be authorized by a policy - even if that policy says anyone can do this. The service was a data transport request - as long as the service is meeting that request, why should access to the engineering details be likewise available? If someone else wants to query the status of his service instance, the credentials they present should be used to allow or disallow it. Likewise for canceling the service. It has nothing to do with who's package it is - it is a function of makng sure the actions performed are authorized - always - by asserting the actor's credentials and the action they wish to perform against a policy rule. If you lower the authorization level to ...nothing... Then you are simply saying that you implement a policy where anyone's credentials can perform a any function - you don't bypass the authorization decision point.
And more importantly - the level of authorization required to perform some function is a policy imposed by the administrative body responsible for those resources or services. Just because *you* in ESnet think that this information should be easily visible does not mean that NORDUnet feels the same way. And NORDUnet may give you excellent connection service performance and reliability... And just because NORDUnet might allow any academic user a great deal of latitude in provisioning services across NORDUnet does not mean ESnet will honor a similar policy.
We can all mutually agree to institute very lax policy, but we should not bypass the policy decision points or the policy enforcement points.
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?
Nope. FedEx simply calls *their *tracking a number a "global tracking number". If I call the NORDUnet Connection ID the "NORDUnet Global Tracking ID" ...would you expect it to work in ESnet? FedEx can impose their global tracking number on themselves - across all of their international divisions. But they can't impose it on the subcontractors. Even the little guys use their own tracking number for actual operations, and simply correlate the FedEx number with their own. And they only look for the FedEx "GlobalID" when FedEx comes asking.... If those little guys also also serve UPS, they map the UPS tracking number to their internal system for UPS packages... and track UPS numbers when UPS asks. And when they are simply tracking their own operations - should they use FedEX Global ID or the UPS Internaional ID? Or could they use their own number..?
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.
We need to approach the standard not as a mechanism we want to be able to work properly across *and beyond* the academic networks. ESnet tends to be focused on the US DoE lab requirements - a relatively limited horizon. But NSI is intended to work across a wide array of network - R&E networks *AND* commercial networks. We need to keep this in mind - NSI needs to function in other network contexts - often much MUCH larger and untrustworthy. And R&E networks should not be less able to secure themselves than commercial networks. So if we elect to implement a loose authorization policy profile - this is fine. And I agree can be useful in these development activities. But we should not define a field to be something we cannot verify. E.g. if an ID appears in the GID field - what happens if it is *NOT* globally unique?
Perhaps what we need is an "options" field in every message. This is akin I guess to what Chin asked about in Oxford but I think that was for just reservation request... So this field would contain arbitrary type-value pairs (or maybe TLVs.) The Options field would be mandatory, but could be empty. The contents are intended to be parameters for non-standard (i.e. implementation specific) functionality. Since these are *optional and non-standard* data, the NSI standard should make no rules about how the data elements are defined or how they are handled. NSI should simply state how they are formatted within a message. And I mean *NO* rules about their usage - they are non-stanard i.e. "NOT of the standard." (!) so should not be required or referenced by any feature in the standard. The only thing that should be placed in the standard is that there is a message field that carries 0 or more non-standard parameters. Since the parameters are non-standard, we can not even stipulate when they ought to be replicated by aggregators. It is left to each particualr NSA implementations to interpret them or to ignore them altogether.
Thoughts? Jerry
My $0.02 representing the other side,
Inder
On Thu, Dec 6, 2012 at 4:19 AM, Jerry Sobieski <jerry@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@es.net> <haniotak@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@ogf.orghttps://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On 2012-12-05, at 9:46 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
The types:
GlobalReservationIdType ( restriction base: xsd:anyURI ) ConnectionIdType ( restriction base: xsd:string ) NetworkIdType ( restriction base: xsd:anyURI )
Seems to just be aliases. Are there any reason for having them?
I changed the occurrences to a specific type so i had a single location to change them. In the previous NSI version these were included in individual messages and I was getting sick of changing them in multiple places every time we changed our mind. Now when we change their type I only have to do it in one spot.
On Wed, 12 Dec 2012, John MacAuley wrote:
On 2012-12-05, at 9:46 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
The types:
GlobalReservationIdType ( restriction base: xsd:anyURI ) ConnectionIdType ( restriction base: xsd:string ) NetworkIdType ( restriction base: xsd:anyURI )
Seems to just be aliases. Are there any reason for having them?
I changed the occurrences to a specific type so i had a single location to change them. In the previous NSI version these were included in individual messages and I was getting sick of changing them in multiple places every time we changed our mind. Now when we change their type I only have to do it in one spot.
Right, that makes sense. The NetworkIdType is only used once AFAICT. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On 2012-12-05, at 9:46 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
The file ogf_nsi_connection_types_v2_0.xsd import saml, but does not appear to use it. I'm guessing this is just a leftover from when the security attributes was in the file.
Yes, this was a holdover to when we were including the SAML attributes in the core schema. Their use has been moved to the header. I will remove the reference from the types file. John.
On 2012-12-05, at 9:46 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Questions:
Why do we need protocol version in Header? Isn't this already contained in SOAP action?
Do we really need a file ( ogf_nsi_framework_headers_v2_0.xsd ) for one type? Not really important, just seemed like overkill.
1) SOAP Action I had an internal discussion here in Ottawa with my dogs on this exact topic a few months ago when I defined the header. We argued for both including and excluding the version field within the header. What swayed me to include it was the concept that if we removed SOAP from the equation, and wanted to continue using the XML schema, then a header with version number let the protocol contents exist independent of the SOAP action. Additionally, the HTTP SOAP action field if 100% optional and I only provided it in the SOAP binding to make it easier for .NET clients to use (Microsoft requires the action field by default). 2) I separated the header types into a separate file so that it could be reused by the Discovery Service, Connection Service, and hopefully a future Topology Service. I recently removed the use from Discovery, but I think the separation of concerns is still good. The header schema will not need to change with changes in any of the individual protocols. John
On Wed, 12 Dec 2012, John MacAuley wrote:
I had an internal discussion here in Ottawa with my dogs on this exact topic a few months ago when I defined the header.
:-)
We argued for both including and excluding the version field within the header. What swayed me to include it was the concept that if we removed SOAP from the equation, and wanted to continue using the XML schema, then a header with version number let the protocol contents exist independent of the SOAP action.
OK, that at least makes sense. However a new protocol will probably mean changes anyway, as the current messaging scheme as highly based on RPC. Also, in some protocols, say HTTP, this is handled with mime-types. Is there are a urn for what the value should be?
Additionally, the HTTP SOAP action field if 100% optional and I only provided it in the SOAP binding to make it easier for .NET clients to use (Microsoft requires the action field by default).
From section 6.1.1 in SOAP 1.1 spec:
"An HTTP client MUST use this header field when issuing a SOAP HTTP Request." Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Ah yes, but "Basic Profile Version 1.1" clause "R1127 A RECEIVER MUST NOT rely on the value of the SOAPAction HTTP header to correctly process the message." was put in because in SOAP 1.2 the SOAP action dependency was removed. The additional statement from the profile document states "SOAPAction is purely a hint to processors. All vital information regarding the intent of a message is carried in soap:Envelope." Most new SOAP specifications no longer use the SOAP action field. I had just went through the pain of doing Microsoft integration and put it in for better NSI compatibility with MS. John. On 2012-12-12, at 10:20 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
From section 6.1.1 in SOAP 1.1 spec:
"An HTTP client MUST use this header field when issuing a SOAP HTTP Request."
On Wed, 12 Dec 2012, John MacAuley wrote:
Ah yes, but "Basic Profile Version 1.1" clause "R1127 A RECEIVER MUST NOT rely on the value of the SOAPAction HTTP header to correctly process the message." was put in because in SOAP 1.2 the SOAP action dependency was removed.
The nice thing about standards is that there are so many to choose between :-). Is there a decisions on what version of SOAP the NSI protocol should use?
The additional statement from the profile document states "SOAPAction is purely a hint to processors. All vital information regarding the intent of a message is carried in soap:Envelope."
Most new SOAP specifications no longer use the SOAP action field. I had just went through the pain of doing Microsoft integration and put it in for better NSI compatibility with MS.
Interesting. OpenNSA will break without it, but it should not be difficult to change (just annoying). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On Wed, 12 Dec 2012, Henrik Thostrup Jensen wrote:
Is there a decisions on what version of SOAP the NSI protocol should use?
I think we had a case of an implementation (cannot remember which) requiring text/xml as mime-type, which is SOAP 1.1, where as SOAP 1.2 wants application/soap+xml. Maybe the implementation suports both (originally OpenNSA did not specify one, which is what triggered it). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
participants (6)
-
Henrik Thostrup Jensen -
Inder Monga -
Jeroen van der Ham -
Jerry Sobieski -
John MacAuley -
Vangelis Chaniotakis