Depth-First Forwarding (DFF) in Unreliable Networks
draft-cardenas-dff-14

All the DISCUSS positions have been addressed and lifted, and no objections to publication were heard on the IESG mailing list.  I'm therefore marking this done.

[Ballot comment]
Very many thanks for the hard work to address my Discuss points.

I hope you will find time/energy to sift through my Comments with your AD and document shepherd to apply any that would improve the document.

---

In his Routing Directorate review, Alvaro Retana asked...

> o Section 4.2 reads (last paragraph): "..if a router receives a
>  Packet with DUP = 1 (and RET = 0) that it has already forwarded,
>  the Packet is not considered looping, and successively forwarded to
>  the next router.."  I'm at a loss of why would the router forward
>  the packet if it is a duplicate of one that it has already
>  forwarded.

Ulrich helpfully responded...

> This is necessary for the following reason:
> Imagine a case where after a lost L2 ACK, DUP of the packet is set to
> 1 and a duplicate is created. The duplicate may now during its path
> again be duplicated if another L2 ACK is lost. However, DUP is already
> set to 1, so there is no way of discerning the duplicate from the
> duplicate of the duplicate. That is not much of a problem, other than
> that loop detection is not possible after the second lost L2 ACK on the
> path of a packet.
> However, if duplicates are simply dropped, it is possible that the
> packet was actually a looping packet (and not a duplicate), and so the
> DFS would be interrupted. The problem is to make sure that this "very
> instance" of a packet has passed a router before or not (sequence
> number is not enough; source route would be enough, but at a too high
> cost).
> In practice, we have not observed that to be a problem in deployments
> of thousands of routers in a network. There are some duplicates of
> packets, but not in a considerable amount.

I think this somewhat subtle point would benefit from a little more
explanation in the document (perhaps just include this text).

Maybe, as well, since this is experimental, it would make a useful point
for further research.

---

Section 3 is very useful in setting the scope of the document. I wonder
whether it would be useful to make some references to examples that are
in scope, and some statements about common network types that are
immediately assumed out of scope. For example:

  o  Assumes that the underlying link layer provides means to detect if
      a Packet has been successfully delivered to the Next Hop or not
      (e.g., by L2 ACK messages).

And we can note that 802.15.4 has provision for immediate acks, but many
layer two technologies do not even have an option for assuring delivery.

---

Isn't there a tension in Section 3 between the problem of network
density as expressed in:

  o  Is designed for networks with little traffic in terms of numbers
      of Packets per second, since each recently forwarded Packet
      increases the state on a router.  The amount of traffic per time
      that is supported by DFF depends on the memory resources of the
      router running DFF, on the density of the network, on the loss
      rate of the channel, and the maximum hop limit for each Packet:
      for each recently seen Packet, a list of Next Hops that the Packet
      has been sent to is stored in memory.  The stored entries can be
      deleted after an expiration time, so that only recently received
      Packets require storage on the router.

And the intension to support dense networks as stated in:

  o  Is designed for dense topologies with multiple paths between each
      source and each destination.

---

In Section 3

      In networks with very stable links (e.g.
      Ethernet)

I think "Ethernet" is too general a term. Many LLNs use a variety of
Ethernet.

---

I agree with other ADs that the mixture of design objectives and
deployment-limiting assumptions in Section 3 is unhelpful. Perhaps
separate them out into two sections and make the assumptions more
definitive as limitations?

---

The term "PAN" is used without expansion.

---

More thoughts on storage requirements and list processing...

Section 4 has:

  For each recently forwarded Packet, a router running DFF stores the
  list of Next Hops to which a Packet has been sent.  Packets are
  identified by a sequence number that is included in the Packet
  Header.  This list of recently forwarded Packets also allows for
  avoiding loops when forwarding a Packet.  Entries of the list
  (identified by a sequence number of a Packet) expire after a given
  expiration timeout, and are removed.

There is a problem with the meaning of "list" and "entry". You have a
list of lists :-)

Do you mean that the Next Hop is dropped from the list, or that the
packet's list of next hops is discarded? Should be easy to clarify the
text.

---

The start of Section 4.1 is abrupt and confusing.

  This specification requires a single set on each router, the
  Processed Set. Moreover, a list of bidirectional neighbors must be
  provided by an external neighborhood discovery mechanism, or may be
  determined from the RIB (e.g., if the RIB provides routes to adjacent
  routers, and if these one-hop routes are verified to be
  bidirectional).  The Processed Set stores the sequence number, the
  Originator Address, the Previous Hop and a list of Next Hops, to
  which the Packet has been sent, for each recently seen Packet.
  Entries in the set are removed after a predefined time-out.  Each
  time a Packet is forwarded to a Next Hop, that Next Hop is added to
  the list of Next Hops of the entry for the Packet.

It takes a while to work out "set of what?" You could rephrase for
clarity.

---

Section 4.1

What is a "bidirectional neighbor"? One might assume that it a neighbor
to and from which data can be passed in a single hop? The text goes on
to talk about "one-hop bidirectional routes".

Is that the moral equivalent to being connected with a bidirectional
link? Probably not in the type of network you are building, so maybe
this term needs to be in the Terminology section.

---

Section 4.2

  DFF requires additional header information in each data Packet by a
  router using this specification.  This information is stored in a
  Packet Header that is specified in this document as LoWPAN header and
  as IPv6 Hop-by-Hop Options extension header respectively, for the
  intended "route-over" and "mesh-under" Modes of Operations. 

1. I think you have "route-over" and "mesh-under" reversed!
2. The first sentence doesn't parse. But also "requires" is unclear.
  I think that the information is needed on a per-packet basis by the
  receiving router, and so it encoded in the packet header.

