Re: [addr-select-dt] Proposed default policy table

[Arifumi Matsumoto <[e-mail]>]

Hi,

On 2010/07/12, at 16:13, Tim Chown wrote:

> I have one other topic to add which I can't remember whether I posted about recently or not, so apologies if I'm repeating myself.
> 
> In undertaking some work recently on router-based hints for address selection, we found that we could improve address selection behaviour for hosts by using a new ICMP-based message to query a router or route server for an ordered list of address pairs to use for given candidate addresses.  The issue that came up was that if the host were to cache the result, and we chose to cache it within the RFC3484 policy tables, can we change/augment the current syntax/format to accommodate that?

That approach also should have an issue of policy merge/conflict.

When we think about merging process, we may have to think about this
kind of approach, if we think it looks like some advantages in merging.

When we think about non-merging based solution, do we have to think
about this approach ? Which means, policy table can store one ICMPv6
message at a time ?


> 
> Tim
> 
> On 12 Jul 2010, at 00:52, Aleksi Suhonen wrote:
> 
>> Hi,
>> 
>> Tony wrote:
>>> I suggest leaving 10, 40,&  80 in the precedence so people can move IPv4 or
>>> ULA around without feeling the need to rewrite the other labels (they don't
>>> have to, but an obvious hole to park it in reduces confusion).
>> 
>> The number of bits in the precedence value has not been defined, but I understand that most implementations use at least 32 bits anyway. I would like to see the default precedence values multiplied by 100 to leave more room for algorithmically generated entries and manual tinkering.
>> 
>> There are only 4 values available between fc00::/8 and fd00::/8 for example. Those could be easily consumed after a couple of corporate fusions.
>> 
>> I guess the idea has been that local administration can override all values to their liking. However, my understanding of the best practises for system and network administration is that the defaults are changed as little as possible. And the defaults should preferably "shine through" from under local modifications. This means that when the defaults are changed due to some software update, they might adversely interfere with the local changes.
>> 
>> I don't mind it if the default precedences are multiplied by even more than a hundred, I just feel it is important that there should be more space between the default values.
>> 
>> Tony Hain also wrote:
>>> Precedence  Label  Prefix
>>> ----------  -----  --------------------------------
>> ...
>>>         1      6  fec0::/16
>> 
>> Aren't we removing site local completely while we're at it? Or if it should be kept around, then why not add 3ffe::/16 too for the same reason?
>> 
>> -- 
>> 	Aleksi Suhonen
>> 	Department of Communications Engineering
>> 	Tampere University of Technology
>> _______________________________________________
>> addr-select-dt mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
> 
> _______________________________________________
> addr-select-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/addr-select-dt


--
Arifumi Matsumoto
  Secure Communication Project
  NTT Information Sharing Platform Laboratories
  E-mail: [e-mail]