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

From: Shane Kerr <[email-masked]>
Date: Mon, 13 Aug 2001 17:34:48 +0200

Nit-picks:

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

Basic Questions:

- How is it possible for a router to know when it is an "end router"?
  Is it necessary?  Can a router act as an end router for some hosts but
  not others?

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

- Is the keepalive mechanism intended to avoid the problem of losing a
  connection when the single-home connection goes down?  Since the
  multi-home to single-home mapping occurs only once, certain kinds of
  transport failure will kill active sessions (whether they be TCP or
  UDP "sessions"), correct?  Won't the extra traffic be a problem with
  this?

Fundamental Questions:

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

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

-- 
Shane

---

From: "Michel Py" <[email-masked]>
Date: Tue, 14 Aug 2001 13:43:11 -0700

Pekka,

Thank you for your contribution.

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

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

A separate prefix for multihomed sites would be a good step to matter
what. MHTP goes one step further by moving that separate prefix out of
the routers that needs to process large amounts of data to MHTP
rendezvouspoints that are limited proxies.

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

I, for sure, would be interested in reading Dr. Deering's comments.

I am a strong supporter of a strictly aggregated DFZ, and it is one of
MHTP's goals: keep the DFZ strictly aggregated by moving the multihomed
prefixes that do not belong there somewhere else. In the case of a
reserved prefix for multihomed sites, these prefixes would still be in
the DFZ's routing table.

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

I don't see any issues here. If the source prefix is singlehomed, the
TTL failure would naturally go back to the source node. If the source
prefix is multihomed, it will at some point hit an MHTP enabled router.
Thanks for bringing that point, it makes me think that ICMP error
packets might not be subject to proxying limits on MHTP
rendezvouspoints.

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

As far as I know, MHTP is the first protocol that reverses the NAT at
the end and leaves end-to-end traffic unchanged, and that will take care
of most of the NAT-related issues.

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

Agreed, and I think that now is a better time to find out the unforeseen
consequences and not in 5 years when the race over time might have been
lost.

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

You are making my point here. Everyone assumes that a good solution will
be available when we need it. In the meantime, some people are or will
be reluctant to implement IPv6 until a good solution is found. MHTP is
not a good solution for IPv6 
multihoming, but I think it is a good contingency plan. What is wrong in
developping a contingency plan before it is needed? 

Michel.