---

Section 11 has

  A
  smaller list MAY be used, if desired, and the exact selection of the
  size of the candidate Next Hop List is a local decision in each
  router, which does not affect interoperability.

It is true that it does not affect interoperability of the protocol,
but it does affect the ability to deliver data. So it is probable that
some guidance on the "MAY" might be valuable.

---

I am curious to see no discussion of the management of this protocol
or of networks using DFF. I would imagine that since "unexpected"
things may start to happen, diagnostics would be quite useful.

UPDATED Document Writeup

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

      This is a request for an Experimental RFC and this is consistent
      with the type indicated on the title page of the document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies the "Depth-First Forwarding" (DFF) protocol
  for IPv6 networks, a data forwarding mechanism that can increase
  reliability of data delivery in networks with dynamic topology
  and/or lossy links. The protocol operates entirely on the
  forwarding plane, but may interact with the routing plane. DFF
  forwards data packets using a mechanism similar to a "depth-first
  search" for the destination of a packet. The routing plane may be
  informed of failures to deliver a packet or loops. This document
  specifies the DFF mechanism both for IPv6 networks (as specified in
  RFC2460) and in addition also for LoWPAN "mesh-under" networks (as
  specified in RFC4944).

Working Group Summary

  This document was not adopted in a Working Group.

Document Quality

  There are currently two known implementations of the protocol.  One
  is used on top of IEEE 802.11 and the other on top of IEEE
  802.15.4. The authors, through this publication hope to elicit
  further implementation and experimentation with this protocol and
  concept.

  Thomas Clausen and I (Geoff Mulligan) have reviewed nearly every
  draft of this document and provided detailed comments and
  critiques, which have been addressed by the authors.

Personnel

  Document Shepherd: Geoff Mulligan
  Responsible AD: Ted Lemon

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document has been reviewed by experts in mesh networking and by
  other IP networking experts. The list of reviewers is included in
  section 18 of the document and include myself, Jari Arkko, Thomas
  Clausen and others.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  I have no concerns about the depth or breadth of the reviews of
  the document. It has been read and reviewed by a number of people
  both inside and outside the IETF including the Routing Area
  Directorate, Security Directorate, and IP Directorate and has
  completed IETF Last Call.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document has been well reviewed.  It was reviewed by the
  Routing Area Directorate, the Security Directorate, IP Directorate,
  Gen-Art Directorate and was announced on the Manet, ROLL and
  6lowpan WG lists and was presented during the Routing Area Working
  group meeting.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

  I am not uncomfortable with any portions of the document.  My
  previous "concerns" associate with document organization and design
  details were addressed by the authors in previous versions. In
  fact, as soon as time permits I hope to build an implementation of
  the protocol based on this version of the draft.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

  IPR disclosure 1646 was filed that references this document.  The
  IPR holder has agreed to license the IPR under a royalty free
  license.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

  The authors and reviewers of document are experts in the field of
  mesh networking and IP. Other team members from the authors'
  companies have also reviewed drafts of the this document.

  The authors and reviewers are fully supportive of this document and its
  publication. As this is a new concept through publication and then
  further experimentation the group hopes to find broader review,
  implementation, performance and interoperability results.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No. No one has expressed any discontent with the document

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  All ID nits have been address in the most recent version
  of the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  None of these reviews appear to be required

(13) Have all references within this document been identified as
either normative or informative?

  The normative and informative references are split.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are no normative references that are not ready for advancement.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downward normative references.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

  This document will not change the status of any other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  An addition to the 6lowpan Dispatch Type field is requested for the
  DFF header.

  An addition to the IPv6 Destination Options and Hop-by-Hop options
  registry is requested.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new registries are to be created.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

  The document appears to be correct.  Other than ID-nits, none
  appear to be required.

[Ballot discuss]
This is presented as an experimental protocol, and yet the indication in the appendix is that it is being considered for city wide levels of experimentation.

These are much larger scale experiments than we normally consider, and might be considered as full deployments.

I think that there needs to be text up front describing the planned experiments and noting that the IETF has reviewed this in the context of an experimental protocol and not a protocol that it has satisfied itself is ready deployment as a production protocol.

I am also concerned that this end-runs the work and decisions of the ROLL and MANET WGs, and the right way forward may be to put this work through those working groups.

[Ballot discuss]
Thank you for addressing Alvaro Retana's Routing Directorate
review. There is one minor point carried forward in my Comment,
but I have cleared Alvaro's review from my Discuss.

But I have a substantial number of my own concerns. I believe that it
was a fundamental mistake to state or assume that this document did not
need careful review by the Routing Area as it has clear implications for
the behavior of packet routing.

---

This point is placed first as it is not actionable by the document
authors. It is intended for consideration by the sponsoring AD only.

There seem to be a large number of relatively meaty changes to the text
(although not to the protocol) since IETF last call (file went from 85K
to 90k). I don't see that these changes were discussed on the IETF list.
Since this is an IETF consensus document, do we know that the IETF has
consensus support for the changes?

---

Thank you for bringing this work forward as Experimental and holding
off asking for publication on the Standards Track.

I really like that you have put a section about further experimentation
high up in the document. I would also like that section to describe the
experimental environment a bit: how much should this be contained? what
are the risks of running it "on the Internet"? what happens if the
experiment "escapes"?

This last point is quite important because you are not using
experimental code points. While I see you have an "ignore and forward"
code point of IP_DFF, what are the implications of that behavior?

---

Section 1.2

  While this protocol has been widely deployed...

and Appendix B

