Subject: [addr-select-dt] discussion point, task and members

From: Ruri Hiromi <[email-masked]>
Date: Thu, 11 Sep 2008 16:37:27 +0900

# resent on changing Subject line.

Dear 3484 policy distribution design team,

Here is a outline to start to discuss with.

In this team, we will write a protocol design draft for dynamic policy  
table update.
I think here some points. How do you think about them?
	
1. definition of "default policy" and its administration
	o a basic "default policy table" is described in RFC3484 but it will  
have additional address numbers like ORCHID, ULA and so on.
  	o Because of it's possibile modification it is hard to fix entire  
table.
	o It is better to refer up-to-date table and it seems better that  
IANA(or like such authorised organization) manages the table.

2. distribution mechanism
	o Protocol
	   From the solution document, here is 4 types of mechanisms(obtain- 
all-info, routing-system-assistance, trial-and-error-approach, all-by- 
oneself), I think obtain-all-info using DHCPv6 or RA will be a  
suitable solution for a client connecting to a managed network.
	   But for other network requirement or use cases, we want to make a  
brand-new protocol?
	   In any cases, how do we consider about cooperation with other  
protocol(i.e, routing protocol)?
	   Can we use LDAP or other popular protocol?
	o Timing
	o Dynamics
	o Other requirements from address-select-req

3. draft table of contents
	(1) abstract
	(2) terminology, definitions
	(3) data format, syntacs
	(4) data type(request, response)
	(5) security consideration

4. Milestone
	o drafting at the end of Oct. 2008
	o presentation at the 6man next IETF73
	o the Goal is publishing the draft as RFC

- Design Team Members
current 3484 policy dynamic update design team
	- Marc Blanchet
	- Tim Chown
	- Marcelo Bagnulo Braun
	- Suresh Krishnan
	- Tony Hain
	- Francis Dupont
	- Evans TJ
	- John.zhao
	- Sebastien Roy
	- Janos Mohacsi
	- Tim Enos
	- Teemu Savolainen
	- Fujisaki Tomohiro
	- Arifumi Matsumoto
	- Ruri Hiromi

- Sandbox
	o ML [email-masked]
	o wiki coming soon?

- references

  proposal for updating RFC3484
http://tools.ietf.org/id/draft-arifumi-6man-rfc3484-revise-00.txt
  Problem Statement
http://tools.ietf.org/html/rfc5220
  Requirement
http://tools.ietf.org/html/rfc5221
  Solution Analysis
http://tools.ietf.org/wg/6man/draft-ietf-6man-addr-select-sol/
  shim6
  using DHC option to carry out distributing table
http://tools.ietf.org/id/draft-fujisaki-dhc-addr-select-opt-06.txt

Regards,
-------------------------------
Ruri Hiromi
Intec NetCore, Inc. / Keio university
[email-masked]

-------------------------------
Ruri Hiromi
Intec NetCore, Inc. / Keio university
[email-masked]

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 Sep 2008 14:30:20 +0200

> In this team, we will write a protocol design draft for dynamic policy 
really?
i thought that the team scope was broader than that, in particular i 
thought we were supposed to update rfc3484.
In rfc3484, the main issue that i identify is how to deal with multiple 
addresses, in particualr how to deal with initial contact failures, when 
the failure is due to a problem in the source address (e.g. due to 
ingress filtering)

dynamic update seems straight forward, i don't really see the need for a 
design team, we just need peopel to write the specs.
This other problem, otoh, seems much harder to me and could benefit from 
new ideas and the expertise of this group

Regards, marcelo

>   o Because of it's possibile modification it is hard to fix entire table.
>    From the solution document, here is 4 types of 
> mechanisms(obtain-all-info, routing-system-assistance, 
> trial-and-error-approach, all-by-oneself), I think obtain-all-info 
> using DHCPv6 or RA will be a suitable solution for a client connecting 
> to a managed network.
> o ML [email-masked] <mailto:[email-masked]>
> o wiki coming soon?
>
> - references
>
> [email-masked] <mailto:[email-masked]>
>
>
> [email-masked] <mailto:[email-masked]>
>
>
>
> ------------------------------------------------------------------------
>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 11 Sep 2008 11:37:28 -0400

All,
      Let me set the path for this design team.

First, I have asked two members of this design team to act as co-chairs 
in order to ensure that consensus is reached within the design team on 
discussion points.  Once I have gotten confirmation of their willingness 
to take on this role I will ask them chime in with their views on how 
they want to do that.

Second, the initial focus of this work should be to determine how 
dynamic the updates of an address selection policy need to be.  Once 
that is accomplished, the focus should be on determining what types of 
update approaches satisfy those needs.  The third task is to assess 
whether those update solutions require/need 3484 to be updated.  In some 
instances, I could envision solutions that simply use 3484 as guidelines 
and provide sufficient controls to address the current limitations in 
the RFC.

Regards,
Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 12 Sep 2008 00:04:02 +0200

ok, my bad, i thought that the scope of the DT was broader than that, 
RFC3484 update in general, not limited to the policy table configuration.

thanks for the clarification

regards, marcelo

---

From: Francis Dupont <[email-masked]>
Date: Thu, 25 Sep 2008 13:48:31 +0200

In your previous mail you wrote:

=> note the "default" word has to be defined here, i.e., what
is the scope of this "default". It seems it is "system wide"
but first it just moves the issue to the "system" definition
and second larger or smaller granularities make sense (for
instance "link wide" and "user wide").

Thanks

[email-masked]

PS: BTW I prefer pure text messages (no HTML copy, etc).
_______________________________________________
addr-select-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/addr-select-dt

---

From: Ruri Hiromi <[email-masked]>
Date: Mon, 29 Sep 2008 12:35:07 +0900

Hello,

To determine how dynamic the updates of an address selection policy  
need to be, here is a short talk about "Dynamic" inputed from japanese  
tema metes.

We can see 2 kinds of "dynamic" :

- once in an initial of communication
  1) just start to the communication
  2) booting the interface settings
  3) just gets address(es) from NDP
  4) when an special use prefix(es) is assigned/advertised from IANA

- administrative trigger(long duration might be allowed for updates  
the table cases)
  1) administrator set priority use of v4-v6, or global and ULA,etc
  2) a renumbering occurs
  3) routing table and forwarding table is changed(in site(with  
related prefix)/out side of the site)

If we consider of cooperation of routing, discussion issues is here;

a) RFC3484 treats both of destination and source address selection  
mechanisms and the destination selection has to cover a huge area but  
end hosts just send a packet dependently with their router/gateway.  
Because of this we focused on "source address selection" at this time.

b) frequency  : what is the most frequently timing in the  
communication system?

c) multiple routers / single router?
  --> changes from up/down with the IF, changes from route(s)  
information in outer router(s), changes of route(s) information in  
whole Internet
--> input from router(s), if one of routers going down. In that time  
it is better to simply stop DHCP/RA with related ineffectual route(s)
level of Dynamic
multicast

What do you think of this?