Subject: [addr-select-dt] meeting at san francisco

From: Arifumi Matsumoto <[email-masked]>
Date: Sat, 21 Mar 2009 23:36:27 +0900

Hi, all.

Can we get together before the 6man session at Hilton ?

How about a slot before the welcome reception,
16:00 on Sunday Mar 22 ?

Please reply if you can come.

Best Regards,

---

From: (Tomohiro -INSTALLER- Fujisaki/藤崎 智宏) <[email-masked]>
Date: Sun, 22 Mar 2009 23:10:01 +0900 (JST)

Hi,

I'll join that meeting.

From: Arifumi Matsumoto <[email-masked]>
Subject: [addr-select-dt] meeting at san francisco
Date: Sat, 21 Mar 2009 23:36:27 +0900

 | Hi, all.
 | 
 | Can we get together before the 6man session at Hilton ?
 | 
 | How about a slot before the welcome reception,
 | 16:00 on Sunday Mar 22 ?
 | 
 | Please reply if you can come.
 | 
 | Best Regards,
 | _______________________________________________
 | addr-select-dt mailing list
 | [email-masked]
 | https://www.ietf.org/mailman/listinfo/addr-select-dt
 |

---

From: Tim Chown <[email-masked]>
Date: Sun, 22 Mar 2009 15:26:38 +0000

Hi,

I don't think I'm free then, sadly.

Note the draft version on the IETF agenda page is wrong - it lists the -01
version of the draft but the current version is now -02.  Hopefully Brian
can update that.

http://www.ietf.org/proceedings/09mar/agenda/6man.html

Tim

On Sat, Mar 21, 2009 at 11:36:27PM +0900, Arifumi Matsumoto wrote:
> _______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 23 Mar 2009 02:15:47 +0900

Tim,

do you have any time free before our Tuesday slot ?

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 22 Mar 2009 10:22:12 -0700

suggesting breakfast time, since none of US I think are IESG involved.
monday breakfast time (i.e. 8h00am)?

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Francis Dupont <[email-masked]>
Date: Sun, 22 Mar 2009 18:55:36 +0100

In your previous mail you wrote:

   
=> works for me but please confirm before...

[email-masked]

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 23 Mar 2009 03:31:47 +0900

Sorry for confusion.

As Tim suggested presenting, I think, we need Tim to attend this  
meeting.
And now we don't have much time left for 16:00 Sunday, I suggest  
postponing it.

I'd like to see how many people are available at Monday morning 8:00, as
Marc suggested.

Kindest regards,

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 22 Mar 2009 14:46:37 -0400

Both the times work for me. Just let us know.

Thanks
Suresh

Arifumi Matsumoto wrote:
> Sorry for confusion.
>
> As Tim suggested presenting, I think, we need Tim to attend this meeting.

---

From: Tim Chown <[email-masked]>
Date: Mon, 23 Mar 2009 01:15:19 +0000

Monday at 8am is fine for me, just say where.

I'm fine if someone else wishes to present, but am happy to do so if
required.

Either way, the important issue I think is to decide what we want to
ask the WG in the session, so we know what the next steps are.

Tim

-- 
Tim

---

From: Ruri Hiromi <[email-masked]>
Date: Mon, 23 Mar 2009 09:25:47 +0900

Hi,

I do want to meet but today I am moving towards the city.
If I got back there around 16:00, I will go.
Leave me(and others) the location, please?

> Please reply if you can come.

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

---

From: Ruri Hiromi <[email-masked]>
Date: Mon, 23 Mar 2009 12:24:21 +0900

Oh, I am sorry, my mailer won't send the message as I want this  
morning, please ignore this.

I will meet all of you tomorrow morning.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 23 Mar 2009 14:22:58 +0900

Ok,

so, gather at imperial A near from breakfast space
at 8:00.

regards,

---

From: Tim Chown <[email-masked]>
Date: Mon, 23 Mar 2009 14:58:33 +0000

