Subject: Re: [addr-select-dt] I-D Action:draft-chown-addr-select-considerations-00.txt

From: Tim Chown <[email-masked]>
Date: Tue, 28 Oct 2008 10:40:05 +0000

Hi,

The draft has been submitted, see below.    Please do keep the discussion
running, and comment on what you agree/disagree with or want to see added
or removed.

It appears that the majority of cases for policy change are 'one off'
administrative decisions (like preferring IPv4 over IPv6), though these
could be applied in a rolling manner across a site in an incremental
change (as pointed out in Dublin).

More frequent changes may occur where external routing requirements drive
the change, e.g. to favour a certain link.   

The other isue that has come up that is captured is ensuring hosts can be
notified of and receive policy updates in a timely fashion.

--
Tim

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Considerations for IPv6 Address Selection Policy Changes
	Author(s)       : T. Chown
	Filename        : draft-chown-addr-select-considerations-00.txt
	Pages           : 10
	Date            : 2008-10-27

Through operational experience of IPv6 Default Address Selection
(RFC3484) [1] implementations, it appears that a requirement has
arisen for hosts and networks to be able to have their policies for
address selection updated.  This text discusses considerations for
such policy changes, e.g. examples of cases where a change of policy
is required, and the likely frequency of such policy changes.  This
text also includes some discussion on the need to also update
RFC3484, where default policies are currently defined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chown-addr-select-considerations-00.txt

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

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 30 Oct 2008 18:41:45 +0900

Hi.

Regarding "How Dynamic?", the biggest concern is whether we work on  
both external triggers and internal triggers.

One of the external trigger is a routing change outside of a site.
We can say that this site is multi-homed and have multiple exit routes.
When the site is BGP multi-homed and advertises one prefix to both up- 
streams, then the site doesn't need policy table manipulation.

When the site is non-BGP multi-homed and have two prefixes given from  
both up-streams, each host have multiple addresses and may need policy  
table manipulation. In IPv4, this case of multi-home is sometimes  
realized by using NAT-Box at the site exit. However, in such a case in  
IPv4, do we deploy a dynamic routing mechanism that reflects routing  
chages outside of the site ? IMO, even the most intelligent NAT-box  
has a function of static routing and a function of detecting up-stream  
link failure.

This degree of "how dynamic" is all what we MUST provide, isn't it ?

                         ==================
                         |    Internet    |
                         ==================
                              |       |
           2001:db8:1000::/36 |       | 2001:db8:8000::/36
                         +----+-+   +-+----+
                         | ISP1 |   | ISP2 |
                         +----+-+   +-+----+
                              |       |
          2001:db8:1000:::/48 |       | 2001:db8:8000::/48
                             ++-------++
                             | Router  |  <- In IPv4, NAT is sometimes  
used here.
                             +----+----+
                                  |  2001:db8:1000:1::/64
                                  |  2001:db8:8000:1::/64
                        ------+---+----------
                              |
                            +-+----+ 2001:db8:1000:1::100
                            | Host | 2001:db8:8000:1::100
                            +------+

Other comments below.

* If the aspects in section 2 corresponds to the following sections  
4,5,6,7, and their titles, then I guess the structure will be simpler  
and easier to understand.

* 4.1.
   another example of external factor is emerging of a new address  
block defined.

* 4.2
   I think these bullets don't cover all the cases in RFC 5220.
   e.g. 2.1.3., where a site connects to multiple disjoint network.

* 5
   I fail to see what this section tries to describe.
   If the address changes involves network interface's down and up,  
this falls into start-up. If not, this falls into renumbering.

* 6
   If you say *gradual* introduction of new policy, the update  
mechanism does not necessarily be more frequent. If you say *sudden*  
introduction, then I can get it clearer.

Kindest regards,