RE: MHTP draft (draft-py-multi6-mhtp-00.txt)

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

Shane,

Some of your questions have been adressed in the not-yet-published -01
available here:

http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt

I encourage everyone to refer to the -01 text instead of the -00.

>> I assume that DFZ is the "Default-Free Zone".  Perhaps you should
>> define it in the document, so I don't have to guess which of the 9
>> documents referenced contains it?

Thanks for the suggestion. I also acknowledge that I need to polish the
references in the text.

>> How is it possible for a router to know when it is an "end router"?

By static configuration, no more than a very few lines.

>> Is it necessary?

Not every router needs to be an MHTP client. As a matter of fact, small
customers with stub networks should not do anything regarding MHTP and
send untranslated multihomed traffic to their ISP.

>> Can a router act as an end router for some hosts but not others?

There is no specific provision for that, could you give me an example of
why it would be nice to have?

>> It appears every multihomed site must carry the entire (single-homed)
>> DFZ, the same as in current BGP multihoming.  While hopefully the DFZ
>> will be much smaller, is this indeed the case?

This is indeed the case, and will produce signinficant gains if the IPv6
DFZ stays strongly summarized, which is the way it was designed.

>> Is the keepalive mechanism intended to avoid the problem of losing a
>> connection when the single-home connection goes down?

Yes.

>> Since the multi-home to single-home mapping occurs only once

It happens each time traffic to an a prefix is unknown in the
translation table for a specific router and is refreshed periodically.

>> certain kinds of transport failure will kill active sessions (whether
they be TCP or
>> UDP "sessions"), correct?

Depending on the duration of the failure, yes. However, this is
currently the case with BGP, and I expect MHTP to be much more
survivable for open sessions than a BGP reconvergence as it happens
today.

>> Won't the extra traffic be a problem with this?

There is a balance to find between increasing the frequency of
keepalives and the amount of extra traffic caused by active sessions
that died trying to reconnect. Let's say that if the keepalives are set
to twice a second, hardly any session would die, but it will nail the
endpoints.

>> It seems like this protocol won't scale.  I may not understand it
>> fully, but while creating a second routing table with fixed length
>> prefixes is an optimization, it still won't solve the problem when
>> every home on earth wants to multihome, because you'll need millions
>> (or billions!) of entries in the MHTP route table.  I presume that
>> this is what the "rendezvous point" model is intended to deal with,
>> but won't the rendezvous points themselves be overloaded then?

Let's say it will scale better, and you are completely correct here. As
mentionned in the -01, this is part of the design.
The idea is double:
1. Keep the IPv6 DFZ cleanly summarized.
2. Give time to someone to invent the perfect IPv6 multihoming solution.

>> Since this is fundamentally a translation, why not get further
benefit
>> of distribution and do the mapping at the hosts rather than on a
>> router?   The problems with NAT (state in the network) are definately
>> present here, and I don't know if 6.2.[12] fully address this.  For
>> instance, what happens if my router bounces?  What happens if my
>> closest router changes?

In either case the host should see only increased latency for the very
first packets immediatly after the topology change.

Thanks,
Michel.