On my way, see you there.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 23 Mar 2009 23:41:49 +0000

Hi,

Here are some notes from this morning's meeting, combined with
a few lines to describe where we are with the -02 draft.

I think the important input from you chaps is to look at the 
questions we should be asking the 6man WG and commenting on 
these.   Are they appropriate?   Any missing?   Any unnecessary?

If you can give me feedback today I will convert the notes into
slides to pass to Brian/Bob to upload to the agenda page.

--- General status ---

General scope is site/enterprise network, where
administrator wishes to convey policy to hosts
- may be different to 'RFC3484 default' policy
- may vary across site (with topology and/or time)
- may change for a host as it moves within site

New address selection DT draft issued:
- draft-chown-addr-select-considerations-02

Design Team is looking at:
- frequency of updates - how dynamic are they?
- approaches given the identified frequency of changes
- host detection of polciy changes
- whether an RFC3484 update is required

Main changes since -01:
- included nomadic nodes within a site
- noted the multiple interface (mif) issue, e.g. VPN
- possible policy conflicts (multiple admin domains)
- should we have a 'priority' interface for conflicts?
- initial notes on push vs pull solutions (pull = dhc = per host config)
- note that indicator of default policy in effect is useful?
- note that routing hints may be of value to a host

Frequency:
- most triggers are administrative (application of new policy)
- higher if many nomadic hosts
- higher if (changing) traffic engineering in use

--- Questions for the 6man WG ---

1) Overlap with mif
- the DT is focused on site/enterprise networks which may have nomadic
  nodes and may have multiple uplinks
- mif is focused on mobile nodes
- the DT should ensure all relevant scenarios are identified, the question
is where solutions are progressed, and how collaboration with mif happens
- what about a device in the site with an external VPN?
- what about nodes that might 'accidentally' have multiple interfaces up?

2) 3484 update how/when
- some clear issues, like Rule 9, ULAs
- can we proceed now independently of any requirements emerging from the DT?
- it seems there is nothing affecting progress in parallel now?

3) Do we consider just one administrative domain?
- simplifies considerations - because conflicts in policies unlikely
- but what about one site with two uplinks from different providers? 
- what about hosts in the site network that 'accidentally' or deliberately
  attach to other networks (VPN, wireless, etc)?
- solution we choose may affect the impact of being in multiple domains  

4) Handling conflicts?
- if we encounter them, how do we prioritise?
- or do/can we merge?
- perhaps one interface has higher priority?
- perhaps fall back to default policy if conflicting policies received?

5) Are we ready to move towards solution space?
- push vs pull solutions
- DHCP options seem preferable, allowing different policy per host

6) Information from routing state?
- pass routing information to host to assist decision?
- some early mif draft(s) seem to be doing this (pushing routing info
  rather than RFC3484 policy)

7) Should 3484 be just node-specific?
- or interface specific?
- mif issue?

8) What about application-specific limitations, e.g. firewalls?
- assume out of scope

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Mar 2009 00:09:36 +0000

So we need to consider the questions raised by draft-denis-v6ops-nat-addrsel
as well - as raised by Fred's recent mail.

Your comments on that are welcome too :)

Tim

-- 
Tim

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 23 Mar 2009 19:19:48 -0400

Hi Tim,
  I am not sure.  I do not think we can do anything about this 
specifically. The only thing we need to ensure is that the dynamic 
update mechanism we come up with must be able to support his scenario.

Cheers
Suresh

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 24 Mar 2009 13:46:57 +0900

Thanks Tim.
Let me add some comments below.

>  nodes and may have multiple uplinks

What do you mean by multiple uplinks ?
   The site has multiple uplinks ?
   Or a host in the site has multiple uplinks ?

> - what about nodes that might 'accidentally' have multiple  

To repeat my thinking,
as the focus is different, the solution can be different.
So, basically, we should work separately.

> - it seems there is nothing affecting progress in parallel now?