The implication here is that the protocol is being brought forward in
its current form for "rubber stamping". That is, that the document is
intended to describe a protocol version that has been implemented and
deployed, and then to encourage more experimentation. That is OK, but
normally, in those cases, we publish as "Company X's Foo Protocol"
rather than with the implication of IETF consensus on the protocol
itself.

For example, if I raised an issue that required a change to the protocol
we would have the situation where either the published RFC diverged from
the deployed base (making the text need to be changed) or push-back from
the authors about making the change.

Being branded as "Company X's Foo Protocol" does not stop the document
from being AD Sponsored with IETF consensus, but it means that the
consensus is behind the publication, rather than behind the technical
content. Given the relatively short review that the document got from
the community, this might be more in keeping with reality.

---

Section 2.2
I am uneasy with the use of a direct quote from Wikipedia.
- I have read the Wikipedia license terms and am not sure I
  understand them. Does the IETF copyright license infringe the
  Wikipedia terms?
- Wikipedia calls for attribution and credit to the original
  contributor. Is that supposed to be applied when we make a direct
  quote?
- Is the Wikipedia URL considered a stable reference?
I would prefer to see the authors write their own definition of what
they mean be "Depth-first search".

---

Section 3

As I note in my Comment, this section is very valuable for setting the
scope of the protocol and the associated experiment.  It may seem
obvious to the authors, but it is important that this protocol not be
used in environments that are not within the scope of Section 3. Indeed,
doing so could be extremely damaging to the stability of the network. I
would welcome a clear statement in the Introduction about the care with
which experiments should be conducted and the environment in which they
must not be tried. I don't believe this would detract from the protocol,
but would just make it clear for implementers and deployers.

---

Section 3 contains the assumption

  o  Is designed for networks with little traffic in terms of numbers
      of Packets per second, since each recently forwarded Packet
      increases the state on a router.  The amount of traffic per time
      that is supported by DFF depends on the memory resources of the
      router running DFF, on the density of the network, on the loss
      rate of the channel, and the maximum hop limit for each Packet:
      for each recently seen Packet, a list of Next Hops that the Packet
      has been sent to is stored in memory.  The stored entries can be
      deleted after an expiration time, so that only recently received
      Packets require storage on the router.

You state this as necessary for router state (which is true).  But it
is also necessary if your forwarding model is going to save bandwidth.
Otherwise, forwarding packets as suggested by this protocol is actually
going to cost more bandwidth than the routing protocol reduction saves.

Phrased differently, all of packet processing is about finding the
correct tradeoff between state in the packet and state in the network.
Basically, this is moving a lot of state into the packet, and I worry
about how this will develop over time.

Consider a deployment that meets the assumption. Over time the amount
of traffic grows (as we know is the case in all networks ever deployed).
At some point you will hit a catastrophe! Either the devices can no
longer store the necessary information (I don't immediately find a
description of how the protocol handles not being able to store the
information for a packet it is about to send, but I may have missed it),
or the bandwidth used may climb a bit fast (possibly stressing a low-
capacity link more than expected).

I think the way to handle this is to put in processing for the case
where the amount of traffic (or the network density) increase over a
threshold. The protocol could, for example, apply back-pressure on its
data applications, or it could simply discard packets. And it should
report issues to the operator.

---

While I understand how using L2 "reliable delivery" reduces the need to
provide a certain amount of function in L3, I find the assumption in
Section 3 to be counter-productive. One of the motivations in Section
1.1 is

  More frequent routing protocol updates can mitigate that problem to a
  certain extent, however this requires additional signaling, consuming
  channel and router resources (e.g., when flooding control messages
  through the network).  This is problematic in networks with lossy
  links, where further control traffic exchange can worsen the network
  stability because of collisions.  Moreover, additional control
  traffic exchange may drain energy from battery-driven routers.

This is a very good point. But you seem to address the issue by saying
that some mechanism (like L2 Acks) must be applied. Now, it seems to
this naif reader that sending an Ack for every data packet is an
increase in the traffic that negates the reduction in routing traffic.

Of course, this does cut into the previous point about "little traffic".
Taken to extreme, if there is absolutely no traffic, then there is no
need for routing exchange, and this protocol is ideal.

So, how is the deployer to work out whether the use of this protocol is
a good idea or not? Is this a point for experimentation? Is there more
precise guidance you can give related to specific routing protocols and
traffic demands / network density?

---

Section 4

  This list is
  ordered, first containing Next Hops listed in the RIB, if available,
  ordered in increasing cost, followed by other neighbors provided by
  an external neighborhood discovery.

I believe that you should say whether there is any way of ordering the
externally discovered neighbors, or whether it does not matter.  Should
the order be consistent across each packet (subject to changes in
metrics that may impact the RIB)? A forward pointer to Section 11?

---

Section 4.2 and DUP processing

I have read the exchanges on this topic (see also the Comment, below),
but I continue to have concerns about the way this works:

As discussed, Section 4.2 notes that duplicate (same origin and sequence
number) packets which have the DUP flag set will not be considered
looping.

OK, but suppose that a packet gets the DUP flag set (from having failed
to get an L2 Ack earlier) and then starts looping, it will keep looping
and not be terminated by the loop suppression feature. Am I missing
something about the DUP flag being cleared again?

---

Section 4.2 - more about duplication

The document assumes that if a packet loops on an trial, then you
should stop trying alternatives and return the packet backwards.  In
many easily constructed topologies, this will cause valid paths to be
missed.

---

Section 4.2 contains some scary throw-away text!

  An external mechanism may use this information for increasing
  the route cost of the route to the Destination using the Next Hop
  which resulted in the loop in the RIB.  Alternatively, or in
  addition, the routing protocol may be informed.

