[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: charter
I've appended a slightly revised version of the charter (comments from
Erik Nordmark) and proposed some milestones.
Comments?
Site Multihoming In IPv6 (multi6)
-------------
Charter
Last Modified: 15-Feb-01
Chair(s):
Peter Lothberg <roll@stupi.se>
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: 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 in IPv4 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.
This WG will consider the problem of how to multihome sites in
IPv6. The multihoming approaches used in IPv4 can of course be used in
IPv6, but IPv6 represents an opportunity for more scalable
approaches. Also, 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 and hosts
support multiple addresses per interface.
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 in IPv4,
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 Initial ID on requirements, terminology.
Apr 01 Initial ID on multihoming in IPv4.
Apr 01 Begin consideration of approaches and proposals that could
be pursued.
Aug 01 Evaluate approaches and select those to be worked on.
Sept 01 Submit requirements ID to IESG for publication as
Informational RFC.
Sept 01 Submit IPv4 multihoming ID to IESG for publication as
Informational RFC.
Sept 01 Evaluate progress, recharter or shutdown.