Subject: New proposal for Network Layer IPv6 multihoming: MHTP

From: "Michel Py" <[email-masked]>
Date: Mon, 6 Aug 2001 14:41:22 -0700

Dear multi6 members,
 
I would greatly appreciate the group's feedback on the following text I
just submitted.
 
http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-00.txt
 
Regards,
Michel.

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 7 Aug 2001 11:55:50 -0700 (PDT)

Hi,
I read this draft, and my main complaint is that it does not seem to solve
the main (and only?) problem with IPv4 multihoming, which is
scalability---this document proposes to maintain the MHTP prefixes of
*all* multihomed sites, and this means that the same scalability
problem arises, whether these prefixes are of fixed or variable length as
in IPv4. Imagine the scenario where every home is multihomed---/48
MHTP prefixes are certainly sufficient, but I don't think any router can
maintain translation tables for these billions of multi-homed sites (or
homes in this case).

Other potential problems:
1) As far as I can tell, connection survivability probably becomes worse
in this case than with IPv4 because of the way the
the source MHTP client tries to  discover failed MHTP endpoints--by
constant pro-active pings.
Apart from the increased traffic due to
constant pinging between the source MHTP client and the destination MHTP
endpoint, this exposes faiures that would not have been noticed in some
cases---for example, currently, an ssh session would survive a transient
failure in a router if the connection is idle during the failure, but
would not probably survive in MHTP because the multihomed
destination router (or MHTP endpoint) would become unavailable to the
pings. What happens in these cases is not specified by the draft.

2) How are rendezvous points provisioned and discovered? The draft says a
TLA would run them, but questions about scalability, availability and
discovery of rendezvous points still remain.

3) Problems acknowledged in the draft itself, which include sub-optimal
paths for messages, first-packet latencies, etc.

In any case, I see the scalability problem still persisting, and that is
my main objection...

thanks,
ramki

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 7 Aug 2001 12:58:01 -0700 (PDT)

I would just like to add that if one is looking into NAT-based solutions,
Paul Francis and I have a paper at this year's SIGCOMM conference about
such a protocol for dealing with address renumbering and multihoming
issues using NATs. It has some elements common with MHTP, and shows how
one can do away with out-of-band pings, rendezvous points, etc. The protocol is
called IPNL, and the paper is available from:

http://www.acm.org/sigcomm/sigcomm2001/p6.html

thanks,
ramki

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 Aug 2001 15:25:39 +0859 ()

Michael Py;

My mailer says:

[Charset UTF-8 unsupported, skipping...]

Use ASCII.

				Masataka Ohta