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)
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.
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.
Any thoughts on that?
Thanks,
Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
