Thank yo for feature request however here are few points against implementing such specification:
- General argument used to support such new BGP features:
Since BGP is such a stable and widely deployed thing,
let's add all kind of random stuff to it.
Once you start adding stuff, BGP implementation ceases
to be simple, stable, and gets whole lot of new
failure modes. Quoting rfc:
"While it is certainly possible to address this problem using other
mechanisms, the authors believe that this solution offers the
substantial advantage of being an incremental addition to already
But you still need to configure it on each BGP speaker.
Why not, under the hood, make it a separate protocol so
that bugs in this thing don't pull whole BGP under?
- BGP NLRI is meant to carry address prefixes, which, in the
case of VPNv6, are 8 bytes RD + 16 bytes IPv6.
Data structures that handle such short ( <= 24 bytes)
prefixes well are generally not suited for storing
arbitrary length (into kilobytes) NLRI this RFC proposes to use.
The SANE way would have been to use NLRI as a short ID,
and keep flow matchers in the attributes. No reason in RFC is
given for their choice.
- If BGP speaker that redistributes flowspec gets DOSed,
flowspecs are removed from BGP peers. RFC does not
explain how this case is handled.
- This thing needs a way for administrator to monitor/limit
the amount of distributed info. You cannot use existing
tools for this thing.
Juniper does it since 7.3, and there are no good alternatives to prevent DDoS traffic. Cloudflare uses it, a lot of people uses it, if you want to give some sense to your "high end" devices you should think about this seriously.