RE: New proposal for Network Layer IPv6 multihoming: MHTP

["Michel Py" <michel@arneill-py.sacramento.ca.us>]

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

Valid point; three remarks about that:

a) The scalability would be improved indeed because the rendezvous
points would
not process a lot of traffic, so the problem, instead of being size of
the
routing table aggravated by high traffic, would be size of the routing
table
only.

b) the scalability would be further improved because the routing table
would
be smaller (it would not contain the single-homed prefixes).

c) It might be a few years before we need billions of multihomed
prefixes.
Current hardware could accomodate a million MHTP prefixes. A million
IPv6
multihomed sites? In a while.
Maybe only one home out of two is going to be multihomed to two
different TLAs,
maybe a neighborhood would get a /48 instead of a home, who knows.
And by then, wrist watches would have a Gigabyte of ram.

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

The MHTP endpoint would not become unavailable.
- If one of the MHTP translation prefixes fails, the traffic would be
switched
to another translation block.
- If all the translation prefixes fails at the same time, there is not
much that
any protocol can do. Besides, idle connections would survive because, if
any path
has become available again during idle time, the first packet in either
direction
would trigger a new query and be proxied to the rendezvous point.
- It would make sense to have two routers with a mechanism such as HSRP
to dodge
router failures.

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

The discovery part is easy: rendezvous points advertise aggregates to
the multihomed
space. Multihomed traffic will naturally flow to the one deemed as the
closest by
the routing protocol.

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

Postponing it for 5 or 10 years would be good enough for me.

Michel.