From: "Y. Yang" <[email protected]<mailto:[email protected]>> Date: Thursday, October 24, 2013 12:51 PM To: Cisco Employee <[email protected]<mailto:[email protected]>> Cc: Wendy Roome <[email protected]<mailto:[email protected]>>, IETF ALTO <[email protected]<mailto:[email protected]>> Subject: Re: [alto] Problem with "longest prefix" rule for mapping endpoints to PIDs
On Thu, Oct 24, 2013 at 1:23 PM, Reinaldo Penno (repenno) <[email protected]<mailto:[email protected]>> wrote: I disagree again. If you have a prefix 0.0.0.0/0<http://0.0.0.0/0> in one PID does that mean no other prefix can appear in any other PID? it means that all other prefixes will overlap with it. Not sure I understand the issue. Which condition among the three: (1) No prefix should belong to two PIDs.; [RP] Wendy pointed out that this is already in the draft. Thanks for that. But I'm not sure this is necessary, but that is for another time. (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. [RP] What is needed to be said? Above is already in the draft. The way I see it the draft already has everything needed. Is it (1)? Richard The prefixes below could have been imported from BGP at t=0 and at t=1 they will be broken up. Or the PIDs can have different properties (as we discussed before). From: "Y. Yang" <[email protected]<mailto:[email protected]>> Date: Thursday, October 24, 2013 8:47 AM To: Wendy Roome <[email protected]<mailto:[email protected]>> Cc: IETF ALTO <[email protected]<mailto:[email protected]>> Subject: Re: [alto] Problem with "longest prefix" rule for mapping endpoints to PIDs Wendy, On Thu, Oct 24, 2013 at 10:33 AM, Wendy Roome <[email protected]<mailto:[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<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. 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]<mailto:[email protected]>> Date: Wed, October 23, 2013 18:47 To: Sebastian Kiesel <[email protected]<mailto:[email protected]>> Cc: IETF ALTO <[email protected]<mailto:[email protected]>>, Wendy Roome <[email protected]<mailto:[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
