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

Kristian Larsson <kristian@spritelink.net> Thu, 02 November 2017 16:41 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 3153513F706 for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 09:41:55 -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 wKuFH9XBvvtn for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 09:41:52 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5F99513F736 for <netmod@ietf.org>; Thu, 2 Nov 2017 09:41:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 8E35A261846; Thu, 2 Nov 2017 17:41:53 +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 ELUSx69oS3Gy; Thu, 2 Nov 2017 17:41:51 +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 61DD3261838; Thu, 2 Nov 2017 17:41:51 +0100 (CET)
Date: Thu, 2 Nov 2017 17:41:49 +0100
From: Kristian Larsson <kristian@spritelink.net>
To: Robert Wilton <rwilton@cisco.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, mjethanandani@gmail.com, netmod@ietf.org
Message-ID: <20171102164149.GD12688@spritelink.se>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <c90aa6c1-340e-2225-f960-73c1395041c5@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Q9QhVZiYot8eQquJV3PGIJ4e6qY>
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: Thu, 02 Nov 2017 16:41:55 -0000

On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
> One further refinement might also be to make the ACL type features a bit more
> hierarchical as well, but I don't know if that makes it too complex?

I was pondering this for a bit but I'm not sure it actually
helps.

> For example, the model could define separate features for what type of ACE
> matching is supported by the device, separately from what types of ACE
> combinations are allowed.
> 
> E.g.
> 
> // New 'match type' features.
> 
> feature match-on-l2-eth-hdr {
>    // Device can match on L2 Ethernet header fields.
> }
> feature match-on-ipv4-hdr {
>    // Device can match on IPv4 header fields.
> }
> feature match-on-ipv6-hdr {
>    // Device can match on IPv6 header fields.
> }
> 
> 
> The existing ACL type features could then depend on these:
> 
> 
>   feature l2-acl {
>     if-feature "match-on-l2-eth-hdr";
>     description "Layer 2 ACL supported";
>   }
> 
>   feature ipv4-acl {
>     if-feature "match-on-ipv4-hdr";
>     description "Layer 3 IPv4 ACL supported";
>   }
> 
>   feature ipv6-acl {
>    if-feature "match-on-ipv6-hdr";
>    description "Layer 3 IPv6 ACL supported";
>   }
> 
>   feature mixed-ipv4-acl {
>     if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
>     description "Layer 2 and Layer 3 IPv4 ACL supported";
>   }
>   ...

Features dependent on features... inception. I didn't even know
this was possible with YANG. Learned something today \o/

Anyway, I don't think you can actually deduce that a device
supports an ACL that maches on ethernet and IPv4 based on that it
supports matching on Ethernet headers and IPv4 headers.

For example, on IOS XR there are "ethernet-service access-list"
which can match on Ethernet headers but they are distinct from
ipv4 access-list and they use different attachment points under
an interface. IPv6 is yet another ACL with its own attachment
point... you cannot mix them in the same ACL. I guess they are
logically evaluated in order, so ethernet first, and if it passes
that then the ipvX ACL is evaluated. I believe the situation is
similar on JUNOS.

Which brings us to how to define attachment points. By using YANG
features a device can declare what ACL types it supports but if
the device has different attachment points then there should
probably be some constraint on what ACL type is attached where.

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?

An example (from the top of my head so excuse syntax errors):


grouping interface-attach {
  choice attach-style {
    case mixed {
      if-feature mixed-acl;
      leaf-list mixed {
        description "Any type of ACL that can match on ethernet, ipv4, ipv6 or anything else";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name"; // we can apply any acl-type
        }
      }
    }

    case specific-acl {
      if-feature specific-acl;

      leaf-list ethernet {
        description "ACL for Ethernet";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name";
        }
        must 'derived-from(deref(.)/../acl-type, eth-acl)';
      }

      leaf-list ipv4 {
        description "ACL for IPv4";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name";
        }
        must 'derived-from(deref(.)/../acl-type, ipv4-acl)';
      }

      leaf-list ipv6 {
        description "ACL for IPv6";
        ordered-by user;
        type leafref {
          path "/access-list/acl/acl-name";
        }
        must 'derived-from(deref(.)/../acl-type, ipv6-acl)';
      }
    }
  }
}

// ACLs attached under interface, like most big routers do it
augment "/if:interfaces/if:interface" {
  if-feature interface-acl;
  container acl {
    description
      "ACL attachment point";

    container ingress {
      uses interface-attach;
    }
    container egress {
      uses interface-attach;
    }
  }
}


// ACL globally attached, like on a Linux machine
augment /access-list {
  if-feature global-attach;
  leaf system-acl {
    type leafref {
      path "/access-list/acl/acl-name";
    }
  }
}


Kind regards,
   Kristian.

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