Skip to main content

Early Review of draft-lamparter-rtgwg-dst-src-routing-01

Request Review of draft-lamparter-rtgwg-dst-src-routing
Requested revision No specific revision (document currently at 01)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-08-25
Requested 2015-08-18
Authors David Lamparter
I-D last updated 2015-08-25
Completed reviews Rtgdir Early review of -01 by Acee Lindem
Assignment Reviewer Acee Lindem
State Completed
Request Early review on draft-lamparter-rtgwg-dst-src-routing by Routing Area Directorate Assigned
Reviewed revision 01
Result Has issues
Completed 2015-08-25
Hello David,

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 WG adoption, IETF last call, and IESG review,
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

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.

Since this is an initial QA review, I intend to focus on the main area
that require discussion in the WG.

Document: draft-lamparter-rtgwg-dst-src-routing-01
Reviewer: Acee Lindem
Review Date: 21 Aug 2015
Intended Status: Standards Track


I believe the document is ready for Working Group adoption and further
There are a number of issues that needed to be resolved as part of the
IETF process.

Issues for Resolution:

  Section 3.1: Ultimately we need to choose a variant for recursive route
      resolution. I believe we should choose one that simpler than variant
      The reason being that BCP 38 is normally not a factor for use cases
      complex recursive resolution is required. However, this is a topic
      WG discussion.

  Section 3.2: Again, I believe one option needs to be selected for uRPF
               filtering. I believe it should be pointed out that both the
               and destination are reversed in the uRPF lookup.

  Section 3.3: I don’t see why multicast is not applicable since there are
               multicast routes (where the source is always /128).

  Section 4: Rather than expressing the constraints in terms of
forwarding, they
             should be expressed in terms of route installation and more
             should be placed on the routing protocol.

Nits: I have some suggested editorial changes to the draft that I will
to David.