Hi Ben, On Mon, Jun 27, 2011 at 1:43 PM, Ben Niven-Jenkins <[email protected]> wrote: > Vijay, > > On 27 Jun 2011, at 17:23, Vijay K. Gurbani wrote: > >> As individual ... >> >> In reference to [1], where we discuss whether or not there >> should be a 1-1 relationship between an IP address and >> a PID, and if it is not, how should we handle it? >> >> On 06/24/2011 10:46 AM, Ben Niven-Jenkins wrote: >>> 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: The bigger question to me is: is it indeed valid to have >> a 1:N mapping between an IP address and a PID? If it is not, >> then we leave this to the category of configuration errors and >> not discuss how to handle it in the draft (the draft cannot >> provide hedges against every MUST and MUST NOT). > > I have no issue with the current requirement that for a given IP address a > client should be able to resolve one (and only one) PID via longest prefix > matching and I'm not suggesting we change that. > > However I do think that a sentence or two on what it means when such a > scenario happens is useful for interoperability. > > For example, if my client uses the network map service to obtain the complete > network map and discovers that a particular IP address exists in two PIDs > (i.e. a longest prefix match would return two PIDs), how is my client > supposed to interpret the network map: > > a) Does it mean the entire network map is invalid and I should throw it all > away? > b) Does it mean those PIDs containing the duplicate IP address are invalid > and I must disregard their complete contents but the rest of the map is > useable? > c) Does it mean that those PIDs containing the duplicate IP address are valid > (along with the rest of the network map) provided I disregard the duplicate > IP addresses? > d) Does it mean I am allowed to make a local decision as to which PID is the > correct PID for that IP address? > > IMO (a) & (b) require a client to fully validate the network map looking for > duplicate IP addresses before using any portion of it can be considered > useable. (c) & (d) allow a client to discover & recover from an inconsistency > at "run time". > > Validating the entire network map before using it may not have a significant > performance impact for an ALTO client in some P2P software where the number > of PIDs and IP prefixes in the network map is likely to be small, however for > some CDN use cases it could well be the case that there are thousands of PIDs > and millions of individual prefixes in a single network map. A simple example > would be if one wanted to represent in an ALTO network map a geo-location > database containing the entire global routing table. >
If I were implementing a client, I would choose (d) in the interest of Postel's Law. I would also send an email to the ALTO Server's provider or implementer notifying them that it is not compliant and that they should stop it :) Saying something in the protocol is okay with me, but a concern is getting into the habit of trying to find and suggest possible behaviors in case any of the MUST / MUST NOT's in the document are violated. Rich > Ben > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