I think there is some possibility our dt activity results in
some update to RFC 3484, such as policy table syntax.

> - solution we choose may affect the impact of being in multiple  

Even focusing on site/enterprise networks, we should think about
multiple administrative domains case, which occurs accidentally
and/or against site administrator's will.

> - perhaps fall back to default policy if conflicting policies  

We can learn from implementation experience of host-global policy,
such as DNS server option.

> - pass routing information to host to assist decision?

assist what ?

> 7) Should 3484 be just node-specific?

This question should be merged in 4) ?

> 8) What about application-specific limitations, e.g. firewalls?

This is already possible by using addr-select-api, so there is no  
problem if we make it out-of-scope.

Regards,

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Mar 2009 16:34:46 +0000

>   Or a host in the site has multiple uplinks ?

It could be either.   I would assume if the site has multiple uplinks
from multiple providers that the site admin can configure (possibly
overriding default) 3484 policy to determine how those uplinks are used.

The question is where a *host* would receive multiple responses from
different administrative domains, typically, beyond the case where it
uses VPN, or some 2nd interface (e.g. some wireless access when the
primary access for the site is wired).
 
> >- pass routing information to host to assist decision?

The address selection decision and thus the path taken.   There seems to
be some drafts on this within mif.
 
> problem if we make it out-of-scope.

Except that the application probably doesn't have knowledge of such
middlebox interference, but it may have knowledge of whether the app
should prefer IPv6 (even if a transition tool) over IPv4, perhaps?

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Mar 2009 18:21:44 +0000

Here are some *draft* slides based on the comments.

If I don't hear anything back by early afternoon, I'll pass the slides
as final on to Brian and Bob.

Tim

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Mar 2009 05:32:29 +0900

Tim,

your ppt covers every points to be solved well,
however, it looks to me like containing so many
questions to be answered from our short time session.

How about narrowing down key questions, like
scope issue, multiple domain and policy conflicts issue ?
And as in your slides, here in IETF74, the issue of
updating  RFC 3484 was raised several times, we should
treat this issue also.

But, of course, the slide you can present best is best :)

Kindest regards,

On 2009/03/25, at 3:21, Tim Chown wrote:

> <ietf74-chown-addr- 
> select-02.ppt>_______________________________________________

---

From: Tim Chown <[email-masked]>
Date: Tue, 24 Mar 2009 20:50:35 +0000

A very good point - time is limited.

I have reduced it to 5 questions.  We can omit 1 or 2 if time is short.

Tim

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 25 Mar 2009 07:18:01 +0900

All,

Though this should not necessarily be included in today's
discussion, some random thoughts regarding policy conflicts below.

> is where solutions are progressed, and how collaboration with mif  

Then, DT focus should be within the following scope:
1) a single interface case.
2) multiple interface case with mobile nodes not involved.

The former case, as we've discussed, policy conflicts is hard to happen.
So, let's think about the latter case.

The latter case, we can classify the cases into the followings.
2-1) two (or more) independent (physical) interfaces are attached to a  
host.
2-2) one interface is overlapping with the another interface.
   Namely, one interface is logical and packets go through a physical
   interface. Typically this is a VPN.

Regarding 2-1, now that a mobile node is not involved in the case,
what kind of concrete example can we imagine ?
Wired interface and wireless interface to connect the Internet ?
Can we assume these two interfaces are used for the same purpose of
connecting the Internet ? If so, we can ignore either interface.
We may be able to even conclude that this is a misconfiguration,
and out-of-scope.

Regarding 2-2, the logical interface depends on the physical one,
so if logical interface policy spoils physical interface policy,
both interfaces perhaps will not work.
Vice versa is not true here. Even if the physical interface policy
is adopted globally, only the logical interface does not work.
And, usually, it is the overlapping interface or it's setting-up
software that knows what kind of routing/address-selection policy
the underlying interface should have.
So, it should be overlapping interface that is responsible for
setting-up routing and address-selection policy.

Any comments are welcome.