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]> 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] > https://www.ietf.org/mailman/listinfo/alto > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
