Subject: [addr-select-dt] tomorrow's presentation

From: Ruri Hiromi <[email-masked]>
Date: Mon, 9 Nov 2009 13:55:29 +0900

Hello team,

Arifumi and I discussed for preparation of tomorrows presentation.

give these information

1. RFC3484 leave as is
   - The design team conclude no modification to the RFC3484 itself,  
because there is no significant point to be changes the 3484 mechanism.

2. then we simply consider about dynamic update of policy table in the  
hosts
   - The design team concludes there are no other updates in the  
draft<draft-ietf-6man-addr-select-considerations-00.txt> and this is  
to be the final version of it.
   - The suitable protocol with our consideration document, there are  
3 choices, 1st is DHCPv6, 2nd is RA, the last is making brand new  
protocol which co-working with routing protocols.
   - we choose 2 of DHCP and RA
   - we already have a basic DHCP version draft
   - need a RA version draft
   - co-working with routing protocol is hard to {deploy in the hosts,  
need more consideration, etc}

3. Additional conflict document
   we could not have time to talk in the previous meeting so far.

I hope any comment or advise will be given by this night around 2200(?)
Thanks in advance,

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Nov 2009 12:18:42 +0000

> Hello team,

Hi, some comments below...
 
> because there is no significant point to be changes the 3484 mechanism.

I assume you mean that there are no additional changes required to
RFC3484 beyond those already identified, based on the DT work and draft?

I assume at some point a revision of 3484 will take place, such that a
new 'default' 3484 will be defined?   Many OS developers have already
implemented some changes based on identified issues, so we have different
OSes with different 'defaults' now.
 
> to be the final version of it.

I agree.

>   - we already have a basic DHCP version draft

Yes, so I think the next step is to review that draft against any
observations made in the considerations draft.

>   - need a RA version draft

Is this just an indicator that policy has changed, or that policy on the
link is different to 3484 'default', or are you suggesting conveying the
policy in the RA?

> need more consideration, etc}

Well, we did some work on this here by adding a new ICMP message for 
hosts to query routers for policy/hints, and the prototype is encouraging.
This would really be most applicable in dynamic, unmanaged networks
where by definition there is no DHCP service.

What this work did reveal is the shortcomings in the API (the selected
source address is lost) and also that 3484 is a bit vague in that you
apparently can't store a source/destination address combo in the policy
table (so you can't 'cache' the routing hint there as such).

>   we could not have time to talk in the previous meeting so far.

This is still a very useful draft to take forward though :)
 
> I hope any comment or advise will be given by this night around 2200(?)

Cheers,
-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 9 Nov 2009 21:57:25 +0900

Tim,

> OSes with different 'defaults' now.

Correct. "leave as is" means just what you mentioned.

> link is different to 3484 'default', or are you suggesting conveying  

Regarding this point,
after conducting the policy collision work, we've found that the routing
information and address selection policy have to be correlated.

I propose a method that makes use of routing table on a host, and  
chooses
the corresponding policy with the selected route in the routing table.

This leads to,
if RA is a mechanism to deliver routing info, then policy has to be
carried by RA.
if DHCP is a mechanism to deliver routing info, then policy has to be
carried by DHCP. (this option is forthcoming, as you know)
if routing protocol is a mechanism to deliver routing info, then policy
has to be carried by routing protocol.

Then we considered pros/cons of each of the above 3 choices,
and I believe RA option should be the most feasible mechanism.

> table (so you can't 'cache' the routing hint there as such).

This consideration is also very valuable for us, and 6man ppl.
Have you summarized these things in dt draft, or somewhere else ?

> This is still a very useful draft to take forward though :)

So, to show the above mentioned considerations regarding RA option,
I'm trying to talk about this conflict solution mechanism, halfway
down to the conclusion.

>> I hope any comment or advise will be given by this night around 2200 

What do you think ?

---

From: Ruri Hiromi <[email-masked]>
Date: Mon, 9 Nov 2009 22:09:59 +0900

Hi!

Thanks for the correction!

> RFC3484 beyond those already identified, based on the DT work and  

Yes, that's right.

> OSes with different 'defaults' now.

Yes, too.  This additional information seems to be useful for all  
attendee who do not know much about our discussion history.
(this time, it is seemed to have more new-comer as usual)

> observations made in the considerations draft.

thanks for pointed out, agree with you, pick the document is our next  
step.

> link is different to 3484 'default', or are you suggesting conveying  

