Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

Kristian Larsson <> Tue, 31 October 2017 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3070713F439 for <>; Tue, 31 Oct 2017 04:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oaWuce1ZfxMQ for <>; Tue, 31 Oct 2017 04:37:51 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET []) by (Postfix) with ESMTP id 7DCEF13F62F for <>; Tue, 31 Oct 2017 04:37:50 -0700 (PDT)
Received: from localhost (localhost []) by Mail2.SpriteLink.NET (Postfix) with ESMTP id E15C2261846; Tue, 31 Oct 2017 12:37:50 +0100 (CET)
X-Virus-Scanned: amavisd-new at SpriteLink.NET
Received: from Mail2.SpriteLink.NET ([]) by localhost (Mail2.SpriteLink.NET []) (amavisd-new, port 10024) with ESMTP id EeXvpfBdXsiU; Tue, 31 Oct 2017 12:37:45 +0100 (CET)
Received: from localhost (Mission-Control.SpriteLink.NET []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 4DBE4261838; Tue, 31 Oct 2017 12:37:45 +0100 (CET)
Date: Tue, 31 Oct 2017 12:37:43 +0100
From: Kristian Larsson <>
To: Eliot Lear <>
Cc: "" <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Oct 2017 11:37:54 -0000

On Tue, Oct 31, 2017 at 11:47:54AM +0100, Eliot Lear wrote:
> Hi Kristian,
> Just my view below:
> On 10/31/17 11:25 AM, Kristian Larsson wrote:
> > This brings us to the acl-type. It seems to me that this is
> > primarily for being able to do YANG validation when a device does
> > NOT support a unified model. I.e. if Linux nftables was all we
> > wanted to model, then we wouldn't need this and the only
> > (implied) acl-type would be l2-l3-ipv4-acl. In reality though, we
> > need acl-type because most current network devices out there have
> > per-AFI types and we want to be able to say:
> >  * this interface attachment point can only do ipv4-acl
> > And still be able to validate the data based on the YANG model.
> > Is this correct? It seems like one hell of a design trade-off to
> > be able to achieve that. Wouldn't we be better off with actually
> > having different list of ACLs, again vastly simplifying the
> > attachment points and making data validation much easier?
> This reflects, IMHO, the complexity of the situation.  You want
> consistent policy implemented to the full extent of device
> capabilities.

I'd argue we are not achieving that anyway because of the
previously mentioned container mess. I.e. on a a Cisco I'd have
to do matches/ipv4-acl/foo while on my Linux machine I'd do
matches/l2-l3-ipv4-ipv6-acl/foo. Thus multiple ACLs need to be
generates for any heterogenous network. We missed the goal with
the model.

>  That means that if someone wants to generate a mixed mode
> ACL, they can.  But if we attempt to separate those mixed modes on the
> device, can we guarantee that we have gotten the intent correct and
> consistent with, say, what would have been the mixed mode?  I think
> that's how we got here but others can speak more authoritatively.  And
> keep in mind, all of this ties to efficient use of device resources, and
> so there's a lot of h/w optimization seemingly going on here.

So how is the current situation better than doing:

module: ietf-access-control-list
    +--rw access-lists
       +--rw acl [acl-name] <<< this is the unified one
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ethernet
       |        |  +--rw ipv4
       |        |  +--rw ipv6
       |        ...

       +--rw ipv4-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

       +--rw ipv6-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

I'm really bothered by the compound key consisting of acl-type
and the acl-name since attachment points then need to reference
both.  It's also weird because I don't think choosing the
acl-type is really a choice of the user but more of a limitation
of the platform.

One approach would be to change the key to only be the acl-name
but let the acl-type leaf remain, perhaps make it mandatory or
default to some unified acl-type. I think it's still possible to
implement a constraint on this, right? Like if a platform only
supports a specific type at some attachment point it can add a
constraint on the acl-type by doing deref() on the leafref.

module a-vendor-module {
  list interfaces {
		leaf ingress-acl {
		  type leafref {
			  path "/acl:access-lists/acl/acl-name";
			must 'yangexp:deref(.)/../acl-type="ipv4-acl"';

I think that looks much nicer. Am I missing something?

It would create a single namespace for all ACL types which is
potentially a problem for some vendors when doing backwards
mapping, like they have separate ipv4 and ipv6 acls today and
when starting to support this new model you could end up in a
collision. But if that is the case, would it not be okay to just
prefix the type to the name as part of the data translation?

Kind regards,

Kristian Larsson                                        KLL-RIPE
+46 704 264511