| 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@xxxxxx> 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:
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/163I 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.
-->
Cheers Christoph
_______________________________________________Gen-art mailing listGen-art@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/gen-art
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
