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

Kristian Larsson <> Fri, 03 November 2017 10:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EF6313FD53 for <>; Fri, 3 Nov 2017 03:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g-Qr404DVKXr for <>; Fri, 3 Nov 2017 03:12:32 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET []) by (Postfix) with ESMTP id 8AFAE13FD3E for <>; Fri, 3 Nov 2017 03:12:28 -0700 (PDT)
Received: from localhost (localhost []) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 5EC39261846; Fri, 3 Nov 2017 11:12:29 +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 dcHFvlW8SDH1; Fri, 3 Nov 2017 11:12:27 +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 F2537261838; Fri, 3 Nov 2017 11:12:26 +0100 (CET)
Date: Fri, 03 Nov 2017 11:12:25 +0100
From: Kristian Larsson <>
To: Robert Wilton <>
Cc: Martin Bjorklund <>,,
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: Fri, 03 Nov 2017 10:12:34 -0000

On Fri, Nov 03, 2017 at 09:30:01AM +0000, Robert Wilton wrote:
> On 03/11/2017 08:42, Kristian Larsson wrote:
> >On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
> >>
> >>On 02/11/2017 16:41, Kristian Larsson wrote:
> >>>Are we seeking to have a single style of attachment points? I
> >>>think that's difficult in reality. Linux has one style, where a
> >>>single global "ACL" is defined. Most routers use per interface
> >>>ACL and as seen, they split it up on ethernet vs IP (and v4 vs
> >>>v6). I doubt one can be said to be better than the other so
> >>>trying to argue that everyone should converge on one way is
> >>>pointless. Similarly supporting every different style is also
> >>>futile as it's completely against the point of standardisation.
> >>>
> >>>The pragmatic compromies is likely to support a few ways and any
> >>>vendor that needs something radically different need to build
> >>>their own model, do augment, deviate, refine or whatever. Other
> >>>thoughts?
> >>For interface attachments I think that the approach in the draft looks OK,
> >>and reasonably generic, but will need vendor deviations. This is probably
> >>OK.
> >I don't agree. Given the length we've gone in trying to convey the
> >match capabilities of the platform I think we can afford to give
> >implementors some options when it comes to attachment too! :)
> I  agree that interface vs global are two different styles, and happy if the
> model supports both.


> >As for the per-interface style options
> >  * current draft; a list of ACLs of varying "type", evaluated in
> >    specified order, per-interface and per direction
> >  * three separate ACLs for ethernet, ipv4 and ipv6 and
> >    per-interface and per direction
> I think that the current model accommodates both of these.
> For the 3 separate ACLs, the vendor would "deviate" the model with
> additional constraints so that there could only be one ACL of each type in
> the list for an interface.

Fair enough. I actually discussed this solution off-list
yesterday evening but failed to bring it up as a potential
solution now ;)

> Given that the model allows mixed ACLs, this approach still seems reasonable
> and quite generic to me.

Sure. I guess the XPath on IOS XR, which supports one eth acl,
one ipv4 acl and one ipv6 acl per interface becomes a little
tricky. Like we have to do count() based on acl-type I guess to
prevent two ACLs of the same type being set (or say that the
translation mechanism should logically merge multiple ACLs).

JUNOS also has different attachment points that each accept a
list of ACLs so it's just a matter of putting a constraint on
accepted acl-type and the translation mechanism just sorts based
on acl-type.

I'm happy with this :)


Kristian Larsson                                        KLL-RIPE
+46 72 5479985