The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4
draft-ietf-manet-dsr-10

[Ballot comment]
I decided to change my DISCUSS to ABSTAIN. I don't understand why the authors
have been unresponsive but since it's over a year, let's be done with it, since
it's Experimental anyway.

This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore, the text states that "... and operation of DSR with IPv6 [7], are covered in other documents." [7] is only a reference to the basic IPv6 spec. I'd expect to see at least a "work in progress" reference to substantive work on DSR for IPv6, if the quoted statement is correct.

[Ballot comment]
I decided to change my DISCUSS to ABSTAIN. I don't understand why the authors
have been unresponsive but since it's over a year, let's be done with it, since
it's Experimental anyway.

This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore, the text states that "... and operation of DSR with IPv6 [7], are covered in other documents." [7] is only a reference to the basic IPv6 spec. I'd expect to see at least a "work in progress" reference to substantive work on DSR for IPv6, if the quoted statement is correct.

Subject: RE: Proposed RFC Editor Note for draft-ietf-manet-dsr
Date: Tue, Apr 25 12:40:22
To: dmaltz@microsoft.com
Cc: dbj@cs.rice.edu yihchun@cs.cmu.edu macker@itd.nrl.navy.mil idc@cs.ucsb.edu

>> OLD (near the end of section 1, change "are" to "will be"):
>> NEW:
>>
>>    Advanced, optional features, such as Quality of Service
>> (QoS) support
>>    and efficient multicast routing, and operation of DSR with
>> IPv6 [7],
>>    will be covered in other documents.
>
>This seems like a strange fix.  There are already other documents
>describing these features: academic papers and internet-drafts.  They're
>not RFCs, granted, but they do exist.  Would a better fix be to include
>citations to those other documents?  I'll grant you that those docs
>might be considered "informative" rather than "normative".

If you'd rather do it this way, please supply the references and the
text for the document, preferably in the RFC-Editor's OLD:/NEW: style.
The original request was for references to them, and Dave had suggested
just changing the wording so it didn't sound like a reference was needed.

  Bill

I put the proposed RFC Editor note in the writeup; just have to get buy-in from the authors

Subject: Proposed RFC Editor Note for draft-ietf-manet-dsr
Date: Wed, Jan 11 08:46:07
To: dbj@cs.rice.edu,dmaltz@cs.cmu.edu,yihchun@cs.cmu.edu
Cc: macker@itd.nrl.navy.mil,idc@cs.ucsb.edu

[Ballot discuss]
There are at least three technical issue that I have with the DSR document:

(1) It invents a new source routing header, instead of using the one that we already have.
(2) It makes several statements that I think are technically incorrect regarding 802.11 networks.  Has it been reviewed by Bernard Aboba and/or any IEEE contacts?
(3) It makes statements about behavior of the IP and ARP protocols that I am not sure reflect existing standards/implementation.  I think you might have to build a custom IP/ARP implementation to implement manet/-dsr which seems odd for something that refers to itself as a routing protocol.

If necessary, I can produce a specific list of the sections that I am concerned about, but it won't be a short list.  Perhaps a better approach would be to add an IESG note explaining why it is being published and stating that parts of this protocol are not consistent with the Internet architecture or existing IETF protocols, and that we don't recommend deployment?  What do you think?

[Ballot discuss]
This document was on an IESG telechat while I was on vacation, and I am just reviewing it now in an effort to educate myself about the proposed AUTOCONF WG.

I am about 1/2 way through reviewing the draft and, unfortunately, I have found some issues with this draft that may be substantive and should be discussed before it is published.  I also think that this draft is significant enough that I'd like to get it reviewed by some other Internet area experts.

I apologize for this non-specific discuss, and I will attempt to complete my review and summarize the significant issues as soon as possible.

[Ballot discuss]
Not sure if this covered so:

What did we do for AODV and OLSR?  we should go with the Experimental
protocol number policy as the rule now.  See IANA Considerations.  Clearly assign
this one to 253 or 254.

IANA Comments:
10. IANA Considerations
Upon approval of this document the IANA will assign a signle IP protocol number from the following registry:


Does the IANA need to do anything with the "No Next Header"?  Possibly change the reference?  In which registry can this be found?

We understand that new DSR options (for use in the DSR Options header) and additional new DSR options are defined in this document.
The IANA Considerations section could be a little more clear on the request for assignments. 

An expert will also need to be named.

[Ballot comment]
We assume that a node receiving a corrupted packet can
  detect the error and discard the packet.

Is this "receipt" as in end-point receipt, or nodes along the route
receiving then discarding the packet?  I am assuming that
"end-point receipt" is meant here--if not, some clarification
may be in order.

Comments below do not anticipate any change in the document.

Since the document is going for experimental, it might be useful
to examine at what rate routes "overheard" are used.
Depending on the rate of change and the available resources,
it seems like it may be optimal in some circumstances to avoid
learning overheard routes. 

I think it would also be valuable to test the routes used in
"Salvaged" packets against the case in which the node
originating the packet also had multiple routes to see if
a pattern emerges in which salvaged packets had
significantly better or worse routes than the alternate
routes available at the origin.

[Ballot discuss]
The document says that the IPv4 address is assigned by any means,
  including DHCP.  Is there any work on the use of DHCP in an ad hoc
  network?  DHCP implies an administrator, and ad hoc networks do not
  necessarily have administrators.

