Subject: multihoming proposals summary again.

From: Peter Tattam <[email-masked]>
Date: Wed, 22 Sep 1999 16:08:17 +1000 (EST)

I don't believe anybody has yet volunteered to put together this list.  As I
raised the topic, I guess the responsibility falls on my shoulders.  If no
volunteers come forward within a day, I can do it although I'm probably not the
best for the job as I also have vested interest in at least one proposal from
myself being considered. 

Are there any volunteers for an impartial person to create the summary list?

I propose some ground rules should be laid...

Once the list is published, it will be counter productive to argue over what is
listed, or the contents of suggested proposals.  I would strongly recommend
that all discussion on the summary list be postponed until after the Interim
meeting has concluded and minutes are published.

Also, to be fair, no proposal should be left off the list provided it meets the
technical standard of discussion acceptable to this mailing list.  Whether it
works or not should not matter - that would (hopefully) be decided fairly
quickly at (or before?) the interim meeting.  Of course a prudent course of
action would be to get a couple of key opinions beforehand from knowledgeable
individuals on the IPng working group (PRIVATELY!!!).

If we can't agree on the ground rules... I won't bother.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Peter Tattam <[email-masked]>
Date: Thu, 23 Sep 1999 13:23:40 +1000 (EST)

> If we can't agree on the ground rules... I won't bother.

In the absence of volunteers, I will need to do this as time is running short.

If you have a proposal, send it to me ASAP.  I need,

1. Name of proposal (if you haven't thought of one do so, make it short or
provide acceptable acronym)

2. Author(s),  please provide email address(s) for questions.

3. If possible a one paragraph description. Try to be brief, and also try to
place the key concept in one sentence.

4. A URL for the full proposal.  This is a must.  A reference to a mail message
is not sufficient. It should be in a form that makes it easy to print out &
view from a web browser.  It doesn't have to be RFC formatted, but as long as
it has enough detail to determine if it works it will be ok.  And as stated in
the ground rules, it should meet the technical standard expected of this
mailing list. 

I will acknowledge receipt of each proposal.  If you don't get a receipt within
a day, make a LOUD noise on the list or send me a FAX & my secretary will pick
it up.  Don't forget we are in GMT+1000 time zone, one hour before Japan, about
8-11 hours before Europe and around 7-10 hours after North America.  I'm
usually online till at least 12am which puts me in contact with most of Asia &
Europe.  I'm also online for North American evenings, but usually asleep or
recreation for most of North American working hours, although there is usually
a slight overlap at either end of the working day.

For starters, could I ask the following...

a) Itojun to provide RFC2260 proposal details.

b) Jessica to provide SMPL proposal details.

c) Dan Lanciani to provide his proposal details.

d) I will table mine.

I may have missed some, apologies - these are only the ones most recently
discussed.

And, (I might get roasted here :) if there are *serious* proposals relating to
non-aggregation, now's your chance, but it better be *exceptionally* good
because that decision is already laid in concrete, and people don't want to
tear up that concrete.   I will table them, but please don't shoot the
messenger.

No cutoff time has been decided for the list, so I will keep it open as long as
possible, and also post the list to ipng and also on my web site.

Peter

---

From: Francis Dupont <[email-masked]>
Date: Thu, 23 Sep 1999 13:53:51 +0200

In your previous mail you wrote:

=> mutual backup

=> Francis Dupont (as the editor)
E-mail: [email-masked]

=> Take a site attached to two ISPs, with a line (and an agreement) between
the two ISPs you can get a scheme with no long prefix injected to upper
levels and which can cope with any single failure.
This is a pure routing scheme, a kind of symmetric extension of Jessica's
SMPL.

   4. A URL for the full proposal.

=> draft-ietf-ipngwg-multi-isp-00.txt Section 5
(read previous sections to understand the issue and the solution)
   
[email-masked]

PS: if you have not my I-D in a window on your screen:


          ^ A/x and B/x           ^ B/x and A/x
          |                       |
        +-----+                +-----+
        |     |------ A/x ---->|     |
        |  A  |                |  B  |
        |     |<------ B/x ----|     |
        +-----+                +-----+
          ^ |            B:S/x+y ^ |
          | |            A:S/x+y | |
          | +-- A/x -+  +--------+ |
          |          |  |          |
          +--------+ |  | +- B/x --+
       A:S/x+y     | |  | |
       B:S/x+y     | V  | V
                  +--------+
                  |        |
                  |   S    |
                  |        |
                  +--------+
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 23 Sep 1999 14:02:31 +0200

=> use of mobility mechanisms

=> Francis Dupont (as an editor)
[email-masked]

