The examples show that we have two options:
1. Limit "uses" to one network map for end point properties, filtered
network map, and filtered cost map;
2. Allow "uses" to include multiple network maps for the preceding case,
and allow <network-map-id>.pid notation in
- "properties" of end point property query,
- the queried PIDs in network and cost map filtering,
- response in end point property.
You are right on that the notation can then allow querying cross network
maps, e.g., in hierarchical topology.
My personal vote is to go the second path, setting the path for general SQL
syntax and semantics, and the complexity appears to be reasonable, to me. I
am willing to go along 1 as well if others prefer it.
Richard
On Tuesday, July 30, 2013, Richard Alimi wrote:
> My personal opinion when looking at these options is that we're making it
> too complicated in the base protocol, and going past the point of fixing
> bugs. Apologies for not being able to make it to the session on Monday, but
> I personally would prefer the IRD to be more verbose and just have each
> filtered cost map or endpoint property service be allowed to specify at
> most one network map. Would it then be reasonable to treat optimizations
> (such as querying across multiple network maps, and reducing number of
> entries in the IRD) as extensions?
>
>
> On Mon, Jul 29, 2013 at 2:05 PM, Y. Richard Yang
> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>
> > wrote:
>
>> Let's nail down some more on the details on what end point properties,
>> filtered network map and filtered cost map may look like, if we use the SQL
>> syntax/semantics as guide lines.
>>
>> ** End point properties:
>>
>> IRD:
>> ===
>> "netmap1" : // network map
>>
>> "netmap2" : // network map
>>
>> "netmap3" : // network map
>>
>> "endpoint-property",
>>
>> "uri" : "http://alto.example.com/endpointprop/lookup";,
>> "media-type" : "application/alto-endpointprop+json",
>> "accepts" : "application/alto-endpointpropparams+json",
>> "capabilities" : {
>> "prop-types" : [ "pid", "example-prop" ]
>> },
>> "uses": [ "netmap1", "netmap2" ] // query will have SQL equivalent of
>> // using three tables in "from":
>>
>> // netmap1, netmap2, epp_global
>>
>> // there could be one entry with uses "netmap3"
>>
>> }
>>
>>
>>
>> Endpoint property query:
>> ===================
>>
>> POST /endpointprop/lookup HTTP/1.1
>> Host: alto.example.com
>> Content-Length: 96
>> Content-Type: application/alto-endpointpropparams+json
>> Accept: application/alto-endpointprop+json,application/alto-error+json
>>
>> {
>> "properties" : [ "netmap1.pid", "netmap2.pid", "example-prop" ],
>> "endpoints" : [ "ipv4:192.0.2.34", "ipv4:203.0.113.129" ]
>>
>> }
>>
>> Response:
>> ========
>>
>> HTTP/1.1 200 OK
>> Content-Length: TBA
>> Content-Type: application/alto-endpointprop+json
>>
>> {
>> "meta" : {
>>
>> "vtags" : { "netmap1": "1266506239", "netmap2":"124657657"},
>>
>>
>> },
>> "data": {
>> "map" : {
>> "ipv4:192.0.2.34" : { "netmap1.pid" : "PID1",
>> "netmap2.pid" : "pidx",
>> "example-prop": "1" },
>> "ipv4:203.0.113.129" : { "netmap1.pid" : "PID3"
>>
>> "netmap2.pid" : "pidx"}
>>
>> }
>> }
>> }
>>
>>
>> ** Filtered Network Map
>>
>> IRD:
>> ===
>> "netmap1" :
>>
>> "netmap2" : ...
>>
>> "netmap3" :
>>
>> "filtered-network-map": {
>> "uri" : "http://custom.alto.example.com/networkmap/filtered";,
>> "media-type" : "application/alto-networkmap+json",
>> "accepts" : "application/alto-networkmapfilter+json",
>>
>> "uses" : ["netmap1", "netmap3"] // can select from 2 network tables
>>
>> }
>>
>> Indicates that the URI can filter two network maps: "netmap1" and
>> "netmap3".
>>
>> Query:
>> =====
>>
>> POST /networkmap/filtered HTTP/1.1
>> Host: custom.alto.example.com
>> Content-Length: TBA
>> Content-Type: application/alto-networkmapfilter+json
>> Accept: application/alto-networkmap+json,application/alto-error+json
>>
>> {
>> "netmap1.pid": [ "PID1", "PID2" ]
>>
>> }
>>
>> Note that I changed "pids" to pid in the line right above to be
>> consistent with SQL syntax.
>>
>> Note that I do not see value of filtering on two networks (which general
>> SQL syntax can allow, but I do not see value.) In particular, should we
>> support generic SQL syntax, the query could be:
>>
>> {
>> "netmap1.pid": [ "PID1", "PID2" ],
>>
>> "netmap2.pid": [ "pidx" ]
>>
>> }
>>
>>
>> Response (one network map filtering only):
>> ========
>>
>> HTTP/1.1 200 OK
>> Content-Length: TBA
>> Content-Type: application/alto-networkmap+json
>>
>> {
>> "meta" : {
>>
>> "vtags" : { "netmap1" : 1266506139 },
>>
>>
>> },
>> "data" : {
>> "map" : {
>> "PID1" : { // no need to write netmap1.PID1
>> "ipv4" : [
>> "192.0.2.0/24",
>> "198.51.100.0/24"
>> ]
>> },
>> "PID2" : {
>> "ipv4": [
>> "198.51.100.128/24"
>> ]
>> }
>> }
>> }
>> }
>>
>>
>> ** Filtered Cost Map
>>
>> IRD:
>>
>> "filtered-cost-map" : {
>> "uri" : "http://custom.alto.example.com/costmap/filtered";,
>> "media-type" : "application/alto-costmap+json",
>> "accepts" : "application/alto-costmapfilter+json",
>> "capabilities" : {
>> "cost-constraints" : true,
>> "cost-type-names" : [ "num-routing", "num-hop",
>> "ord-routing", "ord-hop" ]
>> },
>> "uses": [ "netmap1", "netmap2" ]
>>
>> Semantics: it can query filtered cost map for network map based on either
>> netmap1 or netmap2, for 4 cost type names
>>
>> Query (limit to filter on one network map):
>> =====
>>
>> POST /costmap/filtered HTTP/1.1
>> Host: custom.alto.example.com
>> Content-Type: application/alto-costmapfilter+json
>> Accept: application/alto-costmap+json,application/alto-error+json
>>
>> {
>> "cost-type" : {"cost-mode": "numerical",
>> "cost-metric": "routingcost"},
>> "netmap1.pid" : { // if it is netmap2.pid, it will be based on netmap2
>> "srcs" : [ "PID1" ],
>> "dsts" : [ "PID1", "PID2", "PID3" ]
>> }
>> }
>>
>>
>> Response:
>> ========
>>
>> HTTP/1.1 200 OK
>> Content-Length: TBA
>> Content-Type: application/alto-costmap+json
>>
>> {
>> "meta" : {
>>
>> "cost-type": {"cost-mode" : "numerical",
>> "cost-metric" : "routingcost"},
>> "vtags" : {
>> "netmap1": "1266506139"
>> },
>>
>> },
>>
>> "data" : {
>> "map" : {
>> "PID1": { "PID1": 0, "PID2": 1, "PID3": 2 }
>> }
>> }
>> }
>>
>>
>> Do they address all problems? Are they necessary?
>>
>> Richard
>>
>>
>> _______________________________________________
>> alto mailing list
>> [email protected] <javascript:_e({}, 'cvml', '[email protected]');>
>> https://www.ietf.org/mailman/listinfo/alto
>>
>>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
