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
Thomas Narten <email@example.com>
Randy Bush <firstname.lastname@example.org>
Bert Wijnen <email@example.com>
Randy Bush <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: subscribe multi6
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).
Submit initial I-D on requirements, terminology, etc.
Submit I-D on how multihoming is done today
Begin consideration of approaches and proposals that could be pursued.
Evaluate approaches and select those to be worked on.
Submit requirements ID to IESG for publication as Informational RFC.
Submit 'how multihoming is done today' ID to IESG for publication as Informational RFC.
Evaluate progress, recharter or shutdown
Multi6 WG minutes
IETF 50, Minneapolis.
As recorded by Jun-ichiro itojun Hagino <firstname.lastname@example.org> and massaged by Thomas Narten <email@example.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:
how applicable are teh following drafts:
mohta: mohta way works with no change to IPv6.
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.
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.