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

Kristian Larsson <kristian@spritelink.net> Tue, 31 October 2017 11:37 UTC

Return-Path: <kristian@spritelink.net>
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 3070713F439 for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 04:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 oaWuce1ZfxMQ for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 04:37:51 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCEF13F62F for <netmod@ietf.org>; Tue, 31 Oct 2017 04:37:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id E15C2261846; Tue, 31 Oct 2017 12:37:50 +0100 (CET)
X-Virus-Scanned: amavisd-new at SpriteLink.NET
Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeXvpfBdXsiU; Tue, 31 Oct 2017 12:37:45 +0100 (CET)
Received: from localhost (Mission-Control.SpriteLink.NET [195.182.5.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 4DBE4261838; Tue, 31 Oct 2017 12:37:45 +0100 (CET)
Date: Tue, 31 Oct 2017 12:37:43 +0100
From: Kristian Larsson <kristian@spritelink.net>
To: Eliot Lear <lear@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20171031113743.GC25608@spritelink.se>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <2c541487-2243-766f-0cdf-6545332cad83@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2c541487-2243-766f-0cdf-6545332cad83@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7HpV8zxCZywcJtPMYn4J9mjLyNQ>
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 11:37:54 -0000

On Tue, Oct 31, 2017 at 11:47:54AM +0100, Eliot Lear wrote:
> 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.

I'd argue we are not achieving that anyway because of the
previously mentioned container mess. I.e. on a a Cisco I'd have
to do matches/ipv4-acl/foo while on my Linux machine I'd do
matches/l2-l3-ipv4-ipv6-acl/foo. Thus multiple ACLs need to be
generates for any heterogenous network. We missed the goal with
the model.


>  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.

So how is the current situation better than doing:

module: ietf-access-control-list
    +--rw access-lists
       +--rw acl [acl-name] <<< this is the unified one
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ethernet
       |        |  +--rw ipv4
       |        |  +--rw ipv6
       |        ...

       +--rw ipv4-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

       +--rw ipv6-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

I'm really bothered by the compound key consisting of acl-type
and the acl-name since attachment points then need to reference
both.  It's also weird because I don't think choosing the
acl-type is really a choice of the user but more of a limitation
of the platform.

One approach would be to change the key to only be the acl-name
but let the acl-type leaf remain, perhaps make it mandatory or
default to some unified acl-type. I think it's still possible to
implement a constraint on this, right? Like if a platform only
supports a specific type at some attachment point it can add a
constraint on the acl-type by doing deref() on the leafref.

module a-vendor-module {
  list interfaces {
		leaf ingress-acl {
		  type leafref {
			  path "/acl:access-lists/acl/acl-name";
			}
			must 'yangexp:deref(.)/../acl-type="ipv4-acl"';
		}
  }
}

I think that looks much nicer. Am I missing something?

It would create a single namespace for all ACL types which is
potentially a problem for some vendors when doing backwards
mapping, like they have separate ipv4 and ipv6 acls today and
when starting to support this new model you could end up in a
collision. But if that is the case, would it not be okay to just
prefix the type to the name as part of the data translation?

Kind regards,
   Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
+46 704 264511                                kll@spritelink.net