This is so casual as to be absolutely dangerous! You don't go any
further into the issues or potential of what is going on here.
(A forward pointer to Section 12 would have helped a bit, but would
only serve to fan the flames!)

Since this is clearly not a fundamental part of the protocol you are
describing, and since you probably don't want to write substantial
text on the risks of metric modification in this way, maybe it would
be best to simply delete this text along with Section 12.

BTW Is "route cost" meant to imply you touch the value in the RIB or
the FIB? Section 12 seems to imply the RIB which is an "interesting"
overlap with the function of the routing protocol! How long is that
update supposed to last? What happens when a packet is successfully
forwarded on that link, should you decrease the cost again? And how
would you know you had increased it? What happens when there is a
routing update? Should the new cost value get flooded by the routing
protocol?

I really think you would be well-advised to cut out this piece of
speculative work.

---

As a general thought, this is effectively an "all routes explore"
protocol. It is fairly easy to see that in many fairly dense topologies
the hop limit will be exhausted before the right path is found.  And you
do state that it is the intention that this protocol works for dense
topologies.

I do note that Section 3 states that "Certain topologies are less
suitable" and that this includes "topologies where the 'detour' that a
Packet makes during the depth-first search in order to reach the
destination would be too long."

Because of this contradiction, I think you need to quantify the issue
rather than skating over it.  What sort of topology makes the DFF too
long?  How dense is too dense?

By the way, the argument that using the installed route will likely work
and so we won't actually explore all routes cannot be used because if
the installed route was correct, we would not need this protocol.

---

Section 5 has

  DFF MAY use information from the Routing Information Base (RIB),
  specifically for determining an order of preference for to which next
  hops a packet should be forwarded (e.g., the packet may be forwarded
  first to neighbors that are listed in the RIB as next hops to the
  destination, preferring those with the lowest route cost).

But Section 4 already said


  This list is
  ordered, first containing Next Hops listed in the RIB, if available,
  ordered in increasing cost, followed by other neighbors provided by
  an external neighborhood discovery.

And to confuse things, Section 11 seems to contain the definitive rules
and only uses RECOMMENDED.

Which is right?

---

Section 6.2

  The Processed Set SHOULD be stored in non-
  volatile memory and restored after a reboot of the router.

You need to separate the function you want to see from the way it is
implemented. But, anyway, why is this a "SHOULD"? Are there good reasons
why an implementation might decide to not restore the Set, and what
would be the consequences?

But let's look at two implications here:

1. The use of non-volatile memory is clearly a gate on throughput.
2. Do you store the information before you send the packet, or send the
  packet before you store the information? One way or the other you
  create a restart window that you need to address in the document.

---

Route-over issues

For route-over operation with a source in the DFF domain and a
destination outside the domain this protocol explicitly assumes that
the source S knows the address of the correct exit router R (Section
15).  That may be reasonable in the 6lowpan case, but it is not
reasonable in the generalized case.  How can you solve the selection
of exit routers?

For route-over, the figure 7 case, using a low capacity network as
transit for connecting external IPv6 nets is simply a BAD idea. 
Whether the required ability for the ingress router to know the
identity of the egress router can be mete depends upon the
properties of the routing protocol.  (For example, RIPv3 will never
tell you this.) This needs far more clarity in terms of a warning to
not do it, but ideally it would have a preventative mechanism built
into the protocol. [Hint: being a bad idea means "it will kill your
network and cause unpredictable effects in the connected networks."
Why not simply remove all discussion of transit networks? Or, better
yet, recommend against it.]

---

Section 7

  Version (VER)  - This 2-bit value indicates the version of DFF that
      is used.  This specification defines value 00.  Packets with other
      values of the version MUST be ignored by this specification.

1. The specification doesn't do active things and so cannot ignore
  packets. Do you mean "...ignored by implementations of this
  specification"?

2. What does it mean to ignore a packet? Drop it? That sounds like
  migrating from one version of DFF to another will not work well.

---

Section 7 - Sequence number re-use

  Sequence Number  - A 16-bit field, containing an unsigned integer
      sequence number generated by the Originator, unique to each router
      for each Packet to which the DFF has been added, as specified in
      Section 13.  The Originator Address concatenated with the sequence
      number represents an identifier of previously seen data Packets.

That means that the sequence number seen in the network is a function
of the total number of packets using DFF sent by the originator. That
is, it is not a function of the number of packets in a flow.

Are you sure that 2^16 is large enough to prevent re-use of an
identifier? Don't you need to make the identifier {src, dst, seqno}?

---

Section 10

  Whenever Section 9 explicitly
  requests it in case of such a delivery failure, the following steps
  MUST be executed:

It seems to me that whenever failure is mentioned in Section 9 there is
always a requirement that Section 10 is executed. So what does this
sentence mean?

---

