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

Job Snijders <> Mon, 16 October 2017 16:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 619C1133023 for <>; Mon, 16 Oct 2017 09:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.418
X-Spam-Status: No, score=-1.418 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, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z5z3WmSTemsa for <>; Mon, 16 Oct 2017 09:30:52 -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 A209A126E64 for <>; Mon, 16 Oct 2017 09:30:52 -0700 (PDT)
Received: by with SMTP id f4so5182788wme.0 for <>; Mon, 16 Oct 2017 09:30:52 -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:in-reply-to:user-agent; bh=L/C7yHNr6Jwjmfgj2ru+yP/WRiQijt5j1dv/gtFJyCA=; b=rQV7ybcK/PCbx5pNwLlPAeunIuR2R8EA+rAhImbHWCEanF1UrPpqhW7QX4Pa9iXLPc ZT/4JaCYn9A4qcZIk7T3jhrY99pV+YDSC/zuGz0i8h0wDVFV/pghifUBecEGvnob7ZJY kEHWpNMlG1KAUud6wAwZZlAJbsvztGcrUmXt73qfwAc9jI31fqQuRT7fBzm52Wi67Qg7 so2Bm4XSri3CyNEuaAXvQ8OVy0yp2xz0DTef18bKDTvR0uelueh7n+b36ty0BF966ET6 oMi0DOYHgXWqVe12cYWHXk//sGINo3MWrW5iGONl8dtsdPW9FLohqWORUKNagqoBCwsE hNqg==
X-Gm-Message-State: AMCzsaVWarSouPMCOLnZWK/416+II3u8LbGDIHFaHAd4xapDUI5sLGFM zyf8M7e7gFJYnwnwtLcil+miuw==
X-Google-Smtp-Source: AOwi7QAw8xt81VT/ZuPaOjsNuzqwOaykNY0YGX7VKv+UVbAKsuq52ErOXlJkjB6Evao+obmAMNkFJg==
X-Received: by with SMTP id e5mr13459905edc.51.1508171450789; Mon, 16 Oct 2017 09:30:50 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:e5a3:5934:947a:210d]) by with ESMTPSA id x10sm6013984edb.24.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Oct 2017 09:30:49 -0700 (PDT)
Date: Mon, 16 Oct 2017 18:30:46 +0200
From: Job Snijders <>
To: Christoph Loibl <>
Message-ID: <>
References: <> <20171014153402.GY19142@Vurt.local> <> <20171016120520.GM19142@Vurt.local> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170912 (1.9.0)
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 16:30:54 -0000

On Mon, Oct 16, 2017 at 01:00:26PM +0000, Christoph Loibl wrote:
> > 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?
> Both are actually installed (but the order is determined). This
> algorithm is used for sorting the ACL terms. 

Ah! I see now, thank you for your patience and clarification. For some
reason I derailed into the LPM routing mindset. OK, back to the original

OLD: For IP prefix values (IP destination and source prefix) precedence
     is given to the lowest IP value of the common prefix length; if the
     common prefix is equal, then the most specific prefix has

    For IP prefix values (destination or source) the common high-order
    bits are compared. The number of common bits to compare is the
    lowest prefix-length of the two prefixes. If the high-order bits are
    equal, the prefix with the longer prefix-length has higher
    precedence. If the common high-order bits are different, the prefix
    with the lowest numeric value takes higher precedence.

> >>>   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
> >> 
> >> 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.
> Can you point me to some I-Ds that use a similar approach - maybe one
> can learn from that.

You can put the relevant python code inside CDATA block to preserve

    my python code ..


And in the paragraph introducing the code reference the full codebase as

    The full python implementation of 'flowspec-cmp' is available at
    <eref target=""></eref>;.

Be sure to add something liberal like a BSD-2 Clause LICENSE file to the

Kind regards,