On Thu, Oct 24, 2013 at 2:43 PM, Sebastian Kiesel <[email protected]>wrote:
> Wendy, > > On Thu, Oct 24, 2013 at 10:33:20AM -0400, Wendy Roome wrote: > > I'm glad to see I can still raise up a controversy! > > > > Here's the problem I saw. Consider two network maps: > > > > > MapA: A1 = 10.0.0.0/14 > > > A2 = 10.0.0.0/15 > > > > > > MapB: B1 = 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16, 10.3.0.0/16 > > > B2 = 10.0.0.0/15 > > > > > PIDs A1 and B1 cover exactly the same set of endpoint addresses. So the > > naďve view is that those two network maps are dentical. > > > > But if we strictly apply the "longest prefix match" rule, they are NOT > > identical. In MapA, 10.0.0.0 is in A2, while in MapB, it's in B1. To me, > > that's counterintuitive. If y'all like that, fine. I can live with that! > > Believe it or not, but for me this client behavior *is* intuitive. > Another story is, why would one create such a strange map? > > > > > Maybe in a scenario like this: > > At time t0: > > C1 = 10.0.0.0/14 > C101 = 10.0.0.0/16, 10.2.0.0/16 > C102 = 10.1.0.0/16, 10.3.0.0/16 > and the corresponding cost map tells you (in an appropriate metric): > > C1 is manually and statically configured as a catch-all for my whole > prefix. I can't say where these IP addresses are located exactly, but > at least they are somewhere in my network. > > C101 is automatically exported from the network management system. The > routing protocol says these prefixes are in my westcoast data center > and the detailed properties are as follows: foo > > C102 is ... eastcoast ... : bar > > > some time later, all prefixes move to westcoast. So at time t1: > > if the management system / map generator is not too clever: > > D1 = 10.0.0.0/14 > D101 = 10.0.0.0/16, 10.2.0.0/16, 10.1.0.0/16, 10.3.0.0/16 > D102 = (empty or undefined) > > > Interesting scenario. > In this case for me it would be intuitive to say that matching > 10.0.0.1 to D101 should give better information than D1. > > if the management system / map generator is a bit more clever and > figures out that prefixes can be aggregated, but not clever enough > to remove the "screened" default entry: > > 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? Richard > Any thoughts on that? > > Thanks, > Sebastian >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