I think that Section 15 is adding more assumptions to Section 3. Can you
at a minimum put a forward-pointer in Section 3? (Yes, I see one already
exists, but it says "is optimized for" while Section 15 says "MUST be
limited".) What I would really like is for you to pull the scope limits
from Section 15 and place them in Section 3.

---

The Security considerations will, no doubt, attract attention from the
Security ADs. Possibly the concern for security in this protocol can be
reduced by the fact that it is an experimental protocol, but in that
case we probably need a Section 3 assumption that "there is no need for
strong security in the network".

With the weakness of the looping issues (mentioned above), the potential
for inducing additional returning, and the dependence on attackable
acknowledgment mechanisms, this protocol seems likely to be extremely
vulnerable. 

Perhaps the assumption that one can use link layer security in low power
and lossy networks will get approval from the Security ADs (in which
case you will have done the ROLL WG a huge favour :-)

---

Are originators single-homed?

Their seems to be an assumption in several places in the document that a
originator will always have only one next-hop for a packet.  There is no
reason for the assumption, and dropping the packet upon first return to
the originator will result in missing paths. Indeed, the preamble in
Section 4 clearly assumes that the source will have a list of next hops,
but then goes on to say:

  If the Packet is eventually returned to the Originator of the Packet,
  it is dropped.

If I am reading this right it is no big deal. It is not a big change to
fix the issue and allow all next hops to be tried.

Or perhaps "Originator of the Packet" is a host? Does that mean that you
intend hosts to also participate in the DFF protocol? Hmmm, reading
further this looks to be the case. So this mechanism is not just about
forwarding, but requires full participation by end systems. That really
isn't clear from the Abstract and Introduction.

Actually, it is probably a little more complicated! In some senses, the
originator will be the first node in the DFF domain. That is, when
traffic originates outside the LLN, you will not expect the nodes out
there to use DFF, so it will be the responsibility of the gateway.

Section 9.1 tries to get into this by talking about "entry into a
routing domain in which DFF is used". But it fails to clarify what
"originator" means in that context.

And this *very* messily clashes with the use of sequence number per
"originator". If originator is the source address of the packet (and
I can't see how it could be anything else unless you do address
swapping or encapsulation) and if the originator is not required to
generate the sequence number itself (and I don't think remote hosts are
expected to know about DFF) then if an originator is dual-homed into
the routing domain, you will have two routers generating sequence
numbers from the same base. I.e. you will have duplicate identifiers
for packets == disaster.

I hesitate to say this is a show-stopper, but it requires a very
significant constraint to the usability of DFF that must be clearly
documented. And possibly all that is needed is:
- a clear definition of originator
- a statement about tunneling over or into DFF domains *much* earlier
  in the document

Ah, finally I found Section 13 that explains some of this. Can you
please bring the definitions forward in the text?

[Ballot comment]
In his Routing Directorate review, Alvaro Retana asked...

> o Section 4.2 reads (last paragraph): "..if a router receives a
>  Packet with DUP = 1 (and RET = 0) that it has already forwarded,
>  the Packet is not considered looping, and successively forwarded to
>  the next router.."  I'm at a loss of why would the router forward
>  the packet if it is a duplicate of one that it has already
>  forwarded.

Ulrich helpfully responded...

> This is necessary for the following reason:
> Imagine a case where after a lost L2 ACK, DUP of the packet is set to
> 1 and a duplicate is created. The duplicate may now during its path
> again be duplicated if another L2 ACK is lost. However, DUP is already
> set to 1, so there is no way of discerning the duplicate from the
> duplicate of the duplicate. That is not much of a problem, other than
> that loop detection is not possible after the second lost L2 ACK on the
> path of a packet.
> However, if duplicates are simply dropped, it is possible that the
> packet was actually a looping packet (and not a duplicate), and so the
> DFS would be interrupted. The problem is to make sure that this "very
> instance" of a packet has passed a router before or not (sequence
> number is not enough; source route would be enough, but at a too high
> cost).
> In practice, we have not observed that to be a problem in deployments
> of thousands of routers in a network. There are some duplicates of
> packets, but not in a considerable amount.

I think this somewhat subtle point would benefit from a little more
explanation in the document (perhaps just include this text).

Maybe, as well, since this is experimental, it would make a useful point
for further research.

---

Section 3 is very useful in setting the scope of the document. I wonder
whether it would be useful to make some references to examples that are
in scope, and some statements about common network types that are
immediately assumed out of scope. For example:

  o  Assumes that the underlying link layer provides means to detect if
      a Packet has been successfully delivered to the Next Hop or not
      (e.g., by L2 ACK messages).

And we can note that 802.15.4 has provision for immediate acks, but many
layer two technologies do not even have an option for assuring delivery.

---

Isn't there a tension in Section 3 between the problem of network
density as expressed in:

  o  Is designed for networks with little traffic in terms of numbers
      of Packets per second, since each recently forwarded Packet
      increases the state on a router.  The amount of traffic per time
      that is supported by DFF depends on the memory resources of the
      router running DFF, on the density of the network, on the loss
      rate of the channel, and the maximum hop limit for each Packet:
      for each recently seen Packet, a list of Next Hops that the Packet
      has been sent to is stored in memory.  The stored entries can be
      deleted after an expiration time, so that only recently received
      Packets require storage on the router.

And the intension to support dense networks as stated in:

  o  Is designed for dense topologies with multiple paths between each
      source and each destination.

---

In Section 3

      In networks with very stable links (e.g.
      Ethernet)

I think "Ethernet" is too general a term. Many LLNs use a variety of
Ethernet.

---

I agree with other ADs that the mixture of design objectives and
deployment-limiting assumptions in Section 3 is unhelpful. Perhaps
separate them out into two sections and make the assumptions more
definitive as limitations?

---

The term "PAN" is used without expansion.

---

More thoughts on storage requirements and list processing...

Section 4 has:

  For each recently forwarded Packet, a router running DFF stores the
  list of Next Hops to which a Packet has been sent.  Packets are
  identified by a sequence number that is included in the Packet
  Header.  This list of recently forwarded Packets also allows for
  avoiding loops when forwarding a Packet.  Entries of the list
  (identified by a sequence number of a Packet) expire after a given
  expiration timeout, and are removed.

There is a problem with the meaning of "list" and "entry". You have a
list of lists :-)

