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
