[Idr] Genart last call review of draft-ietf-idr-rfc5575bis-20

Gyan Mishra via Datatracker <noreply@ietf.org> Tue, 07 April 2020 21:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7463A08E5; Tue, 7 Apr 2020 14:43:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Gyan Mishra via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.124.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158629580378.13606.6350807287790835622@ietfa.amsl.com>
Reply-To: Gyan Mishra <hayabusagsm@gmail.com>
Date: Tue, 07 Apr 2020 14:43:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Ey7sEPvWdICO7VZEIqoJ3hEAvsk>
Subject: [Idr] Genart last call review of draft-ietf-idr-rfc5575bis-20
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2020 21:43:25 -0000

Reviewer: Gyan Mishra
Review result: Ready with Nits

Reviewer: Gyan Mishra
Review result: Ready with Minor Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-rmcat-wireless-tests-08
Reviewer: Gyan Mishra
Review Date: 2020-04-7
IETF LC End Date: 2020-04-8
IESG Telechat date: Not scheduled for a telechat

Summary: Ready, but with nits and minor issues that should be addressed.  
There are just a few minor points that I would like to bring up related to
clarification of how BGP Flow specification works described in the introduction
as well as updates to "Dissemination of Flow Specification Rules" [RFC5575] and
   "Clarification of the Flowspec Redirect Extended Community"[RFC7674].

Major issues: None

Minor issues:
I am familiar with BGP Flow specification and would like to recommend some
verbiage that may help in the introduction as far as explaining how BGP flow
spec works.  Ssince the introduction has been re-written with this update, this
could be a possible addition to the draft.

This could be placed at the end of the introduction if desired.
BGP flow specification is a client-server model that allows for a more granular
approach to DDOS mitigation than its predecessor, “Remotely Triggered Blackhole
(RTBF) which tagged a prefix with a community and sent it do a discard next
hop.  BGP flow spec has two main components, the “controller” being the BGP
speaker device which acts as the server side, which injects the new flowspec
entry, and the client side which is the BGP speaker devices that receives the
flowspec NLRI and acts on the instruction to match a particular flow with Layer
3 and Layer 4 parameters and then implements the hardware forwarding action

Nits/editorial comments:
7.  Traffic Filtering Actions
   This document defines a minimum set of Traffic Filtering Actions that
   it standardizes as BGP extended community values [RFC4360]

   Any mention of [RFC4360] should be updated with [RFC7153] IANA Registries
   for BGP Extended Communities.