Do you mean that the Next Hop is dropped from the list, or that the
packet's list of next hops is discarded? Should be easy to clarify the
text.

---

The start of Section 4.1 is abrupt and confusing.

  This specification requires a single set on each router, the
  Processed Set. Moreover, a list of bidirectional neighbors must be
  provided by an external neighborhood discovery mechanism, or may be
  determined from the RIB (e.g., if the RIB provides routes to adjacent
  routers, and if these one-hop routes are verified to be
  bidirectional).  The Processed Set stores the sequence number, the
  Originator Address, the Previous Hop and a list of Next Hops, to
  which the Packet has been sent, for each recently seen Packet.
  Entries in the set are removed after a predefined time-out.  Each
  time a Packet is forwarded to a Next Hop, that Next Hop is added to
  the list of Next Hops of the entry for the Packet.

It takes a while to work out "set of what?" You could rephrase for
clarity.

---

Section 4.1

What is a "bidirectional neighbor"? One might assume that it a neighbor
to and from which data can be passed in a single hop? The text goes on
to talk about "one-hop bidirectional routes".

Is that the moral equivalent to being connected with a bidirectional
link? Probably not in the type of network you are building, so maybe
this term needs to be in the Terminology section.

---

Section 4.2

  DFF requires additional header information in each data Packet by a
  router using this specification.  This information is stored in a
  Packet Header that is specified in this document as LoWPAN header and
  as IPv6 Hop-by-Hop Options extension header respectively, for the
  intended "route-over" and "mesh-under" Modes of Operations. 

1. I think you have "route-over" and "mesh-under" reversed!
2. The first sentence doesn't parse. But also "requires" is unclear.
  I think that the information is needed on a per-packet basis by the
  receiving router, and so it encoded in the packet header.

---

Section 11 has

  A
  smaller list MAY be used, if desired, and the exact selection of the
  size of the candidate Next Hop List is a local decision in each
  router, which does not affect interoperability.

It is true that it does not affect interoperability of the protocol,
but it does affect the ability to deliver data. So it is probable that
some guidance on the "MAY" might be valuable.

---

I am curious to see no discussion of the management of this protocol
or of networks using DFF. I would imagine that since "unexpected"
things may start to happen, diagnostics would be quite useful.

[Ballot comment]
Oops, sorry for not entering a ballot sooner.  I did a very thorough IPdir review of this draft for Ralph; when it didn't get finished before he passed the baton to me, I happily agreed to take over sponsorship of the draft—I think it's very interesting and useful work.

Ulrich is working on addressing Martin's DISCUSS.  The short answer is that the packets sent on these networks typically come nowhere near the MTU size, so this hasn't been an issue.  But Ulrich agrees that this is a concern and would like to have a better answer than that in the draft.

Regarding Dan's comment, he asked me for some native english advice on how to update the draft to make it clearer and I gave him some; I don't know if the update to the draft that he proposes to do will actually address Dan's concern, but he's planning to spin the draft with that update and then we can ask Dan if he's happy with the new text.

[Ballot comment]
Oops, sorry for not entering a ballot sooner.  I did a very thorough IPdir review of this draft for Ralph; when it didn't get finished before he passed the baton to me, I happily agreed to take over sponsorship of the draft—I think it's very interesting and useful work.

I too would like to see Martin's discuss and Jari's (which is to say, Dan's) comment addressed.

[Ballot comment]
Oops, sorry for entering a ballot sooner.  I did a very thorough IPdir review of this draft for Ralph; when it didn't get finished before he passed the baton to me, I happily agreed to take over sponsorship of the draft—I think it's very interesting and useful work.

I too would like to see Martin's discuss and Jari's (which is to say, Dan's) comment addressed.

[Ballot comment]
There has been a discussion with Gen-ART reviewer Dan Romascanu, and all his issues have been addressed, with the exception of one new question that was posted in e-mail on March 27th. Please take a look at that issue and respond.

[Ballot comment]
Stephen's first comment, and Pete's comments have me covered.  I'd particularly like to see an answer to the question about reviews from manet, roll, and 6lowpan (though I do see Adrian's comment that a routing directorate review was done, so maybe that covers at least some of that).

[Ballot comment]
I'm balloting NO OBJECTION on this, but reluctantly as I share Stephen's concern: The writeup is not up to date and the now cognizant AD has not issued a ballot yet. I also wonder why this didn't come out of any WG, even though it was ostensibly reviewed in several. But there is nothing to indicate that it is problematic to run this experiment, so I won't bother ABSTAINing, let alone DISCUSSing it.

[Ballot comment]

- The write-up seems out of date, says "reviews should be
sought from 6lowpan, manet and roll" and that Ralph is the
AD. Did those WG reviews happen?

- Abstract: "DFF assumes...stuff" would be better as "DFF
is designed for ...when stuff" or "The design of DFF
assumes ... stuff" (Sorry, thats a total nit you can
ignore if you want, not sure why it bothers me;-)

- general: Other than for IETF organisational reasons, why
is this IPv6 only?

- general: you say how to process one packet in a router's
queue. What if that router has many queued packets, are
you saying that it ought pick one, do the DFF thing on
that and only even look at a 2nd packet when the DFF
process for the first one is complete. So I'm puzzled
that you don't mention how a DFF-capable router handles
queues.

- general: If DFF has been "widely deployed" and you
say that then I'd expect a reference that backs that
up.

