%% You should probably cite draft-ietf-idr-flowspec-path-redirect instead of this I-D.
@techreport{vandevelde-idr-flowspec-path-redirect-00,
    number =    {draft-vandevelde-idr-flowspec-path-redirect-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/00/},
    author =    {Gunter Van de Velde and Wim Henderickx and Keyur Patel},
    title =     {{Flowspec Path-id Redirect}},
    pagetotal = 6,
    year =      2015,
    month =     sep,
    day =       15,
    abstract =  {Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard RFC5575 {[}2{]} defines a redirect-to-VRF action for policy-based forwarding but this mechanism is not always sufficient, particular if the redirected traffic needs to be steered into an engineered path. This document defines a new redirect-to-Path-id (32-bit or 128-bit) flow-spec action to provide advanced redirection capabilities. When activated, the flowspec signalled Path-id is used to identify the next-hop redirect information within a localized to the router Path- id redirect table. The Path-id redirect table is a table providing a list of Path-id's and router local redirect information. This allows a Flowspec signalled redirect towards a next-hop IP address, next-hop local interface or next-hop (traffic engineered) tunnel interface.},
}