Subject: Re: [Gen-art] Gen-ART review ofdraft-ietf-ospf-manet-mdr-04.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 9 Jan 2009 10:08:15 -0600

Just for completeness, version 04 addresses all of my comments from 03. 
Ready for publication as Experimental.

Thanks,

Spencer

>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.)
>
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art