On Thu, Oct 24, 2013 at 04:02:03PM -0400, Y. Richard Yang wrote: > On Thu, Oct 24, 2013 at 2:43 PM, Sebastian Kiesel <[email protected]>wrote:
[same prefix in the definition of two PIDs, e.g.] > > E1 = 10.0.0.0/14 > > E101 = 10.0.0.0/14 > > E102 = (empty or undefined) > > > > Again, the intuitive answer is that E101 would probably give better > > results than E1. But what does the spec say? All I could find was: > > > > > > Each endpoint MUST map into exactly one PID. Since longest-prefix > > matching is used to map an endpoint to a PID, this can be > > accomplished by ensuring that no two PIDs contain an identical IP > > prefix. (sec. 5.2.1.) > > > > > > This wording seems a bit strange to me. Does the "can" in the second > > sentence suggest that there are alternatives? I think this should be > > reworded. I see several options: > > > > 1. clarify what we have now, e.g.: > > > > A valid network map MUST NOT define two or more PIDs which contain > > an identical IP prefix, in order to ensure that the longest-prefix > > matching algorithm maps each endpoint into exactly one PID. > > > > > A good clarification. > > > > 2. specify what should happen if a map contains two PIDs with the > > same prefix: > > > > 2a) the client may randomly chose one > > 2b) the client must use the pid with the prefix that appeared > > first in the json structure > > 2c) the client must use the pid with the prefix that appeared > > last in the json structure > > 2d) the client must lexicographically sort the PID names > > of PIDs that contain the prefix and take the first one > > 2e) the client must lexicographically sort the PID names > > of PIDs that contain the prefix and take the last one > > > > > > I'd prefer one of the 2d) or 2e) options. > > > > > > If I have to choose among the five choices, 2d) and 2e) look reasonable. > But for this case, a simpler statement is that the server misbehaved, and > sends a wrong piece of information, and our protocol does not have a 3rd > step to send feedback to the server. It falls to the domain of client > verifying server information. I would classify it as a case that can be > handled by Section 15.2? Does this make sense? Our protocol design indeed does not provide a mechanism by which the client could inform the server that the server's previous reply could not be understood or was "illegal". Exactly because of that it seems tempting to me to not define this (admittedly questionable) map layout as "illegal", but instead define a deterministic and sort-of reasonable client behavior for that case. If you are a server operator and don't like that behavior, just define your maps in an unambiguous way. What do you think? S. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
