Subject: [addr-select-dt] discussion at Montreal

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 8 Oct 2008 17:13:51 +0900

Hi all,

last week at Montreal, where v4v6interim meeting was held, I had some  
time to talk with Marc Blanchet and Suresh Krishnan, and confirmed the  
following starting points.
# Some parts of these crossover hiromi-san's e-mail on 11 Sep.

-----
The goal of this design team
-> to work out an mechanism that solves address selection problems by  
dynamically updating the policy table.

What we would like to solve ?
-> We would like to solve all or some of the problematic cases  
described in RFC 5220 (Problem Statements).

How do we solve ?
-> option a) revising RFC 3484
-> option b) some dynamic way to update the policy table (e.g. DHCPv6  
option)
-> option c) both a) and b)
------

If you have any comments or questions regarding these points, let us  
know.

BTW.
I wrote a few things on our wiki page.
I'll update this page according to the discussion at ML.
http://trac.tools.ietf.org/area/int/trac/wiki/v6AddrSelect?version=3

Kindest regards,
Arifumi Matsumoto

_______________________________________________
addr-select-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/addr-select-dt

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Fri, 10 Oct 2008 11:37:14 +0900 (JST)

Arifumi-san,

One question,

 | -----
 | The goal of this design team
 | -> to work out an mechanism that solves address selection problems by dynamically updating the policy table.
 | 
 | What we would like to solve ?
 | -> We would like to solve all or some of the problematic cases described in RFC 5220 (Problem Statements).
 | 
 | How do we solve ?
 | -> option a) revising RFC 3484

Does option a) mean we should consider solutions other than policy
distribution?

--
Tomohiro Fujisaki

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 14 Oct 2008 12:20:23 +0900

Hi,

On 2008/10/10, at 11:37, (Tomohiro -INSTALLER- Fujisaki/藤 
崎 智宏) wrote:

> | -> to work out an mechanism that solves address selection problems  
> by dynamically updating the policy table.
> |
> | -> We would like to solve all or some of the problematic cases  

My understanding is that we intend to work on a mechanism for updating
host's policy table, so we assume the existence of RFC 3484.

However, at the same time, we don't exclude minor-update of RFC 3484,
such as adding one line to the default policy table.

So, solutions other than policy distribution and minor-update of RFC  
3484
are outside of our scope.

Regards.

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Oct 2008 10:39:18 +0100

Hi,

I think we need to get a little focus based on Brian's steer for us,
so we can plan to produce an initial draft text.

Note the -00 cutoff is 27th October, so we have two weeks to produce
initial text, if we want to make that cutoff.

My suggestion would be that the text should initially include thoughts
along the lines of Ruri's input, i.e. triggers for policy changes.   From
this we should get a better understanding how often and why the policies 
change.   This should help us in then appreciating which solution fits 
best.   I don't think we should talk about solution spaces in -00.

This my initial question is what people on the team think of Ruri's 
input on triggers?   

I agree we should look a 5220 as one source of input.   

On the subject of changes to default policy (3484), I suspect that while
we could make defaults 'better' in the general case, in this team we
- initially at least - just view one 'trigger' as being an initial 
deployment of policy for the site that may overwrite certain defaults.

Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 16 Oct 2008 20:30:05 +0900

Hi,

I agree that we should start with trigger discussion.

Regarding RFC 5220, the following cases are listed.
Let me try an analysis of these from the aspect of updating trigger.

            2.1.1. Multiple Routers on a Single  
Interface ..............4
            2.1.2. Ingress Filtering  
Problem ...........................5
            2.1.3. Half-Closed Network  
Problem .........................6
            2.1.4. Combined Use of Global and  
ULA ......................7
            2.1.5. Site  
Renumbering ....................................8
            2.1.6. Multicast Source Address  
Selection ..................9
            2.1.7. Temporary Address  
Selection .........................9
            2.2.1. IPv4 or IPv6 Prioritization ........................ 
10
            2.2.2. ULA and IPv4 Dual-Stack Environment ................ 
11
            2.2.3. ULA or Global Prioritization ....................... 
12

Only 2.1.1 and 2.1.2 may need dynamic policy table update triggered
by routing changes, as long as the site uses a dynamic routing protocol
intra-site and the routing protocol is configured to reflect changes
of extra-site routing topology.

In such a case, the policy table of hosts may needs to be updated
according to the routing policy.
It should be noted that we have other mechanims for dynamical routing
topology change, for example deprecating one of the advertised prefixes.
This mechanism may help when one of the upstream links has a trouble.

Regarding any other cases in RFC 5220, IMO an update of the policy table
is triggered by an intra-site topology/policy change. So, only the
site administrator triggers policy table updates.

Can we agree on this analysis ?

---

From: (Tomohiro -INSTALLER-Fujisaki/藤崎 智宏) <[email-masked]>
Date: Tue, 21 Oct 2008 12:35:12 +0900 (JST)

Hi Arifumi-san,

Do you think we should discuss timing of the policy table distribution
(e.g. host initlalization phase and host running phase)? We can use
a same protocol all in all phase or not.

 | Regarding RFC 5220, the following cases are listed.
 | Let me try an analysis of these from the aspect of updating trigger.
 | 
 |             2.1.1. Multiple Routers on a Single Interface ..............4
 |             2.1.2. Ingress Filtering Problem ...........................5
 |             2.1.3. Half-Closed Network Problem .........................6
 |             2.1.4. Combined Use of Global and ULA ......................7
 |             2.1.5. Site Renumbering ....................................8
 |             2.1.6. Multicast Source Address Selection ..................9
 |             2.1.7. Temporary Address Selection .........................9
 |             2.2.1. IPv4 or IPv6 Prioritization ........................10
 |             2.2.2. ULA and IPv4 Dual-Stack Environment ................11
 |             2.2.3. ULA or Global Prioritization .......................12
 | 
 | Only 2.1.1 and 2.1.2 may need dynamic policy table update triggered
 | by routing changes, as long as the site uses a dynamic routing protocol
 | intra-site and the routing protocol is configured to reflect changes
 | of extra-site routing topology.
 | 
 | In such a case, the policy table of hosts may needs to be updated
 | according to the routing policy.
 | It should be noted that we have other mechanims for dynamical routing
 | topology change, for example deprecating one of the advertised prefixes.
 | This mechanism may help when one of the upstream links has a trouble.

