Thanks Christoph & Alissa Gyan
On Wed, Apr 22, 2020 at 9:55 AM Alissa Cooper <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 > [email protected] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art > > > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: [email protected]
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
