Re: charter

[Thomas Narten <narten@raleigh.ibm.com>]

This note responds to several comments and includes an updated
charter.

"Eliot Lear" <lear@cisco.com> writes:

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

> It is not yet readily apparent that the problem cannot be solved for both
> IPv4 and IPv6, since today they both rely on the same mechanisms.  While it
> is possible that this might not be the case in the future, why make it a
> preordained conclusion of the group?

> Therefore, I recommend a substitution, as follows:

> The primary goal of this group is to recommend multihoming mechanisms that
> scale far beyond where we are today.  To meet that goal, this group may
> consider any advantages IPv6  has over IPv4 (e.g., larger address space),
> but is not precluded from making recommendations for IPv4.

I did not make this change. The sense I get is that this WG is should
focus on IPv6. That is not to rule out discussion about IPv4 issues
(and indeed, there is much to be learned from IPv4). But there is a
danger that focussing on IPv4 will bog us down on issues that are not
directly applicable to IPv6. Also, if it becomes clear that something
comes up that really applies to IPv4 and indicates a focussed effort
on an IPv4 approach is desirable, there is nothing to prevent us from
proposing a recharter or additional WG.

> > Produce a document describing how multihoming is done today in IPv4,
> > including an explanation of both the advantages and limitations of the
> > approaches.

> Please remove "in IPv4", since the mechanisms used in v4 and v6 are all but
> identical.

Done.

Jim.Bound@nokia.com writes:

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

Feb 01 means Feb 2001. The IETF web page isn't y2k compliant, it
seems. :-)

Duncan Rogerson <duncanr@cisco.com> writes:

> > Randy, I'm not saying it will or will not be true.  I'm just
> > asking that we not hard code it, given what reality is TODAY.

> Yes.  Otherwise it sounds to me more like the proposed wg is not
> restricting itself just to the multihoming issue, and is out to
> redesign the routing model as a whole.  Which is not necessarily a
> bad thing, but then the naming of the group is something of a
> misnomer.

This WG is restricting itself to multihoming. But I don't think we
should entirely rule out discussing radical approaches. I.e., we need
a real solution, and if radical is all we end up coming up with...

Having said that, the charter is currently structured so that limited
discussion is OK, but the WG does not have the green line to go off
and redesign things and do the complete spec. Before doing that, I
think we should have a more formal process for reviewing overall
implications of an approach so we have an idea of what direction we're
going in and the WG can first talk about whether there is sufficient
support for going in a particular direction, and if so, how to go
about it (e.g., another WG, IRTF, etc.) This is covered in the charter
under the words:

  Development of specific solutions will require approval of the IESG
  (e.g., a recharter).

Ran Atkinson <rja@extremenetworks.com> writes:

> Propose adding words to the effect (edit to taste):

> 	The WG will prefer multi-homing solutions that tend to 
> minimise adverse impacts on the end-to-end routing system and 
> minimise (or strongly preferably shrink) the number of prefixes 
> that need to be advertised in the Default-Free Zone (DFZ).

I edited your text to fit it into the charter and came up with:

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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> writes:

> > > I think additional example must be added:
> > 
> > > 	IPv6 differs from IPv4 that its global routing table is small.
> > 
> > I don't follow. While it is a goal that IPv6 routing tables be
> > smaller,  this has to do with a lot of factors, including whether we
> > get a handle on multihoming.

> The current status of IPv6 is that there is no allocation swamp.

Wording on this point added to charter. Specifically:

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

Revised charter below.

Thomas

Site Multihoming In IPv6 (multi6)
-------------

Charter 
Last Modified: 21-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 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	  Initial ID on requirements, terminology.

Apr 01	  Initial'how multihoming is done today' ID 

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 'how multihoming is done today' ID to IESG for
	  publication as Informational RFC.

Sept 01	  Evaluate progress, recharter or shutdown.