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

Tim Chown <tjc@ecs.soton.ac.uk> Sun, 11 July 2010 15:32 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: addr-select-dt@core3.amsl.com
Delivered-To: addr-select-dt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ECEF3A6876 for <addr-select-dt@core3.amsl.com>; Sun, 11 Jul 2010 08:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD8O0mCRSnJ3 for <addr-select-dt@core3.amsl.com>; Sun, 11 Jul 2010 08:32:08 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by core3.amsl.com (Postfix) with ESMTP id E8B303A67B1 for <addr-select-dt@ietf.org>; Sun, 11 Jul 2010 08:32:06 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFWAih029617 for <addr-select-dt@ietf.org>; Sun, 11 Jul 2010 16:32:10 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk o6BFWAih029617
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1278862331; bh=mivATiCx//L5QckKtwS+QDiT+o0=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=om9Dv4R+AevSjGSx5aUs4HAgvWfgS+gSoQmwHMgSfdwH5J/7K1a+s4aOmkL+Gpkjx 32V3scji4Ir70X7Id5suDV/FnXrQITv6H50N/pWuJHZE3OaWTBHx2zZIAtTPwQC99R lSxNyVZDZO6TyeIeBVrmn9BI6QF1goNH6kuYcGrw=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id m6AGWA0540022385F2 ret-id none; Sun, 11 Jul 2010 16:32:11 +0100
Received: from [192.168.1.14] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id o6BFUlYA015312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <addr-select-dt@ietf.org>; Sun, 11 Jul 2010 16:30:47 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <B25C4B64-A692-4031-A9E5-0609284BF067@nttv6.net>
Date: Sun, 11 Jul 2010 16:30:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|5ff29d0c41dfa2e4c8a73b4f8ffe6d54m6AGWA03tjc|ecs.soton.ac.uk|B74B73DD-2C4B-425C-87F2-D39EFDD836AA@ecs.soton.ac.uk>
References: <762A30D4-C682-4C87-864B-5D0A4586EBED@nttv6.net> <553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <EMEW3|1a621eda15846417a0a7af75ba7ecc9bm64EB003tjc|ecs.soton.ac.uk|553B27A8-F215-4921-A612-6EDEB26B95FE@ecs.soton.ac.uk> <6A6F9AFA-6439-4DD6-AB32-262C54B416EF@nttv6.net> <0ac701cb1d22$11c1acb0$35450610$@net> <53C7DB02-5151-4F89-ADED-5105BA39A61F@nttv6.net> <B25C4B64-A692-4031-A9E5-0609284BF067@nttv6.net> <B74B73DD-2C4B-425C-87F2-D39EFDD836AA@ecs.soton.ac.uk>
To: addr-select-dt@ietf.org
X-Mailer: Apple Mail (2.1081)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=m6AGWA054002238500; tid=m6AGWA0540022385F2; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: o6BFWAih029617
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Subject: Re: [addr-select-dt] 2nd teleconference
X-BeenThere: addr-select-dt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IPv6 Address Selection Design Team <addr-select-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/addr-select-dt>
List-Post: <mailto:addr-select-dt@ietf.org>
List-Help: <mailto:addr-select-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/addr-select-dt>, <mailto:addr-select-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Jul 2010 15:32:09 -0000

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'.

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.

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

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

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.

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: addr-select-dt-bounces@ietf.org [mailto:addr-select-dt-
>>>> bounces@ietf.org] On Behalf Of Arifumi Matsumoto
>>>> Sent: Tuesday, July 06, 2010 2:18 AM
>>>> To: addr-select-dt@ietf.org
>>>> 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: arifumi@nttv6.net
>>>>>> 
>>>>>> _______________________________________________
>>>>>> addr-select-dt mailing list
>>>>>> addr-select-dt@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>>> 
>>>>> _______________________________________________
>>>>> addr-select-dt mailing list
>>>>> addr-select-dt@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>>> 
>>>> 
>>>> --
>>>> Arifumi Matsumoto
>>>> Secure Communication Project
>>>> NTT Information Sharing Platform Laboratories
>>>> E-mail: arifumi@nttv6.net
>>>> 
>>>> _______________________________________________
>>>> addr-select-dt mailing list
>>>> addr-select-dt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/addr-select-dt
>>> 
>> 
>> 
>> --
>> Arifumi Matsumoto
>> Secure Communication Project
>> NTT Information Sharing Platform Laboratories
>> E-mail: arifumi@nttv6.net
>> 
>> _______________________________________________
>> addr-select-dt mailing list
>> addr-select-dt@ietf.org
>> https://www.ietf.org/mailman/listinfo/addr-select-dt
> 
> _______________________________________________
> addr-select-dt mailing list
> addr-select-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/addr-select-dt