draft-ietf-manet-tbrpf-10.txt

[Randy Bush <randy@psg.com>]

[ i saved this for last, and probably will not finish.  as i could
  be off base here, maybe i won't go too deeply ]

is there a formal proof that the partial updates provide sufficient
data to always compute a shortest path?  given

   Each node also has the option to report addition topology
   information (up to the full topology), to provide improved
   robustness in highly mobile networks.

and, if not, then what is actually known about correctness,
convergence, etc.?  i am especially concerned by comments such as

   The number of nodes that can be supported depends on several factors,
   including the data rate, the rate of topology changes, and the
   network density (average number of neighbors). Simulations have shown
   that TBRPF can support 250 nodes in mobile networks using IEEE 802.11
   with a data rate of 2 Mbps.

i.e., did the hello/routing exchange eat the whole 2mb?

---

   router ID
      Each node is identified by a unique 32-bit router ID (RID),
      which for IPv4 is equal to the IP address of one of its
      interfaces. The term "node u" denotes the node whose RID is
      equal to u.

so, in v4 is is mandatory that it is an ip address of an
interface, but in v6 it is arbitrary?  why perpetuate the bgp
routerid confusion?

and, given that the definition of 'interface' precludes virtual
interfaces, commonly known today as 'loopbacks', in v4 one can not
use common ops practice, and in v6 things become muddy.

---

it would be useful to compare the link state hello here, TND, with
the ward-katz work.  the latter would seem to have benefits from a
number of viewpoints, and has room for the 1-hop state payload.

---

maybe i am confused, but in 

   We note that, in wireless networks, it is possible for a single
   interface I to receive packets from multiple interfaces J associated
   with the same neighbor node. This could happen, for example, if the
   neighbor uses a directional antenna with different interfaces
   representing different beams. For this reason, TBRPF includes
   neighbor interface addresses in HELLO messages, unlike OSPF, which
   includes only router IDs in HELLO packets.

should it not be s/TBRPF/TND/ ?

perhaps my confusion stems from TNRPF having two meanings, the
overall scheme and the routing module?

---

   In the following overview of the operation of TND, we assume that
   interface I belongs to node i, and interface J belongs to node j.
   When a node i changes the status of a link (I,J), it includes the
   neighbor interface address J in the appropriate list (NEIGHBOR
   REQUEST/REPLY/LOST) in at most NBR_HOLD_COUNT (typically 3)
   consecutive HELLOs sent on interface I. This ensures that node j will
   either receive one of these HELLOs on interface J, or will miss
   NBR_HOLD_COUNT HELLOs and thus declare the link (J,I) to be LOST.
  
yes, the notiation defined for bi-dir links seems to be unordered,
but would it not be clearer if that last (J,I) was (I,J)?

---