=> a mechanism developped for IPv6 mobility, "bindings", can be reused
for multihoming. This makes connection resilient to provider failures.

=> draft-ietf-ipngwg-multi-isp-00.txt Sections 6 and 7.
Bindings are described in draft-ietf-mobileip-ipv6-08.txt (and previous),
the first document about the proposal is still available at
http://www-dcg.fnal.gov/~crawdad/mhome/index.htm
   
Regards

[email-masked]

---

From: Peter Tattam <[email-masked]>
Date: Fri, 24 Sep 1999 00:44:40 +1000 (EST)

Here is the latest list from responses sent to me.  I have filled in the gaps
for some I haven't received yet.

http://jazz-1.trumpet.com.au/ipv6-draft/multihoming_summary.html

Let me know if you want also a copy sent to the mailing list.

Peter

---

From: Steve Deering <[email-masked]>
Date: Thu, 23 Sep 1999 09:04:34 -0700

Peter,

Thank-you for stepping forward to help organize and categorize recent
multihoming ideas -- your web page looks good, and it will be very
useful input to the working group.

Note, however, that it is inappropriate for you to start declaring
conditions on which ideas shall be considered (e.g., only those that
have a URL) or which ideas will be discussed in which order at the
interim meeting.

The working group began the task of considering solutions to IPv6
multihoming problems at the last IETF meeting, and a consensus was
reached on some basic aspects of the problem (e.g., that IPv6's support
for multiple addresses per interface necessarily implies the need for
host-based, not just router-based or ISP-based, mechanisms), and on
some specific directions to pursue.  Please see the minutes for both
the summary and conclusions; we will review those previous understandings
at the interim meeting.

We continue to welcome additions to the agenda for the interim meeting,
for anyone wishing to present additional ideas or proposals for solving
aspects of multihoming.  Peter: would you like an agenda slot to present
your collation of ideas and/or a summary of the state of the mailing list
discussions?

We will, of course, also accept changes to the agenda in real time at
the start of the meeting, as usual.

Bob Hinden / Steve Deering
IPng Co-Chairs

---

From: Peter Tattam <[email-masked]>
Date: Fri, 24 Sep 1999 02:02:27 +1000 (EST)

There was a broken link in summary.  It has now been fixed, and I have verified
that all other links now work.

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 24 Sep 1999 03:36:19 +1000 (EST)

All,

Just for the record,  I want to publicly state that the preparation of the
summary is not in any way intended to usurp the agenda of the meeting or the
wishes of those chairing and organizing the meeting.

The summary serves only to make sure that I (a self professed newbie) and
possibly others know what the heck we are talking about and not waste valuable
time going over old ground at the meeting itself.  It is also a result of
having been blasted a few times for not having read all the specs.

I humbly apologize for any misunderstandings related to this issue.

Regards

Peter

---

From: Robert Honore <[email-masked]>
Date: Thu, 23 Sep 1999 14:24:06 -0400

Dear Peter,

You might also want to consider asking the authors for some way to contact them,
so as to obtain a copy of their propositions, in lieu of a URL for their
propositions.  Some will not yet have their propositions published in any form
yet.

Yours sincerely,
Robert Honore.

---

From: Jim Bound <[email-masked]>
Date: Thu, 23 Sep 1999 15:36:15 -0400

good idea also check that all authors can be present at the meeting.
if they can't the chairs probably know but thought I would add this
logic check too.

/jim

---

From: Peter Tattam <[email-masked]>
Date: Fri, 24 Sep 1999 12:34:19 +1000 (EST)

> propositions.  Some will not yet have their propositions published in any form

I will be happy to do this.

Also, I will adding some temporary email addresses for authors who may be in
transit at meetings over the next few weeks.  And let me know if there are any
other alterations to the document.

Peter

---

From: Jessica Yu <[email-masked]>
Date: Thu, 30 Sep 1999 08:41:56 -0400

Ok, here is the summary of Simple Mulithoming solution. It was sent
to Peter several days ago so it may be included in his summary already.

						--Jessica

Summary of "Simple Multihoming Routing for IPv6"

Main features:

      a. Providing redundancy and load sharing for the multi-homed sites
      b. Scaling the global IPv6 Internet routing table
      c. Simple and thus operationally manageable and viable, which is
         becoming a strong requirement of ISPs 

Other characteristics:

- It's a routing approach using existing routing protocols and 
  instrumentations.
- No need for multi-address per host 
- No need for building tunnels
- Economic and avoiding errors and outages likely introduced by complexed 
  solutions
- Applicable to most of the environment and it does not prevent certain 
  sites use other solution for their special environment or requirements