Subject: [RTG-DIR] RtgDir review: draft-ietf-opsec-urpf-improvements03.txt

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wed, 21 Aug 2019 13:30:05 +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://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.

Document: draft-ietf-opsec-urpf-improvements03.txt
Reviewer: Matthew Bocci
Review Date: 21 August 2019
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:

Generally, I found the draft quite readable, with a clear explanation of the problem statements and solutions as well
as the trade-offs on the implementation. However, I have one minor comment and a nit.

Major Issues:

No major issues found.

Minor Issues:

Terminology: The document expands 'uRPF' as 'unicast reverse path filtering'. However, I
believe that uRPF commonly means 'unicast reverse path forwarding'   (see RFC3704 and
most vendor documentation). "Ingress filtering" is the general concept and "reverse path
 forwarding" the specific algorithm. Did the authors intend to use a new term, and if so why?

Nits:

Section 2.5: "...separate from the global Routing Information Base (RIB) [Juniper][RFC4364]."
VRFs are supported by most vendors so I think it is sufficient just to reference RFC4364.

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Sat, 31 Aug 2019 00:51:58 +0000

Matthew:

Thank you for your comments. Sorry about the delay in replying.
We (authors) have uploaded a new version and have included changes
reflecting your comments. Please see:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-opsec-urpf-improvements-04.txt  
Please also see responses to your comments inline below. 

> forwarding" the specific algorithm. Did the authors intend to use a new term, and if so why?

Great catch. I am surprised we (authors) overlooked and no one else caught it for so long.
Thank you!  Fixed. 

>VRFs are supported by most vendors so I think it is sufficient just to reference RFC4364.

The sentence now reads:
   The Virtual Routing and Forwarding (VRF) technology [RFC4364]
   [Juniper] allows a router to maintain multiple routing table
   instances separate from the global Routing Information Base (RIB).

Shuffled the order of references. Keeping [Juniper] because there is some 
tutorial material in it that may be helpful for some readers.

Regards,
Sriram