These are fast responses. It seems that the majority (3:1) is to keep the
non-merging semantics. If we do not hear other objections, we will keep the
current version, but do clarify using the good example from Wendy.
Cheers,
Richard
Hi Wendy,
On Wed, Oct 23, 2013 at 03:23:50PM -0400, Wendy Roome wrote:
> I just noticed a possible problem with the rule for determining the PID
> for an endpoint address. {5.2.1} says,
>
> "When either an ALTO Client or an ALTO Server needs to determine which
> PID in a Network Map contains a particular IP address, longest-prefix
> matching MUST be used."
>
> Now consider the following network map fragment:
>
> PID1: 1.0.0.0/16 1.1.0.0/16 1.2.0.0/16 1.3.0.0/16
> PID2: 1.0.0.0/15
>
> Obviously PID1's definition is inefficient -- those 4 CIDRs are equivalent
> to 1.0.0.0/14. But unless I missed it, nothing in the protocol spec says
> that's illegal.
>
> So what's the PID for 1.0.0.0? I think we all agree that it should be in
> PID2.
I don't agree. It should be in PID1.
That's how longest prefix matching works.
I am not sure whether your example is relevant in pracice. Maybe you
don't like the beahavior of this algorithm in this example, but at least
it's well-defined and deterministic, and you have the possibility to
define your map in a different way (e.g., completely omit PID1 OR PID2,
whatever you prefer).
So I don't think we should add any additional mechanism, exception, etc.
here.
Just my $0.02
Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
