Vijay, On 24 Jun 2011, at 03:19, Vijay K. Gurbani wrote: >> 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. > > What triggers the choice of an ALTO server returning an IPv6 > address? An IPv6 address sent by the client and indicated as > the source address? Returning IPv6 addresses to clients who > have indicated a source address of IPv4, obviously, does not > make sense.
Good questions and operation of ALTO in mixed IPv4 & IPv6 environments is not something I have given much thought to. For the Network Map (and filtered network map) service it doesn't seem unreasonable to say that the ALTO server returns all address types it has - the protocol certainly allows for that already. For the Cost Map (and filtered cost map) service it seems less obvious. For example, if two PIDs both contain a mixture of IPv4 & IPv6 prefixes what does that mean? Maybe it doesn't matter because ALTO isn;t saying anything about routing reachability only that any combination of endpoint addresses from each PID are the same cost apart. However it does also raise the question of how an ALTO server can indicate that the cost between two PIDs is infinite (i.e. connectivity between those PIDs is not possible) - or is that what a cost of 0 means (in which case that needs explicitly mentioning in the protocol draft because I couldn't find it in there). >> 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). > > This all sounds reasonable. The question I have is how much of > this should be captured in the protocol document. That document > simply states that there is a 1-1 relationship between an > endpoint and PID. We can leave it at that and not worry about > the question I ask above. However, if we go down the route of > providing heuristics to deal with 1-N mapping, then we should > just as well put it in the document itself. > > Thoughts? I think we should say something along the lines of what I suggest (it probably doesn't need to go in much, if any, more detail either) otherwise we risk interoperability issues where one client may interpret such a map as invalid while others do not. Ben _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
