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

From: "Michel Py" <[email-masked]>
Date: Mon, 13 Aug 2001 11:22:26 -0700

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.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Aug 2001 20:21:10 +0300 (EEST)

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

Isn't this what we wanted to avoid with IPv6? :-)  I believe Steve Deering
would be tearing his hair by now :-)

Does this work properly if a router between to MHTP points notices hop
count has reached zero, and emits ICMP TTL expired to the source?  (if the
TTL failure is delivered to the end node properly, the headers in ICMP
payload would have to be translated too.

ICMP by intermediate nodes is not the only issue with NAT techniques like
this.  I fear this might have unforeseen consequences.

I'm also a bit unsure whether this just moves the multihoming problem to a
separate table, where it would be contained until some new mechanisms are
developed.  Some improvements are naturally made, but I fear the all the
effects couldn't be properly analyzed and planned beforehand.

I have think _some_ multihoming methods will be developed before the
number of "multihomed prefixes", were there not filtering, would reach
critical bounds (perhaps 5 years, who knows).  If this kind of scenario
("race against time") is sought, perhaps just a separate prefix, allocated
to multihomed sites (and they would also have a primary prefix), would be
sufficient.  The prefix wouldn't be aggregated as strictly.  I believe the
thought has already been mentioned.  This way, "99.5%" or the like would
always be reachable through strictly aggregated DFZ, and people who care
about multihoming could play around with the other prefix until it
"explodes" or better ways are made up.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords