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

Robert Wilton <rwilton@cisco.com> Fri, 03 November 2017 10:40 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5E13FB3A for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 03:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 pnOv8nHhvetX for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 03:40:20 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8655113FD6C for <netmod@ietf.org>; Fri, 3 Nov 2017 03:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: =?us-ascii?q?A0COAABPRPxZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJHeJKHSQI5ZFghEKhTsChRQYAQEBAQEBAQEBayiFHQEBAQM?= =?us-ascii?q?BIw8BBUEFCwsYAgImAgJXBg0IAQEXigAIp32CJ4sQAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEhgQ+CH4NaghKDAYgmgmIFih+HP4FtjkOLTYkvi3iHPI4ph22BOR84gWw0IQg?= =?us-ascii?q?dFUmCZYJbHIFnQY1sAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,338,1505779200"; d="scan'208";a="163"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2017 10:40:17 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA3AeHtg026532; Fri, 3 Nov 2017 10:40:17 GMT
To: Kristian Larsson <kristian@spritelink.net>
Cc: Martin Bjorklund <mbj@tail-f.com>, mjethanandani@gmail.com, netmod@ietf.org
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <ac9fc676-80f7-723d-9a85-c99fbb122476@cisco.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <c90aa6c1-340e-2225-f960-73c1395041c5@cisco.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <22bb1ad7-070b-68e1-b35a-bce01204b840@cisco.com> <20171103101225.GJ12688@spritelink.se>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <63d922fe-0f83-f5e7-44a0-7d8abe58aa12@cisco.com>
Date: Fri, 3 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: <20171103101225.GJ12688@spritelink.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/THy2trlcnQDBo4VFB__qSSg0sEg>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=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 :)
Cool.

Rob

>
>     kll
>