- general: If this scheme has had significant academic
review (and even the worst routing schemes have, so I
assume this non-worst one also has:-) then I'd expect at
least some reference to the academic literature. If, OTOH,
this is a reasonable routing experiment for which this is
no academic literature, then that seems even more
noteworthy. In any case, when I finally got to appendix B,
I saw some citations. I think moving those up earlier will
help, as would increasing the diversity of the author list
on the cited papers. To be honest, I read the text as
being somewhat optimistic in terms or how widely deployed
DTT might actually be.

- section 8: What happens if the parameters differ in
nodes within the same DFF routing domain?

- section 13: Starting the sequence number from 0 seems
like a bad plan (for DoS resilience). Starting from a
random number would be better.

- 14.1.2: Is OptTypeDFF experimental or what? I'm not
sure what's needed/correct there.

- section 15, I guess this means that the determination of
workable routing domain boundaries is also part of the
experiment really. Better to say that if so in 1.2. And I
think it is so myself. And FWIW, I don't think the text in
this section is that clear - you might be better off to
just say that routing domain egress/exit nodes (D and R2)
need to know or figure out somehow that they are such
nodes.

[Ballot comment]
I support Martin's DISCUSS on the MTU issue with adding information to packets in transit.

I would think that another metric of interest for experimentation is the overall number of transmissions needed to successfully deliver a packet using DFF as compared to the number needed when a routing protocol is employed.  This would need to incorporate the number of control messages sent as well, in some manner.

[Ballot comment]
Overall, this is a nicely written document.  Thanks!  Couple of minor thoughts below.

"""
P_next_hop_neighbor_list is a list of Addresses of Next Hops to
which the Packet has been sent previously, as part of the depth-
first forwarding mechanism, as specified in Section 9.2;
"""

It seems like it would be possible to run this protocol without per-packet state, under two assumptions:
(1) The set of neighbors is preference-ordered
(2) Communication with neighbors is bidirectional
The document seems to assume both of these.  Under these assumptions, the router could simply take a packet that arrives on interface N (in the preference ordering) and transmit it on interface N+1.  The only issue then is loop detection, which could be done by keeping a list of recently seen serial numbers, a much smaller piece of state.


"""
P_HOLD_TIME - is the time period after which a newly created or
modified Processed Tuple expires and MUST be deleted.
"""

It's not immediately clear to me why this value is a constant.  Might it be useful for implementations to vary P_HOLD_TIME, for example, reducing P_HOLD_TIME to save space when there are many packets in flight?

[Ballot discuss]
I have no general objection to the publication of this draft.

It just struck me that DFF adds an IPv6 extension header to an existing packet or encapsulates them for further tunnelling without any mentioning of MTU issues. Adding bytes to an already existing packet is always subject to MTU issues, e.g., if the packet is already 1500 bytes big and you add another n (with n > 0) you have an issue with the MTU.

Please add a description of the MTU issue and also some recommendations what should be done by DFF in that case.

[Ballot discuss]
I have yet to carry out my own review, however this Discuss is a place-
holder.

The editor has indicated that he intends to post a new revision
addressing the comments received during IETF last call and the Routing
Directorate review from Alvaro Retana, or to debate the points raised
by email.  This revision is planned for IETF week, i.e. after the
telechat, so this Discuss holds the document until that update has been
made.

For clarity, the Routing Directorate Review is attached below:

> Document: draft-cardenas-dff-09
> Reviewer: Alvaro Retana
> Review Date: Feb. 22, 2013
> IETF LC End Date: Feb. 24, 2013
> Intended Status: Experimental
>
> Summary:
> I have some minor concerns about this document that I think
> should be resolved before publication.
>
> Comments:
> This draft is very well written.  It clearly describes the
> purpose and operation of DFF in a well organized manner.
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
> o The term "depth-first search" is used several times (in and out
>  of quotes) to characterize DFF.  It would be nice if the term was
>  explained at some point; the terminology section would be ideal.
> o The terms "route-over" and "mesh-under" should be defined for
>  the casual reader.
> o Both sections 4.1 and 6.1 give the impression that the Neighbor
>  List is made up of information received from ONLY "an external
>  neighborhood discovery mechanism", when in fact (as was explained
>  in sections 4 and 11) information from the RIB can also be used.
>  It seems obvious that local RIB information could be used;
>  clarifying a little would go a long way.
> o Section 6 ("Information Sets") talks about what was described
>  in section 4.1 as an "information base".  Either terms is fine with
>  me, but there needs to be consistency.
> o Section 4.2 reads (last paragraph): "..if a router receives a
>  Packet with DUP = 1 (and RET = 0) that it has already forwarded,
>  the Packet is not considered looping, and successively forwarded to
>  the next router.."  I'm at a loss of why would the router forward
>  the packet if it is a duplicate of one that it has already
>  forwarded.  Note also that the case where the packet was in fact
>  delivered, but no link layer confirmation was received (so the
>  sender set DUP := 1 and retransmitted) is not covered in the
>  detailed explanation in section 9.2 - this is a case where RET = 0
>  and the tuple exits, but it is not a loop.
> o In section 9 the term "generated" is used to indicate that a
>  router creates a packet that goes into the DFF domain.  The
>  Terminology section described "originator" as the router that
>  adds the header.  The terms should be consistent.
> o Given the conditions in the applicability statement I doubt
>  that the sequence numbers will wrap while tuples (with the lower
>  numbers) are still in the table.  It would be nice to indicate
>  what to do; maybe flush the tuples is the answer or maybe just
>  indicate that this is one of the items to gather experience during
>  experimentation.
>
> Nits:
> o s/neighbors provided of by an external neighborhood discovery/
>  neighbors provided by an external neighborhood discovery  In the
>  first paragraph in Section 4.
> o IMHO, the second paragraph in Section 4.1 doesn't provide any
>  content and could be deleted.
> o s/increasing the route cost of the route using the Next Hop/
>  increasing the route cost of the router using the Next Hop  In
>  the second paragraph in 4.2.
> o s/flag is included in the DFF Header/flag is set in the DFF
>  header. When describing DUP in section 7.  Using "included" just
>  indicates that the flag is present, which it is even if set to
>  0. ;-)
> o s/Processed Tuples for a Packet is still/Processed Tuple for
>  a Packet is still    When describing P_HOLD_TIME in section 8.
> o Terminology sections.  I thought that section 2.2 did a good
>  job, so I found 14.1.1 and 14.2.4 redundant.
> o "Sequence Number" is not described when presenting the packet
>  formats.

