On Thu, Oct 24, 2013 at 4:31 PM, Sebastian Kiesel <[email protected]>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 <[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? > 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. WIthout specifying any "recovering" operation seems to be cleaner, but I am willing to learn more on the basic principles of handling non-confirming behaviors. It is a good discussion! Richard > S. >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
