Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-08

Sam Aldrin <aldrin.ietf@gmail.com> Tue, 23 August 2016 06:41 UTC

Return-Path: <aldrin.ietf@gmail.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 CCC7312B04D for <netmod@ietfa.amsl.com>; Mon, 22 Aug 2016 23:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RemZuEKd6NVS for <netmod@ietfa.amsl.com>; Mon, 22 Aug 2016 23:41:37 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EAF612B006 for <netmod@ietf.org>; Mon, 22 Aug 2016 23:41:37 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id 97so229039075uav.3 for <netmod@ietf.org>; Mon, 22 Aug 2016 23:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/59NUl0k2ojOckf4uiFD8ckfAiWr88TpxEf7ZsgUu1A=; b=h1tcje7d5KXVpDZPtiR4uCPDaitWGRx5vhq2CFNzRaXtmQBuDTdIIOfa97AqQfa7hu mkqv/a7iZFRKuHLFHNiWSDSSLYn/Cu6WAZrbqK4vhrwt9XcK0FDCU7kb7TP1OF/yoaG5 Yeo7UhSWwtPFSmU4H4Tc6M/fJfxzWWJvZgOdTtCnzpkg11uIuIiRcuqPYhpnS9XWEyVg Q3iG5ivZjh7ZNxnBxaSXjE+lK5hrWXK1LyPbITF+Ynb8YVW5G3OXrloXq3jBLNswGvH8 FeP2XzaL/uoY6g+5WCHjPV5x9PSSaNCRMnxaPl6J4LevwX0UI5tkyjXcOb433bE0YF/G rm2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/59NUl0k2ojOckf4uiFD8ckfAiWr88TpxEf7ZsgUu1A=; b=iJCKLjVjBDJ9M/BRCgDKqd6jBUtxdbXMFt2FMUZ+grTDrR/ZHXIc4PITPI8eEXgZue DiDHC9Bc4hkCzFJDJtyS2mg5ihbUInm8mqIhcHkggpnrq3bQL90Bv6WKBvHnM6FvFQvI 5ZajFOth5sVewL6SlNWHy20AbI30XWhddMQfo80ZeBxT9f1HK0tsvF50NiqJUch2Acnv rBMPvbOIkLy/PuAkwyWNdfCIbzpMCxNWYvxL1AEonuHxe7M9iO7TfT4+GVL1QOl4wqEm RP0JmPavxJc394bXoSjHbXwA/xp171SsavOhuDumevpJiY1lhEXLnpcRZwu3pWA5CMtG tWEQ==
X-Gm-Message-State: AEkoouu6dWdzbRtBncTaU0SsJzpUhw1AlvIgdtZq0susNOiZmzRCOsRaWAYJ3IIMxkJv9Fjmug9PhEZAlFIbQg==
X-Received: by 10.31.227.196 with SMTP id a187mr3485653vkh.89.1471934496443; Mon, 22 Aug 2016 23:41:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.7.41 with HTTP; Mon, 22 Aug 2016 23:41:35 -0700 (PDT)
In-Reply-To: <7F859F89F9B4DD4DB902232F9E2DAC083873C9AD@ESGSCMB103.ericsson.se>
References: <7F859F89F9B4DD4DB902232F9E2DAC083873C373@ESGSCMB103.ericsson.se> <B4BF42A6-9642-457D-9CA6-B22B3303A3FD@gmail.com> <7F859F89F9B4DD4DB902232F9E2DAC083873C9AD@ESGSCMB103.ericsson.se>
From: Sam Aldrin <aldrin.ietf@gmail.com>
Date: Mon, 22 Aug 2016 23:41:35 -0700
Message-ID: <CA+C0YO2mJiZbG0b3=4s+s4s9AmuR-ruYT8yJ7fXz5xwLP1zEfg@mail.gmail.com>
To: Adrian Pan <adrian.pan@ericsson.com>
Content-Type: multipart/alternative; boundary="001a114e0198cb11ce053ab7743d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YCNCC6KbNnQSin4MmB5pMMZw0Q8>
Cc: netmod WG <netmod@ietf.org>, "kkoushik@cisco.com" <kkoushik@cisco.com>
Subject: Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Aug 2016 06:41:40 -0000

Model design shouldn't be limited by the device capabilities, rather it
should be agnostic.
The existing IETF model is more of a YANG version of CLI, which is rather
limiting from operational perspective.

How do we (operators) like to see ACL model should be? take a look at the
model we published (work in progress) at <
https://github.com/openconfig/public/tree/master/release/models/acl>

-sam

On Mon, Aug 22, 2016 at 7:04 AM, Adrian Pan <adrian.pan@ericsson.com> wrote:

