Well to address Inder's thoughts about having the segmentation returned... I do seem to recall that we decided to shelve "special" queries until we had more time to talk through the use cases and appropriate service models and semantics. A "normal" Query would return the PA's local state for the reservation, and the as-built as far as the user's requested reservation parameters are concerned including defaulted parameters as appropriate. (I don't recall any "prefered" paramaters...) The normal as built information would be the summary of what the PA committed to deliver to the RA (for instance the summary Frame Loss Rate, or the summary latency, or summary MTU.) But nothing beyond that. This is the "user stuff". Since the PA segmentation is solely an internal policy decision of the PA, and actually constitute independent connection requests of the local NSA, this could be considered internal information not privy to the parent RA, at least not under the same authorization as the service request itself. Ie. the PA must be allowed to authorize all the internal network transport segmentation information separately. Thats "network stuff". Not the same s "user stuff" :-) Further, the local NSA may not even use the same authorization credentials or service parametrs for the children as the parent. So that even if the NSA returned the segmentation to the parent, there is no guaranty that the parent will be able to query the respective segment PAs for their information. And I am sure all networks will love divulging their authorization credentials to external agents (:-) If thats not enough to convince you of the futility of it all, there is nothing to stop the local NSA from virtualizing the connection - I.e. building a tunnel directly to the destination network through 25 transit networks, installing that path in its topology DB, and then using a single segment for the actual request from here to there. Then it all gets hidden from the query anyway because the tunnel was not part of the request segmentation. To be clear, it *can* work - all we need to do is to think through the query processes and the authorization requirements, and the primitive parameter set(s). But there is a lot to discuss even for such a simple seeming request. Can we shelve the "special" query until V2? J On 3/14/11 12:40 PM, John MacAuley wrote:
Okay, sounds good. I have it in the WSDL now, but it is easy enough to remove.
I think we had agreed at GLIF that queries would be (for now) just returning the PA's state and the request parameters as-built. That there was no walking the tree implied at this time...?
J