On 11/4/13 8:11 AM, "Sebastian Kiesel" <[email protected]> wrote:
>Reinaldo, > >On Mon, Nov 04, 2013 at 03:41:58PM +0000, Reinaldo Penno (repenno) wrote: >> 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. > >section 5.2.1 is about the endpoint address type "IP address". >This is what has to be resolved before we can publish the base protocol. The current text seems perfect fine. > >If you want to use MAC addresses as endpoint addresses, you will have >to write a separate document that defines this address type, which may >define other rules regarding m:n mappings to PIDs. > >> 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. > >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. > > >Just my $0.02 >Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