[Ballot discuss]
This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore, the text states that "... and operation of DSR with IPv6 [7], are covered in other documents." [7] is only a reference to the basic IPv6 spec. I'd expect to see at least a "work in progress" reference to substantive work on DSR for IPv6, if the quoted statement is correct.

[Ballot discuss]
This draft applies to IPv4 only. The title should say that by adding "using IPv4" to the end, or something like that. Furthermore, the text states that "... and operation of DSR with IPv6 [7], are covered in other documents." [7] is only a reference to the basic IPv6 spec. I'd expect to see at least a "work in progress" reference to substantive work on DSR for IPv6, if the quoted statement is correct.

Note: this is one of the four MANET protocols that's being publishes as experimental as part of moving forward with a standards-track protocol.  This took longer in AD review than the others (mostly my fault); meanwhile the others have been published as RFCs 3561, 3626, and 3684.

I've reviewed the changes, and I'm happy with the result, except
that since it's going for Experimental I think the IP Protocol
number usage should be as described in RFC 3692 -- basically,
it must be configurable by the deployer, but values 253 and 254
have been reserved for experiments using IP protocols.

If you feel that you can't use this process, it is possible
to assign an IP protocol number via IESG Approval (see
RFC 2780 section 4.3 for the requirements); I would expect
a fair amount of justification will be requested since the
RFC 3692 process was created for exactly this reason.

My odd comments about the I-D update were because of a synchronization problem - the system told me a new I-D was available so I looked at the latest version that I had, which ended up being -09; I didn't notice that the system had sent the notification before the actual new I-D was available.  I will review the changes.

This new version updates the submission date from 24 Feb 2003 to 15 April 2003, and the expiration date from 24 August 2003 to 15 October 2003, and nothing else.  Given that it appeared in July 2004, I am vaguely mystified as to the point of submitting a new version, especially with such odd dates.

To: dbj@cs.rice.edu dmaltz@cs.cmu.edu yihchun@cs.cmu.edu
Subject: Initial AD-review comments on DSR
Cc: zinin@psg.com corson@flarion.com macker@itd.nrl.navy.mil fenner@research.att.com
Date: Tue, 18 Nov 2003 09:53:04 -0800

Folks,

  Below are my initial AD-review comments on DSR, mostly phrased
as questions.  As I mentioned to David in Minneapolis, I've been
avoiding sending them because I am concerned that some of them are
stupid questions and I was hoping that I could clear them up by
further reading of the spec.  However, as David pointed out, you
could help me understand what I got wrong and it's ridiculous to
have gone so many months without any feedback.  I apologize for
taking so long to get these comments back to you.

  Bill


How does IP->MAC resolution work?  Seems as though some of it could
be piggybacked on the route discovery, but there's no mention of this.
Does it do ARP?

In section 3.1, the timers are kind of underspecified; "..has recently
seen..", "..for some timeout period", "MUST limit the rate" - unclear
if this is further specified somewhere else.

In 3.3.4, I don't know if it's clear what to put in the TTL field
for "no hop limit".

In 3.4.1, I don't understand why TTL isn't enough to prevent a
salvaging loop and the salvage counter is required.

In 3.5.1, what's the TTL used for in the flow table?

In 3.5.6, what's the expected hop count?

In 3.5.7, what's an adjusted TTL?

Section 8.2.3 doesn't refer back to section 3.3.3 so it's not clear
exactly how the implosion-prevention delay fits in here.  Strictly
implementiong from 8.2.3 doesn't seem to include the random delay
so I'm concerned that the implosion prevention would get missed
since it's so long ago.  In particular, even though I read linearly
through the spec, when I got to 8.2.3 I wrote down a note about
multiple nodes decapsulating the same packet in a dense network,
even though this would be prevented if the delay in section 3.3.3
was inserted in the right place in the algorithm in 8.2.3 .  This
is a symptom of what I felt was a common theme in the spec - a feature
was introduced and described in a standalone section but not propagated
through the rest of the spec.

Another example of this latter concern is section 8.4.  It describes
when to insert the special addresses 127.0.0.1 and 127.0.0.2 into the
route, but there is no mention of what to do when processing a route
that contains these special addresses, even though the presence of
these special addresses should change which of the categories laid out
at the beginning of section 3.3.1 the caching node should consider for
this route.

Section 8.5 should be more clear about fragmentation and encapsulation,
e.g. specifying the size of the fragments (outgoing MTU minus ip-ip header
and DSR options header length?) and the source/destination addresses to
use in the outer packet.  A reference to RFC 2003 might also help?

For IP protocol number assignments:
1. Can you handle only having one, since you can tell the
flow state and options headers apart with the F bit?
2. Can you use the mechanisms described in
draft-narten-iana-experimental-allocations-04.txt ?

The IANA considerations section needs to specify a policy for
DSR options assignments (i.e., how does IANA decide whether or not
to grant a request for a new DSR option?).  See RFC 2434 for some
possibilities.


I'm afraid that I skipped over some of my questions on the flow state
extension and on packet salvaging because I don't understand them
well enough to formulate the question.  I will try to reread the document
to further my understanding.

State Changes to Pre AD Evaluation                                from Reading List                                      by IESG Member