[RTG-DIR] Quality Assurance Review of "Destination/Source Routing" - draft-lamparter-rtgwg-dst-src-routing-01

["Acee Lindem (acee)" <[e-mail]>]

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,
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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

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

Summary:

I believe the document is ready for Working Group adoption and further
discussion. 
There are a number of issues that needed to be resolved as part of the
normal
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
4.
      The reason being that BCP 38 is normally not a factor for use cases
where
      complex recursive resolution is required. However, this is a topic
for 
      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
source
               and destination are reversed in the uRPF lookup.

  Section 3.3: I don’t see why multicast is not applicable since there are
(S,G) 
               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
onus
             should be placed on the routing protocol.

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

Thanks,
Acee