Re: [addr-select-dt] slide to 6man presentation

Arifumi Matsumoto <arifumi@nttv6.net> Mon, 26 July 2010 11:55 UTC

Return-Path: <arifumi@nttv6.net>
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 747DC3A680A for <addr-select-dt@core3.amsl.com>; Mon, 26 Jul 2010 04:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level:
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 3qb+l8uJYlY7 for <addr-select-dt@core3.amsl.com>; Mon, 26 Jul 2010 04:54:59 -0700 (PDT)
Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 7D25E3A6802 for <addr-select-dt@ietf.org>; Mon, 26 Jul 2010 04:54:58 -0700 (PDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by mail.nttv6.net (8.14.4/8.14.3) with ESMTP id o6QBsf5B074357; Mon, 26 Jul 2010 20:54:42 +0900 (JST) (envelope-from arifumi@nttv6.net)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary=Apple-Mail-17--957113057
From: Arifumi Matsumoto <arifumi@nttv6.net>
In-Reply-To: <EMEW3|485ffd87b61ef2b40ca7f992939f6ae1m6PADp03tjc|ecs.soton.ac.uk|9BC19D14-B2D7-49DF-9E8A-192C2839844D@ecs.soton.ac.uk>
Date: Mon, 26 Jul 2010 20:54:41 +0900
Message-Id: <21EF27BE-29D5-4F7C-8E72-0B67A2AFEE71@nttv6.net>
References: <482E7BB1-B20F-4F96-B632-5F8B8248A4AA@nttv6.net> <9BC19D14-B2D7-49DF-9E8A-192C2839844D@ecs.soton.ac.uk> <EMEW3|485ffd87b61ef2b40ca7f992939f6ae1m6PADp03tjc|ecs.soton.ac.uk|9BC19D14-B2D7-49DF-9E8A-192C2839844D@ecs.soton.ac.uk>
To: Tim Chown <tjc@ecs.soton.ac.uk>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:::1]); Mon, 26 Jul 2010 20:54:45 +0900 (JST)
Cc: addr-select-dt@ietf.org
Subject: Re: [addr-select-dt] slide to 6man presentation
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: Mon, 26 Jul 2010 11:55:00 -0000

On 2010/07/26, at 18:13, Tim Chown wrote:

> Hi,
> 
> Some comments....
> 
> - the DT draft is missed from the slides: draft-ietf-6man-addr-select-considerations-02
> 
> May wish to have a slide summarising the most recent focuses in that draft, for example including some/all of:

Sorry for that.
I put together these slides from top of my head in the plane. 

However, we should not mention all the changes. To make it simple and easy to focus on the important points.

> 
> - frequent policy changes are linked to having either rapid traffic engineering changes/external routing changes or lots of mobile nodes within the site moving between points of attachment with different policies
> 
> - it seems sensible to acquire RFC3484 policy when acquiring other configuration information
> 
> - in a managed enterprise there is likely to be a managed policy, and DHCP available
> 
> - in dynamic/unmanaged networks using routing hints for address selection *may* be more appropriate

I cannot get what exactly mean by this sentence.
Do you assume a environment where a mobile node with multiple interface can make use of routing information for address selection ?

> 
> - the problem of handling policy conflict is a host issue, the method to distribute the policy is a network issue - we focus here on the network issue since the host issue is broadly applicable to many configuration parameters

Important point.
I knew that, but I could not find a space for that.
Maybe we need to add some slides to elaborate.

> - we should avoid delaying progression of a 3484 policy distribution method applicable to managed enterprise networks

Not only enterprise networks, but for networks where multiple upstream networks can talk with each other.

> I think this material could fit in a new Slide 3 and then you continue the arifumi-6man-addr-select-conflict reference after that, to keep the flow.
> 
> I see a new Troan multihoming draft came out this morning, I've not checked what changes there are yet.

The main changes are about the legacy host support. Support by using NAT66 to the wrongly source-addressed packets.

Regards,


> 
> Cheers,
> Tim
> 
> On 24 Jul 2010, at 23:49, Arifumi Matsumoto wrote:
> 
>> Hi,
>> 
>> I drafted the slide for 6man.
>> This version still has some clear errors, so
>> I have to fix them.
>> 
>> I really want you all to comment on this.
>> About the story itself, wording, typos, and whatever.
>> 
>> <ietf78-6man-dt.pdf>_______________________________________________
>> 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