Yes, my company has been implemented policy delivery system using by  
modified RA.
At the beginning of this activity, I had already mentioned that we  
have tested 2 types of policy delivery system, but I had not been  
writing.

> where by definition there is no DHCP service.

Really?
At last, now we have 3 types :-)
Can we mentioned about yours tomorrow?

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Nov 2009 13:37:15 +0000

> and I believe RA option should be the most feasible mechanism.

So the proposal is to move forward on a DHCPv6-based method (which we
have an existing draft to work with) and a new RA-based method?
 
I would imagine in my campus/enterprise scenario I would prefer to use
the DHCPv6 solution, if I wanted to convey non-default 3484 policy
to hosts in the network.   When a host changes point of attachment,
it should issue a new DHCP request which would in principle pick up
new policy for its new point of attachment, if different.

My own scenario is not one where we are multihomed though, or facing
dynamic external routing.

> Have you summarized these things in dt draft, or somewhere else ?

It's currently written up in a paper to PerCom 2010 (which is in April
next year), so we can't write a draft until that is reviewed/published,
due to the usual IEEE restrictions.

We have an initial software implementation based on Quagga/Linux.  This 
highlighted a bunch of issues with Linux, which I think we can and should
raise/promote/circulate as much as possible now.
 
> I'm trying to talk about this conflict solution mechanism, halfway

What we discussed in the IEEE paper were the various options possible,
e.g. the ICMP query for a routing hint could be to the on-link router,
it could be to a 'route server' (for which we used a Quagga router in
an OSPF domain) or the query could be to one or more edge router(s).

So the host gets policy dynamically, and in theory there would be no
need to try to distribute it (via DHC or RAs).   But, our prototype
only considers hints from pure routing information, it does not take into 
account policy from different upstreams (e.g. ISP A says prefer v4 and
ISP B says prefer v6).  i.e. it will try to discover the best path, and 
pick an appropriate address pair for that path.  

So we have some early prototype, and probably raised as many new questions
as we answered so far.   But I think it's an interesting approach.  

> >>I hope any comment or advise will be given by this night around 2200 

I agree on 3484, and on progessing the DHCPv6 mechanism.

I think if there are clashes these could be in managed or unmanaged
environments.   In managed environments the clashes may be resolved
administratively, and appropriate policy still conveyed by DHCP?

In unmanaged, perhaps dynamic environments, then I would assume there 
is more likely a need to resolve conflicts at the host.   The host
could either query router(s) for hints or it could take hints from a RA.
It's not wholly clear to me yet which is better for what circumstances.

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 9 Nov 2009 23:01:25 +0900

Tim,

> have an existing draft to work with) and a new RA-based method?

I like both RA and DHCP ways to be standardized.
But, DHCPv6-baesd method needs additional thing for correlation.
In multiple interface case, the interface itself can be used for
correlation, so it's easy, though.

But, if we try to be more generic, and try to support one interface
and multiple exit routers case, the interface cannot be used as
the correlation. I'm not sure this case should be supported or not.

> new policy for its new point of attachment, if different.

RA also works for your scenario ?

> dynamic external routing.

Another pro for RA is it's PUSH feature.
In multi-home TE case, the route can flap relatively frequently,
and routers want to kick the policy refreshment.
You can use DHCP reconfigure, or lifetime option for refreshment,
but reconfigure is hard to use sometimes, and lifetime option is
not suitable for frequent updates.

Basically, I believe, this time we need not to narrow down to
one single mechanism.

I'll reply in a separate e-mail regarding the issues below.

>>>> I hope any comment or advise will be given by this night around  
>>>> 2200
>>>> (?)
>>>> Thanks in advance,
>>
>> What do you think ?
>

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Nov 2009 14:09:33 +0000

> Can we mentioned about yours tomorrow?

I see no problem with mentioning it.   

A suggestion by Fred Baker to 'use routing hints' was cited in section 
3.2.1 of draft-ietf-6man-addr-select-sol-02.   But there are no details at 
all given for this idea.   The draft scores the router-hint approach very 
well against RFC5221.   This is partly why we decided to try it in 
practice (with help from Brian at JHU).    Fred's preference is to do the
route-hint query to the edge/egress router(s).

A reference would be "On the Use of Routing Hints for IPv6 Address 
Selection", J. Morse, T. Chown, B. Haberman, in submission to IEEE
PerCom 2010.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Nov 2009 14:13:25 +0000

