Subject: [addr-select-dt] draft regarding policy merge

From: arifumi <[email-masked]>
Date: Fri, 03 Jul 2009 00:49:22 +0900

Hi DT members,

here attached my initial draft for policy merging.
I tried to solve this issue by starting from
somewhat meta-level policy merging discussion.

Right now, this is my individual draft.
If we can agree on the merging proposal documented
in this draft, I want to re-submit it as an DT draft.

This time, I want to have comments from 6man ML also
at the same time to make Stockholm a successful
session for us.

Before that, I'd like to have comments here for
a short period.

Kindest regards,

---

From: Tim Chown <[email-masked]>
Date: Fri, 10 Jul 2009 15:53:39 +0100

Hi,

I have compiled the feedback since IETF74 into a revised draft
draft-chown-addr-select-considerations-03, as attached, or 
available at:
http://users.ecs.soton.ac.uk/tjc/ietf/draft-chown-addr-select-considerations-03.txt

I plan to submit this draft on Monday evening, and would welcome 
comments before then to improve it further.

These address comments on list, from Thomas and Dave, and include
reference to new drafts.   I believe the 6man chairs indicated
this could be a WG item, though I don't believe a list 'vote' was
called.   But this could be agreed in Stockholm.

General change notes:

- added reference to draft-denis-v6ops-nat-addrsel-00

- added reference to draft-arifumi-6man-addr-select-conflict-00

- noted that differing administrative domains are in scope (Thomas)

- noted that multiple interfaces are in scope (Thomas)

- noted node-wide problem is destination address selection (Dave)

- noted the two common multiple interface cases (wired/air, normal/VPN)

- noted any 3484 update has two elements: policy table and algorithms

- noted that many OSes already have implemented modified 3484 policy
  so we could use an improved 3484 'default' asap

- noted updates to policy not rapid unless node is in a site doing
  rapid traffic engineering changes or where nodes are heavily mobile
  between parts of the network with different policy (and thus actually
  frequency of 3484 update not really that different to general
  configuration data update, usually via dhcp)

- noted managed (dhcpv6) networks tend to have managed policy
  (thus dhcpv6 option may be appropriate there)

- noted unmanaged networks probably don't have a policy table available,
  so should explore routing hints etc there?

Are we getting close to some firmish conclusions?

I will be in Stockholm.

Tim