Subject: Re: [addr-select-dt] Too quiet --- restarting discussion

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 10 Feb 2009 19:08:08 +0900

Tony,

let me reply to an old e-mail,

On 2009/01/28, at 6:20, Tony Hain wrote:

> Tomohiro -INSTALLER- "Fujisaki wrote:
> .........
>> | So, we have the following choices:
>> | - We give up merging policies in any case, and just chooses
>> |  one policy set. i.e. A host just uses policies from server-A, or
>> server-B,
>> |  or manually configured policies.
>> | - Merge policies. conflicting policies are merged by some means of
>> |  prioritization.
>> | - As Dthaler suggested before, divide policy table into dst addr
>> selection
>> |  table and src addr selection table, and policy distribution just
>> updates
>> |  src addr selection table, which makes merging process far easier.
>>
>> I like second option, merging by some priority value, such as
>> interface priority in Windows OS. I think nodes should be configured
>> as automatically as possible (from this point of view, option one  
>> with
>> no user interaction may be acceptable i.e.  using default policy  
>> table
>> if nodes find multiple policies). And I think the third option have
>> a big impact to existing implementation, so, even if we choose option
>> 3,
>> we should have some method to update the policy table.
>
> Splitting the tables only compounds the merge problems, because the
> likelihood of src/dst/router-rpf conflicts would be very high.
>
> The more I think about it, the more I find that the idea of a merged  
> table
> is a bad idea. There should be some basic rule prioritization like
> default/network-announced/manual-config/enterprise-config, but  
> sorting out
> conflicts within the network-announced set creates more problems  
> than it
> resolves. If router-A sends 75 1000 2001:db8:1::/48 and router-B  
> sends 70
> 2222 2001:db8:2::/48, no matter what value ends up as ::/0, when the  
> node
> sends to something outside those prefixes it would need to choose a  
> src
> address that aligns with the router it will be sending through. A  
> merged
> table would always choose router-A's announcement as the src prefix,  
> even if
> it sent via router-B. This would cause the operators of A & B to go  
> into an
> arms-race to set the highest precedence value they could, so they  
> all end up
> at precedence-of-loopback -1. Rather than go there, we should offer a
> default label that they all use to cause traffic between their  
> customers to
> stay on-network in both directions.  Sorting out the
> routing/rpf/src-selection problem is not resolved by a simple  
> announcement
> of policy table precedence.

> Rather than go there, we should offer a
> default label that they all use to cause traffic between their  
> customers to
> stay on-network in both directions.

I fail to see why default label approach you proposed in previous e-mail
solves the above mentioned problem of mis-alignment of router and src- 
prefix.

I'm glad if you can elaborate on it.

Regards.

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