I think your comments below are good.   The thing to do now is to figure
out the applicability of the two methods.   If two solutions are to
move forward I think we need to be clear what the use cases are, and 
your initial comments on this seem fine to me :)

Tim

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 9 Nov 2009 23:17:25 +0900

Regarding the ICMP kind of approach,

> raise/promote/circulate as much as possible now.

I cannot grasp the whole mechanism from this description, but
it reminds me the approach mentioned by Fred Baker long long
ago, which was summarzed in solution draft I believe.

IIRC, this kind of approach needs non-minor changes to RFC3484
and policy table mechanism. In that sense, that approach is
not in scope of address selection DT. Is that right ?

Honestly, I thought by DT draft adopted as wg item, we 6man
agreed on the policy table distribution approach.

> as we answered so far.   But I think it's an interesting approach.

I understand that the routing information can serve as address
selection policy, especially source address selection policy.

> It's not wholly clear to me yet which is better for what  

I think the latter case, unmanaged case is what we are trying to
solve so far. Conflicting policies are poured into the host.

I'm not sure query router, RA, and DHCP are all treated as ways
to distribute policy table here ?

ummm, sorry for random thoughts.

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Nov 2009 14:43:07 +0000

>    ago, which was summarzed in solution draft I believe.

Well, the draft gives no specifics about Fred's general suggestion.

>    not in scope of address selection DT. Is that right ?

How the mechanism fits with 3484 is an open question.   It's certainly
clear you can't (currently) cache route hints in the policy table due
to the implemented syntax limitations.

But you are right that route-hints approach is outside the scope of DT,
but I am mentioning it for the context.

>    agreed on the policy table distribution approach.

Yes :)

>    selection policy, especially source address selection policy.

Yes. 

The important issue is the policy distribution.   It looks like we have
good material for discussion in 6man.

The route-hint method I think has some potential in dynamic, unmanaged
environments, for source address selection policy as you stated above.

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 10 Nov 2009 00:41:24 +0900

All,

here attached slides for tomorrow.
Is it tomorrow morning when I have to turn in ?

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 10 Nov 2009 00:50:02 +0900

I omitted the correlation issue, because I felt it
is a bit trivial while talking with Tim.

Thanks,
any comments, typos, linguistics are welcome !

On 2009/11/10, at 0:41, Arifumi Matsumoto wrote:

> <20091110-ietf76-6man-addr-select- 
> dt.pdf>_______________________________________________

---

From: Bob Hinden <[email-masked]>
Date: Tue, 10 Nov 2009 08:15:09 +0900

> Is it tomorrow morning when I have to turn in ?

Thanks.  It's the 9am session this morning.

Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 9 Nov 2009 19:23:29 -0500

Hi Arifumi,
  The slides look good. Go for it.

Cheers
Suresh 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: November-10-09 8:15 AM
To: Arifumi Matsumoto
Cc: [email-masked]
Subject: Re: [addr-select-dt] Slides Re: tomorrow's presentation

Bob

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 10 Nov 2009 10:10:08 +0900

I have a problem with arifumi-6man-rfc3484-revise-02 because it will
continue the problems related to falling into the default entry. I have been
using the following policy table on my machines and have not been running
into any problems related to addresses (broken dns servers are another
issue). I am not going to argue the point about teredo before or after IPv4,
because that is a waste of time driven by people who don't want to use IPv6.
In any case something to review for 2.2 where label 5 can be set to
precedence 50 if you want to make it preferred over teredo & 6to4. 

Precedence  Label  Prefix     Usage Comment
----------  -----  ---------- ----------------------
     90      0     ::1/128     Self
     75      1     fc00::/8    Managed local
     70      1     fd00::/8    Unmanaged local
     60      2     2000::/3    RIR managed global
     40      3     2002::/16   Tunnel - 6to4
     30      3     2001::/32   Tunnel - teredo
     20      4     ::/0        Default
     10      5     ::ffff:0:0/96  IPv4
      5      6     ::/96       Deprecated - AutoTunnel
      4      6     fec0::/10   Deprecated - Site Local

I will send more when I have time to review it in more detail.

Tony

> From: [email-masked] [mailto:addr-select-dt-
> [email-masked]] On Behalf Of Arifumi Matsumoto
> Sent: Tuesday, November 10, 2009 12:41 AM
> To: [email-masked]
> Subject: [addr-select-dt] Slides Re: tomorrow's presentation
> 
> All,
>