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

Eliot Lear <lear@cisco.com> Tue, 31 October 2017 10:49 UTC

Return-Path: <lear@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 C580C138103 for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 03:49: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 liTEw4Jw4Dhz for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 03:49:20 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D50413B1B2 for <netmod@ietf.org>; Tue, 31 Oct 2017 03:49:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3138; q=dns/txt; s=iport; t=1509446959; x=1510656559; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=kYuzGXg/5wBR/lAI+0WLBloQmH8jlXe7nRksJM0E0f4=; b=DGALYdthXWzwHMfkoU2TXK+eiLo4hM4hMEXvL3A3NAMLe0QhOCQE84SK hmxFnvFZtDuMPvm0pXCOKhq8eXB7BGxZo7bnTIYgLRDJnjQWx5WVdnOkm 91ZZutPcLlj4J0t+XA91V44/P0Ans6oAqjmU2E7GhDoscaIPYBSUY81ei E=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CjAQD1U/hZ/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBhTGEI4sTj3cmfJVGghEHA4U7AoUmFwECAQEBAQEBAWsohR4BBAEjWwsLQgICVwYBDAgBAYoXCKg6gieLCAEBAQEBAQEDAQEBAQEBARIPgy6FQykLgkE1iCaCYQWiBIRCgiOOF4t0hzqWEoE5IAE2gWg0IQgdFUmCZYRfQIogLIIWAQEB
X-IronPort-AV: E=Sophos;i="5.44,323,1505779200"; d="asc'?scan'208";a="658408561"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2017 10:49:17 +0000
Received: from [10.61.239.244] ([10.61.239.244]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v9VAnGMb016780; Tue, 31 Oct 2017 10:49:16 GMT
To: Kristian Larsson <kristian@spritelink.net>, "netmod@ietf.org" <netmod@ietf.org>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se>
From: Eliot Lear <lear@cisco.com>
Message-ID: <2c541487-2243-766f-0cdf-6545332cad83@cisco.com>
Date: Tue, 31 Oct 2017 11:47:54 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171031102523.GB25608@spritelink.se>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="j0ePNQWjanKneEs26WnVtx1mcWSJ5L190"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zVpBW5noi8Lh9lG7aQW1citEitM>
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: Tue, 31 Oct 2017 10:49:22 -0000

Hi Kristian,

Just my view below:


On 10/31/17 11:25 AM, Kristian Larsson wrote:

> This brings us to the acl-type. It seems to me that this is
> primarily for being able to do YANG validation when a device does
> NOT support a unified model. I.e. if Linux nftables was all we
> wanted to model, then we wouldn't need this and the only
> (implied) acl-type would be l2-l3-ipv4-acl. In reality though, we
> need acl-type because most current network devices out there have
> per-AFI types and we want to be able to say:
>  * this interface attachment point can only do ipv4-acl
> And still be able to validate the data based on the YANG model.
> Is this correct? It seems like one hell of a design trade-off to
> be able to achieve that. Wouldn't we be better off with actually
> having different list of ACLs, again vastly simplifying the
> attachment points and making data validation much easier?

This reflects, IMHO, the complexity of the situation.  You want
consistent policy implemented to the full extent of device
capabilities.  That means that if someone wants to generate a mixed mode
ACL, they can.  But if we attempt to separate those mixed modes on the
device, can we guarantee that we have gotten the intent correct and
consistent with, say, what would have been the mixed mode?  I think
that's how we got here but others can speak more authoritatively.  And
keep in mind, all of this ties to efficient use of device resources, and
so there's a lot of h/w optimization seemingly going on here.

Eliot