I disagree. The central question is not whether an IP prefix can appear in more than one PID but rather if we allow overlapping PIDs.
For example, what if we use MAC addresses, can they appear in more than one PID? The new text does not cover that. Whether a client ignores the whole map or not is implementation dependent. It can provide an error only for those IP addresses that fall within the prefix, still using the rest of the map. Or can just choose one PID at random as tie break. On 11/4/13 6:44 AM, "Sebastian Kiesel" <[email protected]> wrote: >Hi Wendy, > > >so the conclusion is: >at the end of section 5.2.1 of draft-ietf-alto-protocol-20.txt, >we REMOVE > >- Each endpoint MUST map into exactly one PID. Since longest-prefix >- matching is used to map an endpoint to a PID, this can be >- accomplished by ensuring that no two PIDs contain an identical IP >- prefix. > >and ADD instead > >+ A network map MUST NOT define two or more PIDs that contain >+ an identical IP prefix, in order to ensure that the longest-prefix >+ matching algorithm maps each endpoint into exactly one PID. >+ >+ If an ALTO client receives an invalid network map defining two or >+ more PIDs that contain an identical IP prefix, the ALTO client >+ SHOULD completely ignore the whole network map. > > >OK? I support this change. > >Do you think we should add another paragraph saying that > > MapA: A1 = 10.0.0.0/15 > A2 = 10.0.0.0/16, 10.1.0.0/16 > > is legal, and 10.0.0.1 should be in A2 > >? I don't think that this is neccesssary but I won't object against >adding an explicit statement. > > >What do you think? > >Thanks >Sebastian > > >On Mon, Nov 04, 2013 at 09:18:15AM -0500, Wendy Roome wrote: >> Actually I'm in favor or the second alternative for #2 -- ignore the map >> altogether: >> >> > If an ALTO client receives an invalid network map defining two or >> > more PIDs that contain an identical IP prefix, the ALTO client >> > SHOULD completely ignore the complete network map. >> >> >> Sorry for the confusion! I thought that was #3. >> >> - Wendy >> >> >> On 11/01/2013 15:56, "Sebastian Kiesel" <[email protected]> wrote: >> >> >Hi Wendy, >> > >> >so you are saying that for issue 2) we should go with the second >> >text proposal? I don't have strong feelings about that. >> > >> >What about 3) ? Do you want to propose text? Or should we go without >> >a clarification? >> > >> >Thanks >> >Sebastian >> > >> >On Fri, Nov 01, 2013 at 04:27:30PM -0400, Wendy Roome wrote: >> >> I don't like saying that the client should just ignore all >>occurrences >> >>of >> >> a duplicate CIDR. I think that if the server created a map with >> >>duplicate >> >> CIDRs, the server has a major problem, and I wouldn't trust that >>server. >> >> >> >> After all, even if a server automatically creates the network map >>from >> >> network data, how hard would it be for the server to test for and >>remove >> >> duplicates? Especially because we expect the client to be smart >>enough >> >>to >> >> detect duplicates?? >> >> >> >> There's an old saying: If you add a teaspoon of excrement to a >>barrel of >> >> fine wine, you have a barrel of excrement. If a network map has >> >>duplicate >> >> CIDRs, I think that network map is junk. >> >> >> >> >> >> - Wendy Roome >> >> >> >> On 11/01/2013 15:13, "Sebastian Kiesel" <[email protected]> wrote: >> >> >> >> >Dear all, >> >> > >> >> > >> >> >Let's focus on IP prefixes in PID definitions as this has to be >> >> >clarified before the protocol document can be finalized. >> >> >In other words we are talking about section 5.2.1 of >> >> >draft-ietf-alto-protocol-20.txt. >> >> > >> >> > >> >> >it seems that we could not agree on a tiebreaker algorithm to be >> >> >used by the client if it receives a network map defining multiple >> >> >PIDs each containing the same IP prefix. >> >> > >> >> > >> >> > >> >> >Let me try to summarize with two examples: >> >> > >> >> >MapA: A1 = 10.0.0.0/15 >> >> > A2 = 10.0.0.0/16, 10.1.0.0/16 >> >> > >> >> >is legal, and 10.0.0.1 should be in A2 >> >> > >> >> >this is what follows from the current specification, though it may >> >> >be surprising to some of us. >> >> > >> >> > >> >> >MapB: B1 = 10.0.0.0/15 >> >> > B2 = 10.0.0.0/15, 192.168.0.0/16 >> >> > >> >> >is NOT legal. >> >> > >> >> > >> >> > >> >> >So my proposal to move forward: >> >> > >> >> >1. clarify that this kind of map as in example B is illegal: >> >> > >> >> >In Sec. 5.2.1: >> >> > >> >> >Old: >> >> > >> >> > Each endpoint MUST map into exactly one PID. Since >>longest-prefix >> >> > matching is used to map an endpoint to a PID, this can be >> >> > accomplished by ensuring that no two PIDs contain an identical IP >> >> > prefix. >> >> > >> >> >Replace with: >> >> > >> >> > A network map MUST NOT define two or more PIDs that contain >> >> > an identical IP prefix, in order to ensure that the >>longest-prefix >> >> > >> >> > matching algorithm maps each endpoint into exactly one PID. >> >> > >> >> > >> >> > >> >> > >> >> >2. optional: specify client behavior in this error condition >> >> > >> >> >Append a sentence at the end of 5.2.1. >> >> > >> >> > If an ALTO client receives an invalid network map defining two >>or >> >> > more PIDs that contain an identical IP prefix, the ALTO client >> >> > SHOULD ignore that prefix and behave as if the prefix did not >>occur >> >> > in any PID definition. >> >> > >> >> >or: >> >> > >> >> > If an ALTO client receives an invalid network map defining two >>or >> >> > more PIDs that contain an identical IP prefix, the ALTO client >> >> > SHOULD completely ignore the complete network map. >> >> > >> >> > >> >> > >> >> >3. optional: add a clarification that example A above is legal and >>A2 >> >> >is the result. >> >> > >> >> > >> >> > >> >> > >> >> >I think that we should add 1) and the first text proposal for 2). >> >> >I don't think that we need 3) but I will not object if someone >> >> >comes up with a good text proposal. >> >> > >> >> > >> >> > >> >> >Comments? >> >> > >> >> >Thanks >> >> >Sebastian >> >> >> >> >> >> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
