Vijay, I took a quick look over the test cases and although the details are not complete for some of them they look a fairly reasonable set of tests.
Some comments: 1) I wonder whether it is worthwhile to define at least one of the PIDs as containing multiple IP subnets as in real life PIDs are likely to contain >1 subnet. 2) As part of the IPv6 test cases I think some PIDs should contain a mixture of both IPv4 & IPv6 PIDs while other PIDs contain purely IPv4 or IPv6. 3) I assume that the specific hostnames and URLs used in the test cases are purely used for example purposes and the expectation is that the client will be configured with the location of the IRD and then discover the other services based on the contents on the obtained IRD? As the IRD is the key resource for discovering ALTO services and therefore obtaining data from ALTO servers dynamic service discovery based on the IRD is pretty critical for interoperability between clients/servers. You also asked: > Miscellaneous notes > > 1) Section 4.2.1 says that "Each endpoint MUST map into exactly one > PID." > > What happens if a client finds out that the above is not true? IMO: If a client discovers that a given CIDR block is present in more than one PID then the client should be free to pick any of the PIDs that the block is a member of according to local configuration/policy. If a server discovers that a given CIDR block is present in more than one PID then the server should be free to pick any of the PIDs the block is a member of according to local configuration/policy. However for a given resource the same decision should be made for a given version of the underlying map (i.e. subsequent requests generate the exact same result and URLs that are served by multiple implementation instances also generate the exact same result regardless of which implementation instance is returning the response). Ben On 22 Jun 2011, at 16:21, Vijay K. Gurbani wrote: > Folks: Here is the first draft of the ALTO interoperability test > we are scheduling in Quebec City. > > Please go through this and suggest any fine-tuning we need to do > on the test suite. Some of the test cases are more fleshed out > than others (complete with request and response), others need some > more work, and if anyone will like to pick some of the test > cases that need some more work and complete them, please let > the chairs know. > > Similarly, if we need to add any additional test cases or you feel > that we need to remove some of the existing ones, please feel > free to indicate so on the list. > > If there is anything egregiously wrong with the IP address blocks > or costs, please indicate so. > > I suspect that we will go through a couple of iterations to fully > finish the test cases, but the this should give you a good idea > of what to interoperate. > > ---- BEGIN ALTO INTEROPERABILITY DOCUMENT (Version 0.1) > > For the ALTO interoperability, we will consider the following topology > from the view point of a service provider: > > PID IP Address Block > ------------------------------- > mypid1 10.0.0.0/8 > mypid2 192.168.0.0/16 > mypid3 192.168.10.0/24 > peeringpid1 128.0.0.0/16 > peeringpid2 130.0.0.0/16 > transitpid1 132.0.0.0/16 > transitpid2 135.0.0.0/16 > defaultpid 0.0.0.0/0 > > And here is the cost map for the above topology: > > Source PID Destination PID Cost (mode: numerical) > -------------------------------------------------------------------- > mypid1 mypid1 0 > " mypid2 0 > " mypid3 0 > " peeringpid1 0 > " peeringpid2 0 > " transitpid1 5 > " transitpid2 10 > " defaultpid 4 > mypid2 mypid1 0 > " mypid2 0 > " mypid3 0 > " peeringpid1 0 > " peeringpid2 0 > " transitpid1 7 > " transitpid2 8 > " defaultpid 4 > mypid3 mypid1 0 > " mypid2 0 > " mypid3 0 > " peeringpid1 0 > " peeringpid2 0 > " transitpid1 8 > " transitpid2 8 > " defaultpid 5.1 > > Test Cases > > 1) Retrieving the Information Resource Directory (IRD, Section 7.6) > > - Client retrieve IRD through a well known URI: > http://alto.ietf.org/directory > - Server returns the following directory: > (TBD) > > 2) Longest prefix match (c.f. Section 4.2.1) > > - Client retrieves a PID for IP address 192.168.1.23 > Use the following request: > > POST /endpointprop/lookup HTTP/1.1 > Host: alto.ietf.org > Content-Length: ... > Accept: application/alto-endpointprop+json > > { > "properties" : [ "pid" ], > "endpoints" : [ "ipv4:192.168.1.23" ] > } > > - Server returns mypid2 using the following response: > > HTTP/1.1 200 OK > Content-Length: ... > Content-Type: application/alto-endpointprop+json > > { > "meta" : {}, > "data": { > "ipv4:192.168.1.23" : { "pid": "mypid2" } > } > } > > 3) Longest prefix match (c.f. Section 4.2.1) > > - Client retrieves a PID for IP address 192.168.10.23 > Use the following request: > > POST /endpointprop/lookup HTTP/1.1 > Host: alto.ietf.org > Content-Length: ... > Accept: application/alto-endpointprop+json > > { > "properties" : [ "pid" ], > "endpoints" : [ "ipv4:192.168.10.23" ] > } > > - Server returns mypid3 using the following response: > > HTTP/1.1 200 OK > Content-Length: ... > Content-Type: application/alto-endpointprop+json > > { > "meta" : {}, > "data": { > "ipv4:192.168.10.23" : { "pid": "mypid3" } > } > } > > > 4) Returning default PID: > > - Client retrieves a PID for IP address 201.1.13.12 > Use the following request: > > POST /endpointprop/lookup HTTP/1.1 > Host: alto.ietf.org > Content-Length: ... > Accept: application/alto-endpointprop+json > > { > "properties" : [ "pid" ], > "endpoints" : [ "ipv4:201.1.13.12" ] > } > > - Server returns defaultpid using the following response: > > HTTP/1.1 200 OK > Content-Length: ... > Content-Type: application/alto-endpointprop+json > > { > "meta" : {}, > "data": { > "ipv4:201.1.13.12" : { "pid": "defaultpid" } > } > } > > 5) Retrieving a network map (Section 4) > > - Client uses information from IRD to retrieve a network map. > - Server returns the following: > (TBD) > > 6) Retrieving a cost map (Section 5) > > - Client uses information from IRD to retrieve a cost map. > - Server returns the following: > (TBD) > > NOTE: Make sure that the vtag in the response for the cost > map is the same as the vtag in the response for Test case > 5. > > 7) Error: JSON parsing error (Section 7) > > - Client sends a malformed JSON body in the request (details TBD) > - Server returns HTTP response code of 400 with ALTO error code > of E_JSON_SYNTAX (c.f., Table 1). > > 8) Error: Required field missing (Section 7) > > - Client sends a request with a missing field (details TBD) > - Server returns HTTP response code of 400 with ALTO error code > of E_JSON_FIELD_MISSING (c.f., Table 1). > > 9) Error: Unexpected JSON value (Section 7) > > - Client sends a request with a JSON value of unexpected type > (details TBD) > - Server returns HTTP response code of 400 with ALTO error code > of E_JSON_VALUE_TYPE (c.f., Table 1). > > 10) Error: Invalid JSON cost mode (Section 7) > > - Client sends a request with a cost mode of 'foo' > - Server returns HTTP response code of 400 with ALTO error code > of E_JSON_COST_MODE (c.f., Table 1). > > 11) Error: Invalid JSON cost type (Section 7) > > - Client sends a request with a cost type of 'foo' > - Server returns HTTP response code of 400 with ALTO error code > of E_JSON_COST_TYPE (c.f., Table 1). > > 12) Error: Invalid JSON property type (Section 7) > > - Client sends a request with an invalid property type (details TBD) > - Server returns HTTP response code of 400 with ALTO error code > of E_JSON_PROPERTY_TYPE (c.f., Table 1). > > 13) Error: multiple errors in request (Section 7) > > - Client sends a request with a missing required field and an > invalid cost mode ('foo') > - Server should detect at least one error and return that in a > response. The server chooses which error to report. > > Question: If the server is capable of detecting and reporting > multiple errors, then what? How does it let the client know? > > 14) Error: send a request with a bad URI > > - Client sends the following request: > > GET /foo/bar HTTP/1.1 > ... > > - Server responds with: > (TBD) > > 15) Change in network map (Section 5.3) > > - Add a new network, changing the map. For example, add the > following subnet 201.1.2.0/24 to peeringpid2 giving the new > network map entry for peeringpid2 as follows: > > peeringpid2 130.0.0.0/16, 201.1.2.0/24 > > - Have a client retrieve the new network map. > > - The Version tag on the network map should be different than the > one retrieved in Test Case 5. > > 16) Filtered network map (Section 7.7.3) > TBD > > 17) Filtered cost map (Section 7.7.3.2, Section 7.7.2.2) > TBD > > 18) Endpoint cost service (Section 7.7.5) > TBD > > 19) IPv6 test cases > (TBD) > > Miscellaneous notes > > 1) Section 4.2.1 says that "Each endpoint MUST map into exactly one > PID." > > What happens if a client finds out that the above is not true? > > ---- END ALTO INTEROPERABILITY DOCUMENT (Version 0.1) > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
