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

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

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.