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
