Re: [Idr] WGLC for draft-ietf-idr-rfc5575bis-04

[Job Snijders <[e-mail]>]

(snipping some pieces)

On Mon, Oct 16, 2017 at 01:05:27PM +0200, Christoph Loibl wrote:
> I was looking into configurations of different manufacturers,
> documentations, … there is a mix of flow, flow-spec, flowspec in
> various documents. I suggest to use “flowspec” since this seems to
> have the widest spread already in most of the documentation found on
> the web.

ok!

> > section 4.2.3
> > OLD:  The bits lt, gt, and eq can be combined to produce "less or
> >       equal", "greater or equal", and inequality values.
> > NEW:  The bits lt, gt, and eq can be combined to produce common
> >      relational operators such as "less or equal", "greater or equal",
> >      and "not equal to”.
> 
> I understand that your major point here is that the bit combinations
> produce an _operator_ not a _value_, which is true.

yes

> > section 5.1:
> >    I have trouble parsing: "For IP prefix values (IP destination and source
> >    prefix) precedence is given to the lowest IP value of the common prefix
> >    length;”
> 
> Same with me - I try to come up with something better but it still
> lacks a definition what the common prefix is (I will need some more
> time to think about this):
> 
> For IP prefix values (IP destination and source prefix) the common
> prefixes are compared (common prefix: the prefixes up to the minimal
> prefix-length those two share). If those are equal the prefix with the
> longer prefix-length has higher precedence. If the common prefix is
> different the one with the lowest IP value has higher precedence.
> 
> -> Maybe we can even put it this way - I need to spend more time to
> think if this is equal to the above definition, but looks _much_ more
> elegant (what do you think?):
> 
> If the prefixes are overlapping, the one with the longer prefix-length
> has higher precedence. If they are not overlapping the one with the
> lowest IP value has higher precedence.
> 
> >    If a packet destined for 10.5.0.1 is covered by a rule for
> >    destination 10.0.0.0/8 and a rule covering destination 10.5.0.0/24 -
> >    the 10.0.0.0/8 rule would 'win' because '10.0.0.0' is a lower IP
> >    value?
> 
> No. What actually should happen is:
> 
> 1) compare the “common” prefix (in this case the common prefix length = 8)
> 
> 10.0.0.0/8 == 10.5.0.0/8 -> the common prefix is equal.

Why would you ever see 10.5.0.0/8 - that looks like an incorrect CIDR
notation to me? 

> 2) if the common prefix is equal (which is the case) the prefix with
> the longest match takes precedence:
> 
> 10.0.0.0/8 <- 8 bit
> 10.5.0.0/24 <- 24 bit <- this one wins!
> 
> Another example: 9.0.0.0/8 vs 10.5.0.0/24
> 
> 1) compare the “common” prefix (in this case the common prefix length = 8)
> 
> 9.0.0.0/8 == 10.5.0.0/24 -> the common prefix is _not_ equal
> 
> 2) lower value takes precedence:
> 
> 9.0.0.0 < 10.5.0.0/24
> 
> 9.0.0.0/8 wins!

I'm sorry, but I still don't understand. 9.0.0.0/8 and 10.5.0.0/24 don't
overlap, shouldn't they both be installed as ACLs? Maybe I don't
understand when this algorithm is used?

> >    Another question, and I realise this is a big ask: Is it possible to
> >    replace the pseudocode with an actual code example? Pseudo languages
> >    tend to not follow any specific set of rules and therefor oftentimes
> >    are hard to read. Awk, lua, python, ruby, perl, or really anything
> >    that actually can be compiled and inspected would be better than
> >    pseudocode. I've been part of discussions where we tried to
> >    deconstruct the pseudocode author's intentions and rules of
> >    precedence.
> 
> I also think that actual code that can be interpreted/compiled may be
> helpful in some cases. The complexity of such a code may sometimes not
> be very beneficial and some of the environment (variables, modules,
> helper-functions…)  needed to actually run the code may just not fit
> into such a draft.
> 
> However, I uploaded a python-script containing a python version of the
> flow_rule_cmp(a, b) plus unit-test with 100% code coverage:
> 
> https://github.com/stoffi92/flowspec-cmp/blob/master/flow-cmp.py
> 
> IF the group thinks we shall use this - please carefully analyse the
> behaviour. I am sure I have hidden some bugs in there and I am sure it
> is possible to beautify what I came up with (I am not the programmer).

I think this is a very good direction and I hope the WG sees this as
path forward too.

In the I-D I'd leave out the unittest part for the sake of brevity. I'd
also specify what version of python this code was tested against. And
of course you can include a link to that github repository in the I-D.
For other drafts we've taken a similar approach.

Kind regards,

Job