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

[Christoph Loibl <[e-mail]>]

Hi,


> On 13.06.2019, at 22:53, Jeffrey Haas <[e-mail]> wrote:
> On Thu, Jun 13, 2019 at 09:22:15PM +0200, Christoph Loibl wrote:
>> 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.

I have no lab at hand (now) - but I am really curios how ie. Juniper (also other vendors) actually validate FS without a destination-prefix component (to be honest, I never tried this - but it is supposed to be easily verified).

> 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.

Originate default + have no other more-specifics punching holes into that 0/0 - this is arguable very unlikely :-) - still I am not convinced if the behaviour is so much different to what John suggested. I have no objections to John’s solution either.

>> 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

Yes. Saw that.

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

Reading John’s suggestion twice this seems to give more flexibility to extensions while keeping the core behaviour close to what is out there (still there may be changes in behaviour given we do not know what is out there). 

Cheers Christoph

-- 
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at