> Hi Dean,
>
>
>
> 3)   With the model definition, even the acl-type is configured as
> Ethernet, the operator still can configure the matches of ace under the
> acl as ipv4 or ipv6, right?
>
>
>
> No, if ACL type is ethernet, then all ACEs are expected to be ethernet.
>
> [Adrian] I understand your point, but this is not reflected in the model,
> if according to the model, the operator still can configure the acl-type
> as Ethernet, while configure the ace of the acl as ipv4, and this should
> be valid configuration.
>
> is this the model design intention?
>
>
>
> If acl-type is of one family, then only ace with match condition from
> that family are expected to be in the acl. If you want to combine them,
> please use mixed type.
>
> [Adrian] if it’s only expected to be the same as the acl-type, but
> without the restriction in the model, you can’t avoid the operator
> configuration to mix the acl-type and the ace matches. So my thinking is
> that, can we add the restriction in the model for this as below to better
> reflect the model design intention?
>
>
>
>
>
>
>
> container matches {
>
>   description
>
>     "Definitions for match criteria for this Access List
>
> Entry.";
>
>
>
>   container ace-ipv4 {
>
>     when "../../acl-type='ipv4-acl'";
>
>     description "IPv4 Access List Entry.";
>
>     uses packet-fields:acl-ip-header-fields;
>
>     uses packet-fields:acl-ipv4-header-fields;
>
>   }
>
>   container ace-ipv6 {
>
>     when "../../acl-type='ipv6-acl'";
>
>     description "IPv6 Access List Entry.";
>
>     uses packet-fields:acl-ip-header-fields;
>
>     uses packet-fields:acl-ipv6-header-fields;
>
>   }
>
>   container ace-eth {
>
>     when "../../acl-type='eth-acl'";
>
>     description
>
>       "Ethernet Access List entry.";
>
>     uses packet-fields:acl-eth-header-fields;
>
>   }
>
> }
>
>
>
>
>
> Thanks
>
> Adrian
>
>
>
> *From:* Dean Bogdanovic [mailto:ivandean@gmail.com]
> *Sent:* Monday, August 22, 2016 5:39 PM
> *To:* Adrian Pan <adrian.pan@ericsson.com>
> *Cc:* kkoushik@cisco.com; lyihuang16@gmail.com; dblair@cisco.com; netmod
> WG <netmod@ietf.org>
> *Subject:* Re: Question about acl-type in draft-ietf-netmod-acl-model-08
>
>
>
> (+netmod mailing list)
>
> Adrian,
>
>
>
> Please see inline
>
> On Aug 22, 2016, at 2:27 AM, Adrian Pan <adrian.pan@ericsson.com> wrote:
>
>
>
> Dear authors,
>
>
>
> I have some questions about ietf acl model as below, your reply is
> appreciated.
>
>
>
> 1)   In the model definition acl-type is one key of the acl, also in the
> description it says that the acl-type could be ethernet, IPv4, IPv6,
> mixed, in case the acl-type is mixed, what’s the identifier should be?
>
> Should it be augmented by different vendor? Since I don’t see the
> definition about it.
>
>
>
> As mixed ACLs are not supported by all vendors, those are not part of the
> standard model. Iit is up to the vendor to augment the ace-type and select
> an identifier to their liking.
>
>
>
> 2)   In the “mix” case, the “matches” the ace list can be the combination
> of Ethernet,ipv4,ipv6 for different ace, right?
>
>
>
> Or another combination, again depends on what that particular vendor
> supports.
>
> 3)   With the model definition, even the acl-type is configured as
> Ethernet, the operator still can configure the matches of ace under the
> acl as ipv4 or ipv6, right?
>
>
>
> No, if ACL type is ethernet, then all ACEs are expected to be ethernet.
>
> is this the model design intention?
>
>
>
> If acl-type is of one family, then only ace with match condition from that
> family are expected to be in the acl. If you want to combine them, please
> use mixed type.
>
>
>
> Dean
>
>
>
> module: ietf-access-control-list
>
>    +--rw access-lists
>
>       +--rw acl* [acl-type acl-name]
>
>          +--rw acl-name               string
>
>          +--rw acl-type               acl-type
>
>          +--ro acl-oper-data
>
>          +--rw access-list-entries
>
>             +--rw ace* [rule-name]
>
>                +--rw rule-name        string
>
>                +--rw matches
>
>                |  +--rw (ace-type)?
>
>
>
>          leaf acl-type {
>
>            type acl-type;
>
>            description
>
>          "Type of access control list. Indicates the primary intended
>
>          type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
>
>          used in the list instance.";
>
>          }
>
>
>
>
>
> Thanks
>
> Adrian
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>