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 <nore...@ietf.org >> <mailto:nore...@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 > <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 > <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> > > 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 <mailto:c...@tix.at> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | > http://www.nextlayer.at <http://www.nextlayer.at/> > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org <mailto:Gen-art@ietf.org> > https://www.ietf.org/mailman/listinfo/gen-art > <https://www.ietf.org/mailman/listinfo/gen-art>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
