Re: [addr-select-dt] 2nd teleconference

[Arifumi Matsumoto <[e-mail]>]

Tim,
thank you for your memo.
Several thoughts below.

We are having good discussion here in this ML.
As far as time allows, I want our draft reflect this discussion.

And after the cut-off, I want to continue making progress and present better output to the 6man people in Maastricht.

On 2010/07/12, at 0:30, Tim Chown wrote:

> Tony, Arifumi and I attended the teleconference.
> 
> We discussed various topics, with the policy merging/conflict handling issue taking most of our time.   We agreed the principles of Arifumi's text below were good, though Tony thought it should be scoped to 'within the local network'.

So, the Tony's suggestion was putting *local* like below.

>> This mechanism SHOULD be used only when the administrator of a site can make
>> sure that the address selection information receiver will not receive the same kind
>> of information from any other *local* entity, or the receiver can accept and process the received
>> multiple policy sets correctly, e.g. by using pre-configured information.

I came to think that this applicability seems reasonable.

- First of all, the mechanism does not provide a standard way of merging, so the network SHOULD NOT distribute policy sets from multiple entities. This restriction seems to be acceptable for the network administrator.

- As in enterprise network, the network administrator can restrict users's network environment so that they do not do multi-home. But, as in access network and wifi spots, he cannot restrict what they do. Does this inhibit him from using this mechanism ? I do not think so. This matter is just the same as other DHCP options like DNS server address option. It is also the host-wide information, but it has not became an obvious problem, mainly due to implementation measures, such as interface prioritization as studied in mif wg.

> Because of the complexity of this topic, and the need to publish the address selection considerations draft, we agreed to document the conflict/merging problem concisely in the draft and move work on solution(s) to a new text.   This would allow policy distribution in networks without policy conflict to be progressed.   Tim will refresh the dt draft before the IETF78 cutoff.
> http://tools.ietf.org/id/draft-ietf-6man-addr-select-considerations-00.txt
> 
> The conflict/merge problem is hard.   Conflict implies choice, which a general user may not be able to make, and merging may produce a suboptimal or even unusable result.   The most common 'problem' scenario is probably the VPN one, where a user in a coffee shop or enterprise network wishes to use a VPN.   It was noted that VPN clients typically have a user choice in 'send all data via VPN' or 'send only home network data via VPN' tickbox.

We should not say "we do not do this, because this problem is difficult."
We should day "we do not do this, because there is no perfect or practical solution for doing this."

I think we can say the latter, because the destination address selection based on precedence value does essentially conflict with other precedence value coming from other policy source.

We understand there are some cases where they need policy merge. So, we should do further work on producing most practical way of policy merging. But, I suppose the output should be experimental or informational RFC, in that we really have to see the output is acceptable and operational in reality.


One more point about this separation.
If we do this separation, what do we have to have now ?

I think it is basically ultimately a receiver's choice whether it does policy merge or not.
Here, I'm wondering if there should be a way to guide a receiver whether it should merge or not. In this case, there should be a bit to show this preference of policy sender.
But, we may do not have to discuss this, we just need a bit of reserved field in the option.

> It was felt that the dt could work with the authors of the multihome-without-nat66 draft to bolster contributions to the problem space.   While the Troan draft considers many of the issues the DT is concerned with it does not include policy conflict/merger. 
> http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-00

As confirmed in their ML, they are happy with non-merge-capable solution.

> The question arose again if whether RFC3484 should be per node (as now) or per interface.

As far as it is used for destination address selection, it has to be per host.

> 
> Arifumi agreed to refresh the 3484-bis draft before the cutoff, and Tony offered to send some comments over the weekend.    Ideally we would like to get 3484-bis to a publication-ready state as soon as possible.   Many vendors/implementors have already implemented many of the changes in the current 3484-bis draft.
> 

I'll update it from now :)

If everyone agrees, I want that draft to be this DT's output.


Regards,


