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

[Shane Kerr <shane@ripe.net>]

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