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

Robert Wilton <rwilton@cisco.com> Thu, 02 November 2017 17:38 UTC

Return-Path: <rwilton@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 7584B13F6ED for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 10:38:08 -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 hp8m-cG6Rmc6 for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 10:38:06 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5F013F474 for <netmod@ietf.org>; Thu, 2 Nov 2017 10:38:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7441; q=dns/txt; s=iport; t=1509644286; x=1510853886; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yldBb0evydy/T25cDSPo1sys4PfoaPwGfr13CFw4qMk=; b=HK0PFnNz37YN50b5e6VkM0oOEhoU8D8966bQ7zcYBxbKkpgRB1Tme0Pm alIAHKpuHD42NyPL9I0kRbxknhE2FtbhjsAku/5G4egayXBbCCxwNhqyX exSLhsaBeIJ+GqICSWMtABOtT/jE5luzlww8V0B6AElP83V3QvEUptVGD I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAABTV/tZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIofdJAilkWCEQqFOwKFDxgBAQEBAQEBAQFrKIUdAQEBAwE?= =?us-ascii?q?jDwEFQRALGAICJgICVwYNCAEBihcIqSmCJ4sTAQEBAQEBAQEBAQEBAQEBAQEhg?= =?us-ascii?q?Q+CH4NaghKDAYgmgmIFkV6QL4tNiS+LeIc6jimHbYE5HziBbDQhCB0VSYJlgls?= =?us-ascii?q?cgWdBjXkBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,335,1505779200"; d="scan'208";a="18273"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2017 17:38:04 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA2Hc2ND005396; Thu, 2 Nov 2017 17:38:02 GMT
To: Kristian Larsson <kristian@spritelink.net>
Cc: Martin Bjorklund <mbj@tail-f.com>, mjethanandani@gmail.com, netmod@ietf.org
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> <20171102164149.GD12688@spritelink.se>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com>
Date: Thu, 2 Nov 2017 17:38:02 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171102164149.GD12688@spritelink.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/P0_CTJghOjpCwji4FfyZ-ZHxSIA>
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 17:38:08 -0000


On 02/11/2017 16:41, Kristian Larsson wrote:
> 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/
This just means that a device cannot say that it supports a 
"mixed-ipv4-acl" ACL unless it supports classifying traffic on Ethernet 
and classifying traffic on IPv4.

So the 'match type' feature specify what header fields the hardware is 
capable of match on.  E.g. a basic L2 device might say that is only 
matches on the Ethernet header.

The "ACL types" features specify what combination of header fields can 
be combined into a single ACL.

The real benefit for defining "match type" is that the unsupported 
fields in the ACL can then be cleanly left out of the device schema.  
E.g. a hypothetical new breed of IPv6 only routers that only support 
matching on match-on-ipv6-hdr, and don't want to carry v4 baggage.

>
> 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.
The YANG is stating the reverse:
  - You can enable the feature that matches on mixed ACLs, if and only 
if, you support matching on Ethernet header fields and IPv4 header fields.


>
> 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.
So for XR, you might just list the following features:

feature match-on-l2-eth-hdr;
feature match-on-ipv4-hdr;
feature match-on-ipv6-hdr;
feature l2-acl;
feature ipv4-acl;
feature ipv6-acl;

I.e. it individually supports L2, v4, and v6 ACLs, but a given ACL cannot have mixed entries.

Probably the vendors would need to augment this module with addition configuration restrictions to which ACLs can be applied together on an interface.  E.g. either an L2 or L3 ACL.  If an L3 ACL it can either be a v4 ACL, a v6 ACL, or one of each.

>
> 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.
I think that this is probably hard to encode in a generic model.  As per 
above, I suspect that such constraints may be more cleanly implemented 
as vendor specific deviations.

>
> 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?
For interface attachments I think that the approach in the draft looks 
OK, and reasonably generic, but will need vendor deviations. This is 
probably OK.

Personally, I would put the ACL interface attachment points as an 
augmentation of if:interfaces/interface rather than having a separate 
top level list, but perhaps that is just want I am used to ...

Thanks,
Rob


>
> 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;
>      }
>    }
> }
I think that the existing model is g
>
>
> // 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.
>