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

Robert Wilton <> Fri, 03 November 2017 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BF5E13FB3A for <>; Fri, 3 Nov 2017 03:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pnOv8nHhvetX for <>; Fri, 3 Nov 2017 03:40:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8655113FD6C for <>; Fri, 3 Nov 2017 03:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3377; q=dns/txt; s=iport; t=1509705619; x=1510915219; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EqpLOfEX6i8JHdGJp1pR5e1qK3odTzHAy+6j1jl8/Pc=; b=CgBV+JL1uiuPxova5P9JNpD2cMJxSOQSLVT76zGRVXtb5j5QRjJgNXMI 6XcoSadFaj/QbL8c6kRxE8XlZfr/YQ25xyt0CnFj9+ImM51Xd1c5Khnll dP9P8blNtauwLPwsN36B+F01thfwLI91gzlmpYYIS7oNtvco4iERLqb7G A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.44,338,1505779200"; d="scan'208";a="163"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2017 10:40:17 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id vA3AeHtg026532; Fri, 3 Nov 2017 10:40:17 GMT
To: Kristian Larsson <>
Cc: Martin Bjorklund <>,,
References: <> <> <> <> <> <> <> <> <> <>
From: Robert Wilton <>
Message-ID: <>
Date: Fri, 03 Nov 2017 10:40:16 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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:40:22 -0000

On 03/11/2017 10:12, Kristian Larsson wrote:
> 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.
> Cool.
>>> 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).
Yes.  I thought XR either allowed a v4 and  a v6 ACLs, or no IP ACL and 
just an Ethernet ACL.

If so the constraint should be something very roughly like:
- deviate add max-elements 2
- deviate add unique "type"
- deviate add must (count(set-name) != 2, or acl_type != eth).

Or, if one of each type is allowed, then this would just be:
- deviate add max-elements 3
- deviate add unique "type"

> 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 :)


>     kll