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

Thanks Christoph & Alissa

Gyan

On Wed, Apr 22, 2020 at 9:55 AM Alissa Cooper <alissa@cooperw.in> 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
>
>
> On Apr 17, 2020, at 3:43 AM, Christoph Loibl <c@tix.at> wrote:
>
> 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 <noreply@ietf.org>
> 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: 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.
> -->
>
>
> 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: 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
>
> --
> Christoph Loibl
> c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at
>
>
>
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com