On Thu, Oct 24, 2013 at 3:56 PM, Reinaldo Penno (repenno) <[email protected] > wrote:
> > > From: "Y. Yang" <[email protected]> > Date: Thursday, October 24, 2013 12:51 PM > To: Cisco Employee <[email protected]> > Cc: Wendy Roome <[email protected]>, IETF ALTO <[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]> wrote: > >> I disagree again. If you have a prefix 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. > > Good statement. No-duplicate is not a necessary condition, but only a sufficient condition. The wording in the current draft is "can", as Sebastian pointed out. We often use "can" to imply "only sufficient" in such a setting. It is not necessary when one considers the following case (the duplicated prefix is dominated by a more specific prefix both PIDs). But for now, I am fine with Sebastian's wording of enforcing the sufficient condition. > (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. > > > The current draft already has everything. Putting the conditions together is to make potential issues more explicit, and can make the draft easier to read. Richard > 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]> >> Date: Thursday, October 24, 2013 8:47 AM >> >> To: Wendy Roome <[email protected]> >> Cc: IETF ALTO <[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] >> > 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
