If the client just discards the both instances of the duplicate CIDR, in
most cases, the endpoint addresses under that CIDR will end up in the
default PID -- the one with 0.0.0.0/0. As a result, the costs to or from
those endpoints are probably useless.
Here's another alternative: if a client detects a duplicate CIDR, the
client removes that CIDR from all PIDs, and adds it to a list of
"duplicate CIDRs". When the client maps an address to a PID, if the
longest prefix match is a CIDR in the "duplicate" list, then the client
assumes that the ALTO server cannot return a cost to or from that
endpoint. Eg, the cost is unknown.
A client could easily implement that by creating a PID with an otherwise
invalid name, like "*DUPLICATES*", and moving those CIDRs to that phantom
PID. The ALTO server will never return that PID in a cost map, so to the
client, the costs for those addresses are unknown.
- Wendy Roome
On 11/04/2013 12:06, "Reinaldo Penno (repenno)" <[email protected]> wrote:
>>
>>I think it does make sense to mandate a client behavior.
>>
>>If we can agree on a specific tie break algorithm, fine. If we agree to
>>say "just ignore the prefix in question but not the whole map", fine.
>>But I think we should agree on something.
>>
>>We shouldn't repeat the good old days of the WWW, where web servers sent
>>special versions of the content to some user agents as workaround for
>>known bugs in these browsers, and user agents pretended to be a
>>different one to get the "right" content ...
>
>
>I do not think this we are comparing apples to apples.
>
>A better comparison is: If a router gets a bad route (say, pointing back
>to its own interface) , does it throw away the entire routing table?
>
>If client throws away the entire map, it has no guidance, falls back to
>regular behavior
>If client disregard only that prefix, it falls back to regular behavior
>for that prefix.
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