[Ballot discuss]

  The Gen-ART Review by Dan Romascanu on 19-Feb-2013 raises several
  significant concerns.  These concerns deserve a response, but I have
  not seen a response yet.  The Gen-ART Review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg08213.html

IESG/Authors/WG Chairs:

IANA has reviewed draft-cardenas-dff-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there are two actions which IANA must complete.

First, in the Dispatch Type Field subregistry of the IPv6 Low Power Personal Area Network Parameters registry located at:

http://www.iana.org/assignments/6lowpan-parameters/6lowpan-parameters.xml

a new Dispatch Type Field is to be registered as follows:

Bit Pattern: [ TBD AT TIME OF REGISTRATION ]
Header Type: LOWPAN_DFF
reference: [ RFC-to-be ]

Second, in the Destination Options and Hop-by-Hop Options subregistry of the Internet Protocol Version 6 (IPv6) Parameters registry located at:

http://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xml

a new option will be registered as follows:

Hex Value: [ TBD AT TIME OF REGISTRATION ]
act: 00
chg: 1
rest: [ TBD AT TIME OF REGISTRATION ]
Description: IP_DFF
Reference: [ RFC-to-be ]

We understand that these are the only actions that are required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Depth-First Forwarding in Unreliable Networks (DFF)'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the "Depth-First Forwarding" (DFF) protocol
  for IPv6 networks, a data forwarding mechanism that can increase
  reliability of data delivery in networks with dynamic topology and/or
  lossy links.  The protocol operates entirely on the forwarding plane,
  but may interact with the routing plane.  DFF forwards data packets
  using a mechanism similar to a "depth-first search" for the
  destination of a packet.  The routing plane may be informed of
  failures to deliver a packet or loops.  This document specifies the
  DFF mechanism both for IPv6 networks (as specified in RFC2460) and in
  addition also for LoWPAN "mesh-under" networks (as specified in
  RFC4944).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-cardenas-dff/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1645/
  http://datatracker.ietf.org/ipr/1646/

Document Writeup

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

      This is a request for an Experimental RFC and this is consistent
      with the type indicated on the title page of the document.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document specifies the "Depth-First Forwarding" (DFF) protocol
  for IPv6 networks, a data forwarding mechanism that can increase
  reliability of data delivery in networks with dynamic topology
  and/or lossy links. The protocol operates entirely on the
  forwarding plane, but may interact with the routing plane. DFF
  forwards data packets using a mechanism similar to a "depth-first
  search" for the destination of a packet. The routing plane may be
  informed of failures to deliver a packet or loops. This document
  specifies the DFF mechanism both for IPv6 networks (as specified in
  RFC2460) and in addition also for LoWPAN "mesh-under" networks (as
  specified in RFC4944).

Working Group Summary

  This document was not adopted in a Working Group.

Document Quality

  There are currently two known implementations of the protocol.  One
  is used on top of IEEE 802.11 and the other on top of IEEE
  802.15.4. The authors, through this publication hope to elicit
  further implementation and experimentation with this protocol and
  concept.

  Thomas Clausen has reviewed nearly every draft of this document and
  provided detailed comments and critiques, which have been addressed
  by the authors.

Personnel

  Document Shepherd: Geoff Mulligan
  Responsible AD: Ralph Droms

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document has been reviewed by experts in mesh networking and by
  other IP networking experts. The list of reviewers is included in
  section 18 of the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  I have no concerns about the depth or breadth of the reviews of
  the document.  All documents can benefit from greater review.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document has been well reviewed, but further review from manet,
  roll, and the 6lowpan WGs would provide a broader review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

  I am not uncomfortable with any portions of the document.  My
  previous "concerns" associate with document organization and design
  details were addressed by the authors in previous versions. In
  fact, as soon as time permits I hope to build an implementation of
  the protocol based on this version of the draft.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

  IPR disclosure 1646 was filed that references this document.  The
  IPR holder has agreed to license the IPR under a royalty free
  license.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

  The authors and reviewers of document are experts in the field of
  mesh networking and IP. Other team members from the authors'
  companies have also reviewed drafts of the this document.

  The authors and reviewers are fully supportive of this document and
  publication. As this is a new concept through publication and then
  further experimentation the group hopes to find broader review,
  implementation, performance and interoperability results.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No. No one has expressed any discontent with the document

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  All ID nits have been address in the most recent version
  of the document.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  None of these reviews appear to be required

(13) Have all references within this document been identified as
either normative or informative?

  The normative and informative references are split.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are no normative references that are not ready for advancement.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downward normative references.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

  This document will not change the status of any other RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  An addition to the 6lowpan Dispatch Type field is requested for the
  DFF header.

  An addition to the IPv6 Destination Options and Hop-by-Hop options
  registry is requested.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new registries are to be created.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

  The document appears to be correct.  Other than ID-nits, none
  appear to be required.