Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Dec 2008 11:33:22 -0600

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

---

From: Richard Ogier <[email-masked]>
Date: Sun, 28 Dec 2008 14:59:40 -0800

Hi Spencer,

I have updated the draft to address all of your comments.
http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-04.txt

Answers to your questions are given below.

Thanks,
Richard

Spencer Dawkins wrote:

> 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
>
> hoped) .

Richard:  To clarify the meaning of the parameter 2HopRefresh, I 
modified the text
in Section 2.6 (overview) to be similar to the corresponding text in 
Section 4.1.

> nodes mentioned in the next paragraph?

Richard:  No.  To give an idea of what "large" means here, I added
"(e.g., greater than 50)" after the word "large".

> parameter? If so, that's fine, but the chosen values made me wonder about

Richard:  I added text specifying that MDRConstraint can be any integer
greater than or equal to 2.

> Spencer (clarity): it would be good to point to the definitions in 
> this section.

Richard:  Done.

> Spencer: "to be specified"? Is this the L bit described in A.1?

Richard:  Yes.  I modified the text to indicate this.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Dec 2008 09:37:58 -0600

Hi, Richard,

These changes address all my comments - best wishes with your draft.

Happy New Year,

Spencer

----- Original Message ----- 
From: "Richard Ogier" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: <[email-masked]>; "General Area Review Team" 
<[email-masked]>; "Acee Lindem" <[email-masked]>; "Abhay Roy" 
<[email-masked]>
Sent: Sunday, December 28, 2008 4:59 PM
Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt

> Richard:  To clarify the meaning of the parameter 2HopRefresh, I modified 
> the text