I think in a case hosts need to chage their address (e.g. deprecating
the address), the hosts should re-obtaion the selection policy (in the
case of deprecation, it may be unnecessary to change its policy) and
the trigger can be the address configuration mechanism (RA or DHCPv6).

It may be more difficult in a case that hosts do not need to change
their address, how to inform hosts to re-obtaion the policy, or 
deliver the pollicy to hosts. 

When we use DHCPv6 for policy distribution, it is difficult to inform
hosts to re-obtain the policy (can we use reconfigura message?).

 | Regarding any other cases in RFC 5220, IMO an update of the policy table
 | is triggered by an intra-site topology/policy change. So, only the
 | site administrator triggers policy table updates.
 |
 | Can we agree on this analysis ?

Basically, yes.

 | On 2008/10/14, at 18:39, Tim Chown wrote:
 | 
 | > Hi,
 | >
 | > I think we need to get a little focus based on Brian's steer for us,
 | > so we can plan to produce an initial draft text.
 | >
 | > Note the -00 cutoff is 27th October, so we have two weeks to produce
 | > initial text, if we want to make that cutoff.
 | >
 | > My suggestion would be that the text should initially include thoughts
 | > along the lines of Ruri's input, i.e. triggers for policy changes.   From
 | > this we should get a better understanding how often and why the policies
 | > change.   This should help us in then appreciating which solution fits
 | > best.   I don't think we should talk about solution spaces in -00.
 | >
 | > This my initial question is what people on the team think of Ruri's
 | > input on triggers?
 | >
 | > I agree we should look a 5220 as one source of input.
 | >
 | > On the subject of changes to default policy (3484), I suspect that while
 | > we could make defaults 'better' in the general case, in this team we
 | > - initially at least - just view one 'trigger' as being an initial
 | > deployment of policy for the site that may overwrite certain defaults.
 | >
 | > Tim
 | > _______________________________________________
 | > addr-select-dt mailing list
 | > [email-masked]
 | > https://www.ietf.org/mailman/listinfo/addr-select-dt
 | 
 | _______________________________________________
 | addr-select-dt mailing list
 | [email-masked]
 | https://www.ietf.org/mailman/listinfo/addr-select-dt
 | 
_______________________________________________
addr-select-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/addr-select-dt

---

From: Tim Chown <[email-masked]>
Date: Tue, 21 Oct 2008 13:46:40 +0100

> a same protocol all in all phase or not.

It would certainly simplify the discussion if we could assume that the
same protocol/method can be used for startup and for hosts already running
with a policy.   Is there any reason why this should not be so?

>  | of extra-site routing topology.

I think it's possible that some of the above issues may be addressed by
an update to RFC3484.   Whether they are or not, we should consider a)
how commonly the above issues arise and b) what the impact of each might be.

> the trigger can be the address configuration mechanism (RA or DHCPv6).

When we ran renumbering experiments here, we only had RA available, and
thus a 'simple' Baker-style renumbering event wouldn't lead to a new
policy update being triggered.   And certainly not a DHCP based one.
 
> deliver the pollicy to hosts. 

This may be partly related to the discussions about hosts transitioning
between RA and DHCP environments.    There's some cue required that
indicates some 'change' in the network that may require action by the
hosts.
 
> hosts to re-obtain the policy (can we use reconfigura message?).

Indeed.    We should capture this as a requirement, or at least a problem.

>  | Can we agree on this analysis ?

If there are additional triggers, now would be a good time to add them :)
 
We need someone to write an initial -00 draft that captures comments 
raised so far.  I am happy to do this, unless someone else has a burning
desire to do so... so if there are more comments please raise them in
the next day or two so we can be sure to capture them in the draft that
we should submit by Monday.

Tim

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 23 Oct 2008 15:09:49 +0900

Hi,

> with a policy.   Is there any reason why this should not be so?

Of course, we should start with/assume one protocol/method to fulfill
all the problems. And if we cannot, we should handle multiple protocols
to cover the problems.

Tim, do I get what you mean ?

>> |             2.1.5. Site  
>> |             2.2.1. IPv4 or IPv6  
>> Prioritization ........................10
> an update to RFC3484.

agree. e.g. section 2.1.4.

> Whether they are or not, we should consider a)

and, may be after that, we should consider

c) what kind of technical/concrete event can be used for triggering  
the a policy table update mechanism.
    e.g. Address re-obtainment, address lifetime expiration, or  
perhaps policy lifetime expiration.

>> the trigger can be the address configuration mechanism (RA or  

I was talking about non-policy-table-based solution for 2.1.1 and 2.1.2.

Generally speaking, I agree that an address change should correspond to
policy table update.

> Indeed.    We should capture this as a requirement, or at least a  

One possible solution is dhcp lifetime option (RFC 4242).
Tim must know better than I ;)

> we should submit by Monday.

I was just trying to start drafting.
But, I'm sure you are better person for that. :)
I really appreciate your offering.

Kindest regards,

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 Oct 2008 12:07:16 +0100

> I really appreciate your offering.

OK, I am beginning to draft a text today that I'll circulate soon. 

This will give some time for comments before submitting on Monday.

Tim