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

Christoph Loibl <> Fri, 17 April 2020 07:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 610483A0FD1; Fri, 17 Apr 2020 00:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pQZmKB76J9oy; Fri, 17 Apr 2020 00:43:18 -0700 (PDT)
Received: from ( [IPv6:2001:858:58::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20DD13A0FB8; Fri, 17 Apr 2020 00:43:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dguKkT6L0tRJg3kunZwNmQknMaJTBKin7B10aaGWBVI=; b=e7+SfkoI/ZFkEAWq6m3CUTus/g MRgURoxg07BnVD+/4xyPAtqPigO3iL3emBZ2lMXKDNFiSmqcx60tXvwL2CLyO3qJ6M8PYmmsvyB49 jB343HTslCgCZVGCUJmHUgsO01iPlrvFcQE5C+1aT6PAukp1ncUldOyUOWkD7b4vJObR51Dvco1mc tJ3TtaQ6HjNv3D2vk8cUsDSxxS5ltTkoXsjN6MnBH4oT1vu5Rwfx2EHRYYNUdCfeULh8LXg9H3q1h 4vVS91NM0prrv/bgitv8DHOMXyijKa31ja1ESd4PH76a0kSHP86LUeFu991r/HUyUieLANA0Eh5K/ xD4+kw3w==;
Received: from ([] helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1jPLec-0001M5-0o; Fri, 17 Apr 2020 09:43:14 +0200
From: Christoph Loibl <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_28C4CD40-E6D6-437F-8AFF-EDA123E64E81"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Fri, 17 Apr 2020 09:43:12 +0200
In-Reply-To: <>
Cc:,,, IDR List <>
To: Gyan Mishra <>
References: <>
X-Mailer: Apple Mail (2.3608.
X-Scanned-By: primary on (; Fri, 17 Apr 2020 09:43:14 +0200
Archived-At: <>
Subject: Re: [Idr] Genart last call review of draft-ietf-idr-rfc5575bis-20
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Apr 2020 07:43:22 -0000

Hi Gyan,

Thanks for your review. According to your review I made the following changes to the document which is available now as revision -22:

> On 07.04.2020, at 23:43, Gyan Mishra via Datatracker <> wrote:
> Reviewer: Gyan Mishra
> Review result: Ready with Nits
> Reviewer: Gyan Mishra
> Review result: Ready with Minor Issues
> 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
> requested.

Tracked via issue #163:

I do not agree that BGP flowspec is a client-server model -only-. We can propagate this NLRI over administrative domain borders as we do with IP routing information, it follows the same mechanisms. We see such solutions being deployed in the internet as inter provider DDoS solutions.

We actually had a paragraph in the darft that was explaining the advantages over other approaches like RTBF but this has been removed because it was pointed out that it is not relevant to the spec to justify a well deployed technology.

> 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.

Tracked via issue #164:
Commits mentions:

Removed the "values" statement (as suggested by Alvaro) from the draft to make clear we are not talking about particular values but about  Extended Communities as specified in RFC4360.
s/standardizes as BGP extended community values [RFC4360]/standardizes as BGP extended communities [RFC4360]/



Christoph Loibl | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 |