Wendy,

On Thu, Oct 24, 2013 at 10:33 AM, Wendy Roome <[email protected]>wrote:

> I'm glad to see I can still raise up a controversy!
>
>
It is a very good discussion!


> 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!  But it
> should be documented, because I think this has serious potential for
> misinterpretation.
>

Yes. We should document it clearly in the document. The semantics is that:

(1) No prefix should belong to two PIDs.; (2) One obtains the union of all
prefixes defined by all PIDs; call this set of prefixes P; (3) The longest
prefix matching an IP address is identified in P. (4) The PID containing
the prefixed identified in (3) is the PID of the IP address.


>
> And the next bake-off should have a test case for this -- eg, the network
> map should define PIDs like B1 and B2, and there should be a test that
> 10.0.0.0 is in B1, not B2.
>
>
Good idea to test this in the next bake-off!

Richard


> - Wendy Roome
>
> From: "Y. Richard Yang" <[email protected]>
> Date: Wed, October 23, 2013 18:47
> To: Sebastian Kiesel <[email protected]>
> Cc: IETF ALTO <[email protected]>, Wendy Roome <[email protected]>
>
> Subject: Re: [alto] Problem with "longest prefix" rule for mapping
> endpoints to PIDs
>
> 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
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to