[manet] Comments on "Problem Statement for OSPF Extensions ..." draft

["Charles E.Perkins" <charliep at iprg.nokia.com>]

Hello folks,

During the recent meeting, the abovementioned draft
was discussed.   The draft has been submitted for a
long time, but after finally reading the draft, and
motivated by the recent WG discussion, I have a few
comments.

- In section 2.1, it is stated that mobility makes
  the use of directional antennas into a pointless
  exercise.  There are numerous studies that conclude
  otherwise.  It seems likely that, given sufficient
  justification, a workable system can be built.
  Whether or not the additional cost is justified
  compared to other expenses is debatable.  Overall,
  however, I would say that "pointless" is far too
  strong an adjective in this sentence.

- In section 2.3, the acronym "VC" is left undefined.

- In section 2.5, the misconception is promulgated
  that receiving takes less power than transmitting.
  While it is typically true per message, the fact is
  that receiving is often more power-consuming
  when the receiver has to be always powered up.
  In contrast, typically the transmitter can be
  powered down during most of the timm.

- In section 2.7, if a node's ability to support new
  neighbors is exhausted, then one can truly say that
  the number of neighbors is numerically limited,
  so that the nodal degree is limited.  Said another
  way, geographic proximity may not result in network
  adjacency.

- In section 2.8, replace "should not thrash" by
  "should avoid thrashing"

- In section 2.9, last paragraph: the suggested
  strategy requires too much binding between a node's
  IPv4 addressability and its IPv6 addressability.
  This issue may not need solution in this document
  anyway.  In fact, I question the need for binding
  even separate network interfaces to the same nodal
  identifier, but again that is a separate issue.

- Section 2.10 gets to the heart of a crucial
  problem.  I would suggest that it be taken as
  a requirement to outfit the OSPF implementations
  so that unreliable flooding is acceptable,
  otherwise I just don't believe the solution
  will be scalable.

I have other minor editorial improvements to
suggest which don't really need to be brought
out here; if the authors are interested, I will
be happy to send them.

Regards,
Charlie P.

_______________________________________________
manet mailing list
manet@ietf.org
https://www1.ietf.org/mailman/listinfo/manet