Richard, On Thu, Oct 24, 2013 at 05:06:07PM -0400, Y. Richard Yang wrote: > On Thu, Oct 24, 2013 at 4:31 PM, Sebastian Kiesel <ietf-a...@skiesel.de>wrote: > > > 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 <ietf-a...@skiesel.de > > >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? > > > > Here is a concern. If we specify a "recovery" operation such as 2d) and > 2e), then we will not need to specify the no-duplicate requirement, as we > are essentially saying "X is not allowed, but if you do X, then we are OK > and understand X as this..." It is a bit contradicting.
right. what I didn't say explicitly: options 1) and 2?) are mutually exclusive. if we go for 2?) we can add a "note" or maybe a "recommendation" which says that clear and non-overlapping map definitions should be preferred for the sake of easier readability. But we should not declare multiple occurences of one prefix as illegal, and we should also avoid the term "ambiguous", because with a well-defined algoritm the result may be unexpected or counterintuitive but it is unambiguous. Sebastian _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
