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

Christoph Loibl <> Mon, 16 October 2017 11:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75DE31344B7; Mon, 16 Oct 2017 04:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K1wEMJYxpskb; Mon, 16 Oct 2017 04:05:37 -0700 (PDT)
Received: from ( [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59687128D0D; Mon, 16 Oct 2017 04:05:37 -0700 (PDT)
Received: from [2a01:190:1702:0:2813:ab60:d8d9:4caa] by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <>) id 1e42xD-0002cv-AO; Mon, 16 Oct 2017 12:49:03 +0200
From: Christoph Loibl <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_222E8CB6-B491-4581-944C-18FB109ED32B"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 16 Oct 2017 13:05:27 +0200
In-Reply-To: <20171014153402.GY19142@Vurt.local>
Cc: John Scudder <>,,
To: Job Snijders <>
References: <> <20171014153402.GY19142@Vurt.local>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Idr] WGLC for draft-ietf-idr-rfc5575bis-04
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Oct 2017 11:05:40 -0000

Hi Job,

Thanks for you excellent feedback on this draft.

See my comments inline.

> On 14 Oct 2017, at 17:34, Job Snijders <>; 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 is covered by a rule for
>    destination and a rule covering destination -
>    the rule would 'win' because '' is a lower IP
>    value?

No. What actually should happen is:

1) compare the “common” prefix (in this case the common prefix length = 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: <- 8 bit <- 24 bit <- this one wins!

Another example: vs

1) compare the “common” prefix (in this case the common prefix length = 8) == -> the common prefix is _not_ equal

2) lower value takes precedence: < 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: <>

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 | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 |