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

[Christoph Loibl <[e-mail]>]

Hi Job,

Thanks for you excellent feedback on this draft.

See my comments inline.


> On 14 Oct 2017, at 17:34, Job Snijders <[e-mail]> wrote:
> I read the document and support publication.
> 
> Some comments:
> 
> s/automate of inter-domain/automate inter-domain/
> s/application which control/applications which control/
> s/Some of deployments of these/Some deployments of these/

Noted for a update that I will publish by the end of the week.

> I see use of the strings 'flowspec', 'flow-spec' and 'flow spec'; which
> one is the preferred one to use? :)

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.

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

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

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!


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

> Section 13: remove 'Note: Any original author…’

Can/should be done, if no objections.

> This concludes my review, thank you for your work on this document.

Thanks a lot for reading thru this.

Cheers Christoph

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