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

Job Snijders <> Mon, 16 October 2017 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BABC1344C9 for <>; Mon, 16 Oct 2017 05:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OzLJrxpDzUzZ for <>; Mon, 16 Oct 2017 05:05:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00D1E1344CA for <>; Mon, 16 Oct 2017 05:05:28 -0700 (PDT)
Received: by with SMTP id i124so2510974wmf.3 for <>; Mon, 16 Oct 2017 05:05:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=UF2NwFESEO/EvZr6u+RjAiEd3qu7j+hnXgh3hBRFLqA=; b=Io1JJDYh4z4CGsW3ug6bGPAfrCrXEKLJ6rNlj0+O60r0MOZA6PqW22qrwmWtCXZEy/ sE2gikvGJTnnufHKloK36DfM4l0+Lt2OhS38c4h289LVFykELRYEiQRGNzOauN4QHgGT qMluUYrU+mpWNm33p+0pVFMdkp+40mFy8TaebxOK6cb58Df33/p05nhbcS+HUPo6VTIy juOiBKCqnFUj1f3/ELISBvHAFfkepUcX79Ib1tdS8ZaA8yvpmX5Fj/+nuTNi51cqdTqc HmYHbKQb7lmuKKmuFqwx9J4TnLGzbEfNULazHcUtfQP2MgTVCBf5ruyJTbi08VLAbbMU 4Wjg==
X-Gm-Message-State: AMCzsaVUJ+Z/t/ynOLVik/2gPDtQrFFzHxywpJSN6Sn+DcFgXUTVS5ov hgR73vozFY10q5vmszfJmBE+Qg==
X-Google-Smtp-Source: AOwi7QD5gmpDbos9EZEb/ABFibZIoZKACaFTT+EIY9PT7rODM8oapbzMJIKU3nTZa9+fynTK2VpLng==
X-Received: by with SMTP id m53mr12241811edc.249.1508155526967; Mon, 16 Oct 2017 05:05:26 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:5d66:4108:f9d9:1df0]) by with ESMTPSA id t43sm5297832edh.22.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 05:05:21 -0700 (PDT)
Date: Mon, 16 Oct 2017 14:05:20 +0200
From: Job Snijders <>
To: Christoph Loibl <>
Message-ID: <20171016120520.GM19142@Vurt.local>
References: <> <20171014153402.GY19142@Vurt.local> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.9.1 (2017-09-22)
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 12:05:36 -0000

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


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

Why would you ever see - 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:
> <- 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!

I'm sorry, but I still don't understand. and 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:
> 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,