[ietf49] multihome6 minutes

[Jun-ichiro itojun Hagino <itojun@iijlab.net>]

	Here's a little bit cleaned-up log for the today's meeting.
	I failed to note who was the speaker, so there can be mistakes.
	thanks for Eliot Lear who sent me his memo.

itojun


---
Rough summary: exchanged thoughts regarding to:
- what is multihoming anyways?  what is the goal?  problem space?
  a site connected to multiple ISPs
  multihomed second level ISP
- node with multiple address is inherent in IPv6
  (1) addresses from different scopes, (2) multihoming, (3) during renumbering,
  (4) (mobile) host with multiple interfaces, multiple addresses
- ways to handle multihoming issues.
	multiple address on node + source address selection
	routing solutions
	8+8
- impact?
	routing table overflow
	complicated-than-v4 host implementations/site operations
- IPv6 only, or IPv4/v6?
	(situation is very different between v4/v6)
	IPv6 only solution is okay, IPv4/v6 solution can be useful too.

Proposed output:
	A set of minutes
	A proposed charter, with a couple of milestones
	Taxonomy document
	multi6@ops.ietf.org (managed by majordomo)

Proposed charter:
	develop a mechanism or group of mechanisms that enable multihoming
	hosts, enterprise end systems, and intermediary routing systems.
	consideration of mobility is NOT ruled out at this point.

===

Randy: assumption today is,
- we have to do v6.
- we may need to do what we have done for v4 multihoming, in v6 multihoming
but, routing table will explode, as # of prefix will be huge.
proposals are out there, but we need a better one (operationally possible)

???: why not multiple address to host?

???: source address selection needs major change in our picture, it's a mess

itojun: There are multiple proposals for source address selection which is
inside the stack, so that no modifications are necessary at the application
layer.

Randy: But this is pushing routing information outside of the routing realm
at other layers (according to Randy).

Hinden?: "Multiple address per interface" is in IPv6 for couple of reasons,
(1) addresses from different scopes, (2) multihoming, (3) renumbering.
We didn't see a scaleable routing solution, so we tried to solve it in address
selection.
Source address selection is basic problem to IPv6 anyways.
we don't know how to make routing scale, when we have huge # of
sites are multihomed.
How do you pick an address that gives you a good route?  That's a
hard problem.

???: There are issues in routing, yes.
BGP has no metrics it's all metrics, and IGP is all metrics no policy.

???: How can we cope with routing table overflow?
(1) aggregation, (2) faster/memory-rich routers, (3) source address selection

Randy: Statistics from IPv4 routing experiencesshould have been consulted,
to understand scalability implications in multiple address assignment.

Christian: If the host could do intelligent selection that would be a
good thing.

Randy: the decision is being made too far from the routing.

Christian: there are examples today that do exactly that: content networks

Eliot: it [= multiple address + source address selection] works on the small,
but it's either n^2 by looking at routing, or it's delay based.

Benjamin Black: it's not appropriate for hosts to carry 100,000 prefixes. 

Vijay Gill: many customers cannot handle a default. 

Peter Lothberg: Hosts with multiple interfaces are routers.  Briefly
described 8+8.  Let the routers choose best route by picking the upper bits
(embed some routing preference into upper 64 bits).
Renumbering allows the condensing of the routing table.

Ohta-san: It may be okay to propagate larger (non-default) routing table to
end nodes.  we have a upper limit due to v6 alloation policy (8192).
Looked too optimistic for some people.  Then auction routing entries.

Vijay Gill: 8+8 non-starter because it's too hard.  multihoming is too hard.

Can we diagnose address selection and routing issues separately?
Mixed opinions.
- they are separate.
- tied with routing.

CIDR decreased routing table entries, and then, resistance/hesitation
for renumbering added more entries.

Why multihome? - load sharing, robustness (reachability)
Multihoming has multiple goals - lower delay, more bandwidth, improve
reachability, whatever.  They may conflict with each other.

Benjamin Black: there is no pent up demand.  Demand is directly reflected.
Moving to a system that has more addresses does not imply that there would
be an increase in demand.  Because of difficulty in setting up multihomed
network, there will be no skyrocketing of demands.

Randy: We cannot know future demands are, so don't predict demand.

Christian: Need to support more and more hosts with multiple interfaces, with
different policy.  (e.g. notebook PC, with wireless and wired, both active -
multiple interfaces, multiple addresses).  How do i do source selection? 

During renumber, we will have multiple prefix anyways.

Ohta-san: source address selection not an issue, based on destination
response.

Randy: Vast majority of traffic is asymettric. 

Thomas Narten: How do you handle provider inspired renumbering?

Randy: 8+8. 

Christian: How do i get the source address? 8+8 is one way.  A discovery
mechanism is another.

Eliot: Should we separate source selection? 

Thomas: Source selection is required and important. 

Eliot: Agree, but do we need to do them in the same working group. 

Thomas: Source selection allows for a form of multhoming. 

Randy: First define multhoming and explain why people want it. 

Christian: 8+8 is easy because it has security drawbacks.

Bill Manning: I thought we were talking about the impact multihoming has on
routing?

Problems are there, need a working group?

Requirements document to be done by benjamin black. 

Is it useful to discuss v4?  Not sure.
Situation is different.  (1) larger address space, (2) allocation policy (no PI)
We need not to constrain ourselves to v6 solution.
V6-only solution is fine, v4-v6 solution is also fine.

One solution, or multiple solutions?

Need to diagnose relationship between:
- external routing
- source address selection

Conflicts between proposals/mechanisms.
- ingress filter and source address selection

Is source address selection needed/major topic? - looks to be yes.

Definition of multihoming
- single address, multiple ISP.
- multiple address, multiple ISP.

"Multiple interface" multihoming is slightly different from
"single interface" multihoming, because interfaces has policy.

Do we need to cook up new routing protocol?
Not sure what should be done.
Taxonomy of problems is necessary.

Multihomed second-level ISP.

itojun: Really play with IPv6, don't just think about it.

Work item:
- set of minutes, draw up charter, milestones,
- taxonomy of problem and goals.
- problem statments,
- wg, or bof?
- mailing list?  multi6@ops.ietf.org (under preparation - majordomo managed)

charter?
- multihoming mechanism(s), for end systems, enterprise and
  intermediate/toplevel ISPs
- identify what is in scope, what is out of scope, what is already solved
	mobile users, connected to two ISP
	policy issues?
	mobile-ip6 solved which part?