Re: [netmod] IETF ACL model
Martin Bjorklund <mbj@tail-f.com> Tue, 28 November 2017 10:18 UTC
Return-Path: <mbj@tail-f.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 28E85126B6E for <netmod@ietfa.amsl.com>; Tue, 28 Nov 2017 02:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol1t6ZUBaiEP for <netmod@ietfa.amsl.com>; Tue, 28 Nov 2017 02:18:37 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84597124319 for <netmod@ietf.org>; Tue, 28 Nov 2017 02:18:37 -0800 (PST)
Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 654EF1AE0336; Tue, 28 Nov 2017 11:18:36 +0100 (CET)
Date: Tue, 28 Nov 2017 11:17:15 +0100
Message-Id: <20171128.111715.2283575031970124402.mbj@tail-f.com>
To: mjethanandani@gmail.com
Cc: netmod@ietf.org, rwilton@cisco.com, jhaas@juniper.net, agarwaso@cisco.com, kll@spritelink.net, kll@dev.terastrm.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <A6290183-E975-4BDA-83C3-640E237BD5F2@gmail.com>
References: <e1fe6796-c124-b663-8e9f-e66c23b10eea@cisco.com> <87y3mr3loc.fsf@dev.terastrm.net> <A6290183-E975-4BDA-83C3-640E237BD5F2@gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HOJ-o0YxEhrQE29e20hpnpkxBkk>
Subject: Re: [netmod] IETF ACL model
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: Tue, 28 Nov 2017 10:18:39 -0000
Mahesh Jethanandani <mjethanandani@gmail.com> wrote: > An updated version of the model has been posted as part of the PR here > <https://github.com/netmod-wg/acl-model/commit/2477cd400cce6d39933c908ad97da27ff759588b>. > > The particular change removes any-acl from the model, expands on eth > (to ethernet), removes acl- prefix for things like acl-type and > acl-name. Please review. I think 99% of the changes in this PR look good. The one exception is the typedef that used to be called "acl-type". I think it should still be called "acl-type". "type" is too broad. NOTE, this is just the typedef; the leaf /access-lists/acl/type should keep its name ("type"). /martin > > > On Nov 27, 2017, at 5:17 AM, Kristian Larsson <kll@dev.terastrm.net> > > wrote: > > > > > > Robert Wilton <rwilton@cisco.com> writes: > > > >> Thinking about this some more. I'm not sure what it means for the "ACL > >> Type" to be "any-acl". It seems that the "match any packet" should be > >> a > >> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a > >> type of ACL. > > > > Yes, I agree as so far that any-acl makes no sense as an acl-type. The > > way I understood acl-type, and the way that vendors have told me it > > will > > be used, is to say "this is an IPv4 ACL" and then on an attachment > > point > > you can specify that only ACLs of acl-type ipv4-acl can be attached to > > the interface. That makes perfect sense. I do not see how any-acl can > > map into this. > > > > I agree that any-acl is logically a type of ACE but we don't have an > > ace-type and the exact same information can IMHO already be conveyed > > WITHOUT the any-acl type and thus it has no reason to exist. Nor do we > > need a feature for it. > > > > From what I can tell the any-acl container in the ACE should be used > > to > > explicitly signify a match on "any". Think of IOS style ipv4 acl: > > permit ip any any > > > > We have to provide a source and destination so this would be a rather > > explicit mapping of that. However, our structure in this YANG model is > > just completely different than an IOS command so I don't see why we > > should try and mimic IOS in the YANg model. > > > > Not specifying a destination IP address means we match on any > > destination IP address. The same is true for any other field we can > > match on. Not setting a match implies we don't try to match on that > > field, thus we allow "any" value. I think the logical continuation of > > this is that for an ACE with no matches defined at all, we match any > > packet. I think we can update the text to better explain this. > > > > > > > >> Otherwise if the ACL type is "any-acl" then this only allows two types > >> of ACLs to be defined, neither of which seem to be particularly > >> useful: > >> (1) An ACL that matches all traffic and permits it, i.e. the same as > >> having no ACL at all. > >> (2) An ACL that matches all traffic and drops. > >> > >> So I think perhaps the answer here is to define neither ACL type > >> "any-acl" nor leaf "any". The presumption could be that any ACE that > >> is > >> configured to match no fields implicitly matches all packets (because > >> all non specified fields are treated as wildcards), and then applies > >> the > >> permit/deny rule associated with the ACE. This logic can apply to all > >> ACL types. > > > > Yes yes yes :) > > > > Kristian. > > Mahesh Jethanandani > mjethanandani@gmail.com >
- Re: [netmod] IETF ACL model Mahesh Jethanandani
- Re: [netmod] IETF ACL model Robert Wilton
- Re: [netmod] IETF ACL model Martin Bjorklund
- Re: [netmod] IETF ACL model Robert Wilton
- Re: [netmod] IETF ACL model Kristian Larsson
- Re: [netmod] IETF ACL model Robert Wilton
- Re: [netmod] IETF ACL model Mahesh Jethanandani
- Re: [netmod] IETF ACL model Martin Bjorklund
- Re: [netmod] IETF ACL model Mahesh Jethanandani
- Re: [netmod] IETF ACL model Mahesh Jethanandani
- Re: [netmod] IETF ACL model Kristian Larsson
- Re: [netmod] IETF ACL model Kristian Larsson
- Re: [netmod] IETF ACL model Mahesh Jethanandani