RE: charter

[Jim.Bound@nokia.com]

I am ok with the first charter out and this revision.  I think the dates are
to aggressive for the milestones (and Feb 01 ????? is gone).  Add 30 days to
all dates is my input.  

/jim

> -----Original Message-----
> From: ext Thomas Narten [mailto:narten@raleigh.ibm.com]
> Sent: Thursday,February 15,2001 11:38 AM
> To: Randy Bush
> Cc: multi6@ops.ietf.org
> Subject: 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.
>