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

Christoph Loibl <c@tix.at> Mon, 16 October 2017 11:05 UTC

Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DE31344B7; Mon, 16 Oct 2017 04:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1wEMJYxpskb; Mon, 16 Oct 2017 04:05:37 -0700 (PDT)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (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 mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1e42xD-0002cv-AO; Mon, 16 Oct 2017 12:49:03 +0200
From: Christoph Loibl <c@tix.at>
Message-Id: <55EAFCD6-4783-4DDD-B1B9-30AF18FD2342@tix.at>
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 <jgs@juniper.net>, idr@ietf.org, draft-ietf-idr-rfc5575bis@ietf.org
To: Job Snijders <job@ntt.net>
References: <00A83D9A-C00E-4A91-8007-421067DCE879@juniper.net> <20171014153402.GY19142@Vurt.local>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/5rqDOHbNFolZf7JOgJgZUB_5-ak>
Subject: Re: [Idr] WGLC for draft-ietf-idr-rfc5575bis-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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 <job@ntt.net>; 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
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at