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

Job Snijders <job@ntt.net> Mon, 16 October 2017 12:05 UTC

Return-Path: <job@instituut.net>
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 1BABC1344C9 for <idr@ietfa.amsl.com>; Mon, 16 Oct 2017 05:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzLJrxpDzUzZ for <idr@ietfa.amsl.com>; Mon, 16 Oct 2017 05:05:34 -0700 (PDT)
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D1E1344CA for <idr@ietf.org>; Mon, 16 Oct 2017 05:05:28 -0700 (PDT)
Received: by mail-wm0-f53.google.com with SMTP id i124so2510974wmf.3 for <idr@ietf.org>; Mon, 16 Oct 2017 05:05:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.80.169.120 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 smtp.gmail.com with ESMTPSA id t43sm5297832edh.22.2017.10.16.05.05.21 (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 <job@ntt.net>
To: Christoph Loibl <c@tix.at>
Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr@ietf.org
Message-ID: <20171016120520.GM19142@Vurt.local>
References: <00A83D9A-C00E-4A91-8007-421067DCE879@juniper.net> <20171014153402.GY19142@Vurt.local> <55EAFCD6-4783-4DDD-B1B9-30AF18FD2342@tix.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <55EAFCD6-4783-4DDD-B1B9-30AF18FD2342@tix.at>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/QsiT0SpqeCG82NcOR7vLfwWnWXk>
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 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.

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