-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
During the interim Multi6 WG meeting in Santa Monica, the group
tried to come up with a classification of the proposals made so far
based on the classes used in Geoff Huston's
draft-huston-multi6-architectures-01.txt. During the interim meeting,
this classification was discussed and to some extent reordered. Below
you will find the outcome that we agreed on in the room:
A. Addressing based
* draft-kurtis-multihoming-longprefix-00.txt
draft-savola-multi6-asn-pi-01.txt
draft-ohta-multihomed-isps-00.txt
draft-toyama-multi6-operational-site-multihoming-00.txt
draft-ohira-assign-select-e2e-multihome-01.txt
draft-van-beijnum-multi6-isp-int-aggr-01.txt
* draft-van-beijnum-multi6-2pi1a-00.txt
draft-ohira-multi6-multilink-auto-prefix-assign-00.txt
draft-teraoka-multi6-lin6-00.txt
B. "Intermediate systems"
* draft-bagnulo-multi6-mhexthdr-00.txt
draft-py-multi6-mhtp-01.txt
C. Hostbased
draft-huitema-multi6-experiment-00.txt
draft-huitema-multi6-hosts-03.txt
D. Tunnels
E. Transport
draft-coene-sctp-multihome-04.txt
draft-coene-multi6-sctp-00.txt
draft-arifumi-multi6-tlc-fm-00.txt
draft-ohta-e2e-multihoming-05.txt
draft-ohta-multi6-8plus8-00.txt
F. Wedgelayer 3.5 / Fat IP
draft-nordmark-multi6-cb64-00.txt
draft-nordmark-multi6-noid-01.txt
* draft-nordmark-multi6-sim-01.txt
draft-ylitalo-multi6-wimp-00.txt
draft-crocker-mast-proposal-01.txt
draft-nikander-multi6-hip-00.txt
draft-van-beijnum-multi6-odt-00.txt
G. Components
draft-de-launois-multi6-naros-00.txt
draft-crocker-celp-00.txt
The drafts that are preceded with a "*" where withdrawn during the
interim meeting by their authors. The chairs now would like to proceed
with trying to limit the numer of classes of proposed solutions still
on the table and try and judge the support for each class. Based on
the discussions during the interim meeting it appears that there is no
or limited support for the solutions in class A, so we would like to
remove this class of solutions. The same goes for class B. As for
class C, we would like to move the hostbased approach into the
Components class (which we will explain below). As for the tunnels
class, the only proposal that we could come up with that would fit
would be Jerooen Massar's draft-massar-v6ops-ayiya-00.txt, which is
not a complete multihoming solution. We therefore propose to add this
to the components class. As for transport, we judge that although
there is some support for some of the solutions in the transport
class, it does seeem to be in the minority. This then leaves us with the
F class. The chairs would like to encourage the authors of drafts in
this category to work together to try and combine their ideas and if
possible come up with a common proposal. We _might_ appoint a
document editor for this class to help with the work and make sure we
make progress.
As for the components class, this is a class of proposals that do
contain interesting ideas that might be worth studying further, but
that we believe do not constitute a full solution to the multihoming
problem in their own.
The chairs hope that by using this approach, we would have few enough
proposals by the November IETF to start discussion on a final
proposal and singling out of a proposal to move further (i.e.
recharter).
The chairs feel there was consensus in the room for this approach,
and would now like to find out if people on the list disagree. We
aim to produce a final agreed categorisation and list of next steps
within two weeks, so please send your comments now.
Kurtis & Brian
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
iQA/AwUBQM8sU6arNKXTPFCVEQJZGwCeOWUyZQA0swRE0h5XkuUt9O2NlD8An1uT
q2LPtsVnkVvTLtmR78w3t0Xm
=PiIQ
-----END PGP SIGNATURE-----