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

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

I split the thread into two parts, technical and political.
Also, if the WG thinks this is annoying and Pekka and I should discuss
the matter privately, please say so.

Technical:
----------

Pekka Savola wrote:

>> Well, basically you'd have to analyze all the possible packets
>> routers between two MHTP points could send.  For some of these
>> there might have to be payload address translation.  You might
>> not always know the format of the data there (though, e.g. for
>> ICMP, this should be rather straightforward ... but what if
>> you're using e.g. additional headers (e.g. routing) where more
>> are stored, ...).

For most packets, instead of translating something inside the payload,
it would be a lot simpler to translate the header back to the way it was
when it was sent and MHTP takes care of that.

Let's say a TCP packet expires its TTL. It does not make much of a
difference if the router sends the "time expired" ICMP message to the
multihomed or the corresponding singlehomed source address, either one
would reach the host.

Could you bring up a specific situation where a router in the middle
would have to inspect/translate the payload?

>> Of end-to-end traffic, yes.  But as noted, ICMP and friends
>> are not necessarily end-to-end, rather end-to-some_router

or "some_router-to-end" as well


>> (if one assumes that ICMP generated by a MHTP router should be
>> transmitted and translated all the way back to the originating node)

This is the way it works now. The host that sent the traffic is the one
that gets back the "Time expired" or "unreachable".

>> If there is more interest in this, I think it might be useful to
briefly
>> study the tunneling mechanism too.  That is viewed generally as a
more
>> acceptable approach, and it's (mis)features have been more widely
>> experienced already.

My original design was based on tunnels; I detailed in the draft why I
moved to NAT. Back to the ICMP TTL expired scenario, a tunnelled
solution would not notify the host that originally sent the offending
traffic but the router that tunnelled it (unless the router specifically
decapsulates the tunnel, a lot of work).


Political:
----------

>> there might be some similar "evilness".

There will be. Most network protocols have experienced some "evilness"
during their development.


>> But one you're proposing makes fundamental changes to the
>> way people regard IP routing

I would not qualify MHTP as "fundamental" as related to IP routing. BGP4
could be optimized for MHTP but does not need to be modified and will
still be the one that routes packets over the cloud.


>> (one might consider it as a kind of lightweight "MPLS over IP"
>> I suppose), and it may not be thought as a "clean enough"
>> contingency plan.

I am not sure such a comparison could be made. There is a similarity in
the sense that the path taken by the traffic is going to be altered at
the edge, but MHTP does not add a label to the data. My reading of MPLS
is that it is mostly about VPNs and QOS. Packets translated by MHTP have
nothing special and could be labelled by MPLS.


>> I'm pretty certain some contingency plans will be made,
>> whether sanctioned by IETF/IESG or not; this is a tough problem
>> and can't be solved overnight.

Candid question:
Does this workgroup generally think that a contingency plan is a good
idea,
and should it be sanctionned by the IETF/IESG ?

Michel.