[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.