Subject: [RTG-DIR] RtgDir review: draft-cardenas-dff-09

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 22 Feb 2013 22:35:46 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to        the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

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:

  1.  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.
  2.  The terms "route-over" and "mesh-under" should be defined for the casual reader.
  3.  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.
  4.  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.
  5.  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.
  6.  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.
  7.  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:

  1.  s/neighbors provided of by an external neighborhood discovery/neighbors provided by an external neighborhood discovery   In the first paragraph in Section 4.
  2.  IMHO, the second paragraph in Section 4.1 doesn't provide any content and could be deleted.
  3.  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.
  4.  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. ;-)
  5.  s/Processed Tuples for a Packet is still/Processed Tuple for a Packet is still     When describing P_HOLD_TIME in section 8.
  6.  Terminology sections.  I thought that section 2.2 did a good job, so I found 14.1.1 and 14.2.4 redundant.
  7.  "Sequence Number" is not described when presenting the packet formats.