2.4.15 Site Multihoming in IPv6 (multi6)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Thomas Narten <narten@raleigh.ibm.com>

Operations and Management Area Director(s):

Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>

Operations and Management Area Advisor:

Randy Bush <randy@psg.com>

Mailing Lists:

General Discussion:multi6@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe multi6
Archive: ftp://ops.ietf.org/pub/lists/

Description of Working Group:

A multihomed site is a site that has more than one connection to the public internet with those connections through either the same or different ISPs. Sites choose to multihome for several reasons, especially to improve fault tolerence, perform load balancing, etc.

Multihoming today is done largely by having a site obtain a block of address space and then advertising a route for that prefix through each of its ISP connections. The address block may be from the so-called provider independent space, or may be a sub-allocation from one of its ISPs. A site's ISPs in turn advertise the prefix to some or all of their upstream connections and the route for the prefix may propagate to all of the routers connected to the default-free zone (DFZ). As the number of sites multihoming in this manner increase, the number of routes propagated throughout the DFZ increases and overall routing stability decreases because of the burden on convergence time. This WG will explore alternative approaches with better scaling properties. Specifically, the WG will prefer multi-homing solutions that tend to minimise adverse impacts on the end-to-end routing system and limit the number of prefixes that need to be advertised in the Default-Free Zone (DFZ).
This WG will consider the problem of how to multihome sites in IPv6. The multihoming approaches currently used in IPv4 can of course be used in IPv6, but IPv6 represents an opportunity for more scalable approaches. IPv6 differs from IPv4 in ways that may allow for different approaches to multihoming that are not immediately applicable to IPv4. For example, IPv6 has larger addresses, hosts support multiple addresses per interface, and relatively few IPv6 address blocks have been given out (i.e., there are no issues with legacy allocations as in IPv4).
The WG will take on the following initial tasks:
Produce a document defining what site multihoming is, the requirements for a multihoming solution (from both the end site and ISP perspective). This document will also include a taxonomy of different ways that multihoming might be achieved.
Produce a document describing how multihoming is done today, including an explanation of both the advantages and limitations of the approaches.
The WG will also consider specific proposals to multihoming in IPv6 (both existing and new) and select a small number of them to work on as formal WG items. Development of specific solutions will require approval of the IESG (e.g., a recharter).

Goals and Milestones:

Feb 01

  

Submit initial I-D on requirements, terminology, etc.

Apr 01

  

Submit I-D on how multihoming is done today

Apr 01

  

Begin consideration of approaches and proposals that could be pursued.

Aug 01

  

Evaluate approaches and select those to be worked on.

Sep 01

  

Submit requirements ID to IESG for publication as Informational RFC.

Sep 01

  

Submit 'how multihoming is done today' ID to IESG for publication as Informational RFC.

Sep 01

  

Evaluate progress, recharter or shutdown

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

Multi6 WG minutes
IETF 50, Minneapolis.

As recorded by Jun-ichiro itojun Hagino <itojun@itojun.org> and massaged by Thomas Narten <narten@raleigh.ibm.com>

focus of wg
- wg under ops area
- - focus on v6
- - rpoduce document on what multihoming is
- - produce document on how multihoming works today
- not chartered to re-architect v6
- recharter required to develop/pursue specific solutions

draft to look at:
- 2260
- aggr

how applicable are teh following drafts:
- LIN6
- mohta-e2e

mohta: mohta way works with no change to IPv6.

multihoming-requirements-00

mohta: re-routing is a problem

ben: need not to repeat mailing list comments

btw, 2373/2374 revision on the way.

paul francis: why this is outside of ipng?

randy bush: operators do not hang out in ipng

deering: mis/non-communiation between ipng and network operators, that was a problem. it is good that people are showing up here.

changes?
need to be evaluated with impacts. "extend" is okay (with backward compat?)

operators come to ipngwg!

Q: overview of current architecture, how much detail do we need?

ben: will improve. maybe two separate drafts - (1) current arch (2) goals.

Q: jeff houston wrote a good summary of current arch.

localized policy -> aggregate, what happens?
can individual hosts/processes express policy?
can routing protocols handle policy settings from them?

huitema: even now, we have local policy-like behavior (like connect retries)

granuarity of policy control?

send drafts/fragments of drafts!

Q: middle boxes may want to enforce policies (like diffserv/policy-routing?) metrics/criteria

mohta: it is possible for bgp routers to convert metric information based on its policy.

narten: injecting EGP routes into IGP?

mohta: yup. small default free zone makes it possible

ben: may not be necessarily wise, not very easy.

deering: how to express policy? is it api issue? strict source routes?

ben: i'm not trying to propose strict things, but it may be useful to propose policy explicitly.

soren: avoid contract/financial/....

huitema: we should not try to re-architect internet.

randy: would like to make sure scaling issues are within possible-to-handle region, or better-than-v4. ipngwg is doing very good, but operators may want to input from real experience.

Slides

Agenda