> Tim
> 
> On 8 Jul 2010, at 14:45, Arifumi Matsumoto wrote:
> 
>> Hi,
>> 
>> some of my thoughts below.
>> 
>> * general rule for conflict and merge
>> 
>> There is a design choice of
>> 1. the mechanism should allow the merge of two or more polcy sets even if there is a conflict between them.
>> 2. the mechanism should allow the merge if there is no conflict.
>> 3. the mechanism should not allow the merge of multiple policy sets.
>> 
>> As studied in my conflict draft, it is not easy to merge two policy sets even if there is no conflict.
>> So, IMO, we should separate every case of policy merge from the basic spec.
>> It means also the merge of a received policy set and the default policy and the merge
>> of any policy sets with manually configured policy set.
>> 
>> That is, one policy set is treated as one atomic information just like a DNS server option.
>> 
>> In that case, we should define/endorse the relation between auto-configured policy, 
>> and manually configured policy and default policy.
>> I think it should be configurable by user which to choose between auto-configured policy
>> and manually configured policy. These policy sets should override the default policy.
>> And, by default, a host should use auto-configured policy.
>> These relation should be implementation dependent, though.
>> 
>> * applicability
>> 
>> If we can agree on above, the applicability statement should be something like:
>> 
>> This mechanism SHOULD be used only when the administrator of a site can make
>> sure that the address selection information receiver will not receive the same kind
>> of information from any other entity, or the receiver can accept and process the received
>> multiple policy sets correctly, e.g. by using pre-configured information.
>> 
>> Even if we define the applicability as above, the mechanism itself helps a lot of
>> important problems, stated in RFC5220 and draft-troan-multihoming-without-nat66, etc.
>> 
>> 
>> * what happens if multiple policy sets are received
>> 
>> Even if we decided as above, it would be helpful if we can define the behavior when
>> a node received multiple policy sets, and it minimizes the bad effect from it.
>> 
>> I think the best way for it is to use a policy set received on the most preferred interface.
>> The most preferred means manual configuration, and OS dependent value.
>> As studied in mif wg, a lot of implementation has metric value for each interface, and
>> makes use of it to tie-break.
>> 
>> I think we can follow the manner of them here to minimize the damage.
>> 
>> 
>> Regards,
>> 
>> On 2010/07/07, at 17:13, Arifumi Matsumoto wrote:
>> 
>>> All,
>>> 
>>> let me fix the telecon for 7/8 at the same time as before.
>>>>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>>> 
>>> 
>>> Tony, would you please setup the webex ?
>>> 
>>> The cut-off for the revision draft is just ahead of us.
>>> 
>>> We should discuss about the actual text or something close to it
>>> to make it for the cut-off.
>>> 
>>> I'll try to put together some candidate texts, so that we can 
>>> just choose one from the candidates.
>>> 
>>> A brief agenda off the top of my head is,
>>> 
>>> - Design Team merger with draft-troan-multihoming-without-nat66.
>>> 
>>> - Applicability statement in our draft.
>>> 
>>> - Updates for conflict draft.
>>> 
>>> - Strategy for IETF78 presentation.
>>> 
>>> - [please add here]
>>> 
>>> Best wishes,
>>> 
>>> On 2010/07/07, at 0:44, Tony Hain wrote:
>>> 
>>>> I can only do 7 or 8, and I can set up a webex.
>>>> 
>>>> Tony
>>>> 
>>>> 
>>>>> -----Original Message-----
>>>>> From: [e-mail] [mailto:addr-select-dt-
>>>>> [e-mail]] On Behalf Of Arifumi Matsumoto
>>>>> Sent: Tuesday, July 06, 2010 2:18 AM
>>>>> To: [e-mail]
>>>>> Subject: Re: [addr-select-dt] 2nd teleconference
>>>>> 
>>>>> All,
>>>>> 
>>>>> would you all please let us know 7/8 and 9 work or not.
>>>>> Please e-mail by 7/7.
>>>>> 
>>>>> Tony, can you setup WebEx again ?
>>>>> 
>>>>> On 2010/07/05, at 22:10, Tim Chown wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Sorry for the late reply.   Now, only 7/7 would work for me.
>>>>>> 
>>>>>> Thursday or Friday this week are OK at the same time.
>>>>>> 
>>>>>> Tim
>>>>>> 
>>>>>> On 1 Jul 2010, at 07:42, Arifumi Matsumoto wrote:
>>>>>> 
>>>>>>> All,
>>>>>>> 
>>>>>>> I'd like to schedule the 2nd telecon.
>>>>>>> For the 2nd telecon, we should look into concrete items
>>>>>>> to be included in our consideration document, and maybe
>>>>>>> in my document about policy conflict.
>>>>>>> 
>>>>>>> And, I have some things that I want to share with you all.
>>>>>>> 
>>>>>>> As everybody is in different place, so why not have a
>>>>>>> telecon at the same time as the previous one.
>>>>>>> 
>>>>>>> That is,
>>>>>>> 3:00pm in BST, 7:00am in PDT, 11:00am in EDT, 11:00pm in JST.
>>>>>>> 
>>>>>>> 7/2,5,6,7 work for me.
>>>>>>> 
>>>>>>> Regards,


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