I think the protocol document should have an explicit example, such as
"MapB", as well as giving Richard's algorithm.

Case in point: Two years ago, when I first started working on an ALTO
server, I implemented the algorithm Richard described, exactly as is. For
"MapB", my server does indeed say that 10.0.0.0 is in B1, not B2.

And until I tried that test case, I had no idea it would behave that way. I
really thought it would say 10.0.0.0 is in B2.

So I think we need to hit people over the head with this one.

- Wendy Roome

From:  "Y. Richard Yang" <[email protected]>
Date:  Thu, October 24, 2013 11:47
To:  Wendy Roome <[email protected]>
Cc:  Sebastian Kiesel <[email protected]>, IETF ALTO <[email protected]>
Subject:  Re: [alto] Problem with "longest prefix" rule for mapping
endpoints to PIDs

 
> Here's the problem I saw. Consider two network maps:
> 
>> MapA:  A1 = 10.0.0.0/14 <http://10.0.0.0/14>
>>                A2 = 10.0.0.0/15 <http://10.0.0.0/15>
>> 
>> MapB:  B1 = 10.0.0.0/16 <http://10.0.0.0/16> , 10.1.0.0/16
>> <http://10.1.0.0/16> , 10.2.0.0/16 <http://10.2.0.0/16> , 10.3.0.0/16
>> <http://10.3.0.0/16>
>>                B2 = 10.0.0.0/15 <http://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.


_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to