Re: [Idr] Returning draft-ietf-idr-rfc5575bis to WG, new 2 week discussion period

[Jeffrey Haas <[e-mail]>]

Christoph,

On Thu, Jun 13, 2019 at 09:22:15PM +0200, Christoph Loibl wrote:
> I think that in this context we can treat a non-existing destination-ip flow-component as 0/0 and I suggest something like this:
> 
> OLD:
> 
>      a) The originator of the Flow Specification matches the originator
>      of the best-match unicast route for the destination prefix
>      embedded in the Flow Specification.
> 
> NEW:
> 
>      a) The originator of the Flow Specification matches the originator
>      of the best-match unicast route for the destination prefix
>      embedded in the Flow Specification. 0/0 is assumed as destination prefix in 
>      this context if it is not embedded in the Flow Specification.  

I think this has the likelihood to cause some undesirable implementation
behaviors.

If the dest-prefix filter is presumed to be 0/0, the only route that can
contain it is 0/0.  We're thus implicitly suggesting that if you want
flowspec validation to work, originate default.

> Extensions may need to revise this validation behaviour for their needs anyway.

See also https://tools.ietf.org/html/draft-ietf-idr-bgp-flowspec-oid-08

> The draft itself does not deal with / mention any possible vendor-specific
> exception mechanisms that allow to circumvent the validation (complete or
> partly), thus I think there is no additional paragraph needed that tries
> to explain how such validation can be relaxed. (maybe only very minimal
> “This validation procedure MAY be relaxed by configuration.”) 


Thus why John's text is probably the level of desired flexibility.  Copied
from below:

: NEW:
:   A Flow Specification NLRI must be validated such that it is
:   considered feasible if and only if:
: 
:      a) A destination prefix component is embedded in the Flow 
:      Specification.
: 
:      b) The originator of the Flow Specification matches the originator
:      of the best-match unicast route for the destination prefix
:      embedded in the Flow Specification.
: 
:      c) There are no more specific unicast routes, when compared with
:      the flow destination prefix, that has been received from a
:      different neighboring AS than the best-match unicast route, which
:      has been determined in step b).
: 
:   Rule a) MAY be relaxed by configuration, permitting Flow
:   Specifications that include no destination prefix component. If such
:   is the case, rules b) and c) are moot and MUST be disregarded.

-- Jeff