Subject: [Last-Call] Genart last call review of draft-ietf-idr-rfc5575bis-20

From: Gyan Mishra via Datatracker <[email-masked]>
Date: Tue, 07 Apr 2020 14:43:24 -0700

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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

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.

---

From: Christoph Loibl <[email-masked]>
Date: Wed, 8 Apr 2020 09:36:33 +0200

Hi Gyan,

Thanks for the review. I will collect the results of all reviews and comment on those later. I need to note that the reviewed document is draft-ietf-idr-rfc5575bis-20 not rmcat-wireless-tests ;-) :

On 07.04.2020, at 23:43, Gyan Mishra via Datatracker <[email-masked]> wrote:

Thanks,

Christoph

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 8 Apr 2020 21:26:58 -0400

Sorry about the typo in the Draft name specified was incorrect.

Document: draft-ietf-rmcat-wireless-tests-08  - should be
"draft-ietf-idr-rfc5575bis-20"

Kind regards

Gyan

On Wed, Apr 8, 2020 at 3:36 AM Christoph Loibl <[email-masked]> wrote:

> Hi Gyan,
>
> Thanks for the review. I will collect the results of all reviews and
> comment on those later. I need to note that the reviewed document is
> draft-ietf-idr-rfc5575bis-20 not rmcat-wireless-tests ;-) :
>

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Christoph Loibl <[email-masked]>
Date: Fri, 17 Apr 2020 09:43:12 +0200

Hi Gyan,

> 3 and Layer 4 parameters and then implements the hardware forwarding action

<-- 
Tracked via issue #163: https://github.com/stoffi92/rfc5575bis/issues/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.
-->

>   for BGP Extended Communities.

<-- 
Tracked via issue #164: https://github.com/stoffi92/rfc5575bis/issues/164
Commits mentions:
    https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa2750fd376dc148d7a590369
    https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7d5c1822070b862247dfaead

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]/

-->

Cheers 
Christoph

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 22 Apr 2020 09:55:06 -0400

Gyan, thanks for your review. Christoph, thanks for your response. I think the intro in the draft is ok as-is. I entered a DISCUSS ballot with a question about Section 7.

Alissa

> On Apr 17, 2020, at 3:43 AM, Christoph Loibl <[email-masked]> wrote:
> 
> Hi Gyan,
> 
>> On 07.04.2020, at 23:43, Gyan Mishra via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Reviewer: Gyan Mishra
> Tracked via issue #163: https://github.com/stoffi92/rfc5575bis/issues/163 <https://github.com/stoffi92/rfc5575bis/issues/163>
> 
> Tracked via issue #164: https://github.com/stoffi92/rfc5575bis/issues/164 <https://github.com/stoffi92/rfc5575bis/issues/164>
> Commits mentions:
>     https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa2750fd376dc148d7a590369 <https://github.com/stoffi92/rfc5575bis/commit/31f0ac79b7cd998aa2750fd376dc148d7a590369>
>     https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7d5c1822070b862247dfaead <https://github.com/stoffi92/rfc5575bis/commit/7aadadcdf55a1f5a7d5c1822070b862247dfaead>
> 
> [email-masked] <mailto:[email-masked]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at <http://www.nextlayer.at/>
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Apr 2020 19:50:24 -0400

Thanks Christoph & Alissa

Gyan

On Wed, Apr 22, 2020 at 9:55 AM Alissa Cooper <[email-masked]> wrote:

> Gyan, thanks for your review. Christoph, thanks for your response. I think
> the intro in the draft is ok as-is. I entered a DISCUSS ballot with a
> question about Section 7.
>
> Alissa
>
>
> Thanks for your review. According to your review I made the following
> changes to the document which is available now as revision -22:
>
> 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:
> 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.
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>
>
> --

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347