I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve
these comments along with any other Last Call comments you may receive.
Document: draft-ietf-ospf-manet-mdr-03.txt
Reviewer: Spencer Dawkins
Review Date: 2008-12-12
IETF LC End Date: 2008-12-24
IESG Telechat date: (not known)
Summary: This draft is on the right track for publication as Experimental. I
have a small number of questions, listed below.
Comments:
2.6. Hello Protocol
Differential Hellos are sent every HelloInterval seconds, except when
full Hellos are sent, which happens once every 2HopRefresh Hellos.
Spencer (clarity): Is 2HopRefresh a counter? As I continue reading, it seems
to be treated as a counter, but that wasn't clear to me at this point in the
document (I think I caught up in Section 4.1, but that's later than I'd
hoped)
The default value of 2HopRefresh is 1, i.e., the default is to send
only full Hellos. The default value for HelloInterval is 2 seconds.
Differential Hellos are used to reduce overhead and to allow Hellos
to be sent more frequently, for faster reaction to topology changes.
3.2. New Configurable Interface Parameters
All possible configurations of the new interface parameters are
functional, except that if AdjConnectivity is 0 (full-topology
adjacencies), then LSAFullness must be 1, 2, or 4 (see Section 9.3).
Differential Hellos should be used to reduce the size of Hello
packets when the average number of neighbors is large. Differential
Spencer (clarity): does "large" have any relationship with "160" or "200"
nodes mentioned in the next paragraph?
Hellos are obtained by setting the parameter 2HopRefresh to an
integer greater than 1, with the recommended value being 3. Good
performance in simulated mobile networks with up to 160 nodes has
been obtained using the default configuration with differential
Hellos. Good performance in simulated mobile networks with up to 200
nodes has been obtained using the same configuration except with
minimal LSAs (LSAFullness = 0). Simulation results are presented in
Appendix E.
MDRConstraint
A parameter of the MDR selection algorithm, which affects the
number of MDRs selected. The default value of 3 results in nearly
the minimum number of MDRs. The optional value 2 results in a
larger number of MDRs.
Spencer(clarity): are "3" and "2" the only possible values for this
parameter? If so, that's fine, but the chosen values made me wonder about
other possible values...
12. IANA Considerations
This document defines three new LLS TLV types to be allocated by
IANA: MDR-Hello TLV, MDR-Metric TLV, and MDR-DD TLV.
Spencer (clarity): it would be good to point to the definitions in this
section.
D. Non-Ackable LSAs for Periodic Flooding
In a highly mobile network, it is possible that a router almost
always originates a new router-LSA every MinLSInterval seconds. In
this case, it should not be necessary to send Acks for such an LSA,
or to retransmit such an LSA as a unicast, or to describe such an LSA
in a DD packet. In this case, the originator of an LSA MAY indicate
that the router-LSA is "non-ackable" by setting a bit (to be
specified) in the options field of the LSA. For example, a router
Spencer: "to be specified"? Is this the L bit described in A.1?
can originate non-ackable LSAs if it determines (e.g., based on an
exponential moving average) that a new LSA is originated every
MinLSInterval seconds at least 90 percent of the time. (Simulations
can be used to determine the best threshold.)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf