Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Kristian Larsson <kristian@spritelink.net> Thu, 02 November 2017 07:43 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 5545413F9EB for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 00:43:25 -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 fs2dQjONAFZ1 for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 00:43:22 -0700 (PDT)
Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 520EF13F5FE for <netmod@ietf.org>; Thu, 2 Nov 2017 00:43:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 8E684261846; Thu, 2 Nov 2017 08:43:22 +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 bgsvFNWB+O0S; Thu, 2 Nov 2017 08:43:20 +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 34AB9261838; Thu, 2 Nov 2017 08:43:20 +0100 (CET)
Date: Thu, 02 Nov 2017 08:43:18 +0100
From: Kristian Larsson <kristian@spritelink.net>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20171102074318.GC12688@spritelink.se>
References: <51DBEB86-2482-4D37-9F97-5EEE76B38285@juniper.net> <20171031102523.GB25608@spritelink.se> <CDEF081E-C5AA-459B-8DBB-770D5065FD26@gmail.com> <20171101112249.wmq4ggx2ixgn4kqo@elstar.local> <A55809F6-23FA-404D-BC0F-74AF11F508BF@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <A55809F6-23FA-404D-BC0F-74AF11F508BF@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/F0Vc81wE6NKJ7yd0cWCV-U8lPTc>
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 07:43:25 -0000
On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote: > On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > Mahesh, > > I think the question is why we need to have different match containers > for each possible feature set combination instead of having a single > match container with groups of leafs in it marked as features. This > would seem to cut down the size of the module and the tree diagram > significantly. I think this will also make clients simpler sicne they > do not have to select a certain container based on the feature set > announced. > > > The current design of match containers was chosen to allow platforms to select > one container that matched what the hardware supported from a l2, l3 and ipv > {4,6} perspective. Sure, but you are conflating the structure of the model with the feature-wraps. Without changing the features of the model, we can structure it in a different way where there is not a 1:1 mapping between features and containers under the matches container. > I would argue that even though the overall diagram is bigger > with this design, once the platform selects the container of choice, the tree > and the configuration itself would be a little simpler/smaller. I am arguing the opposite. It's really awkward to place the same type of data, like IPv4 match conditions, under different paths based on a feature. If the system model had done the same we would have: /system /system-with-ntp /system-with-ntp-and-radius How do you augment in new leaves? While you are using groupings which allows for a reuse of data across all these containers, someone who is augmenting can't, since you can't augment a container, only where it is used. Someone wishing to add a leaf to the model needs to augment in three different locations to support a new match condition for IPv4 (let's say some meta-data attribute). > Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The current > tree looks like this: > > > | | +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}? > | | | +--rw destination-mac-address? yang:mac-address > | | | +--rw destination-mac-address-mask? yang:mac-address > | | | +--rw source-mac-address? yang:mac-address > | | | +--rw source-mac-address-mask? yang:mac-address > | | | +--rw ethertype? eth:ethertype > | | | +--rw dscp? inet:dscp > | | | +--rw ecn? uint8 > | | | +--rw length? uint16 > | | | +--rw ttl? uint8 > | | | +--rw protocol? uint8 > | | | +--rw source-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operation? operator > | | | +--rw destination-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operations? operator > | | | +--rw ihl? uint8 > | | | +--rw flags? bits > | | | +--rw offset? uint16 > | | | +--rw identification? uint16 > | | | +--rw destination-ipv4-network? inet:ipv4-prefix > | | | +--rw source-ipv4-network? inet:ipv4-prefix > | | | +--rw next-header? uint8 > | | | +--rw destination-ipv6-network? inet:ipv6-prefix > | | | +--rw source-ipv6-network? inet:ipv6-prefix > > | | | +--rw flow-label? > | | | inet:ipv6-flow-label > > > > whereas, if the design went with one match container with each group of leafs > in their own container (to support the if-feature statement for that > container), the tree would look like this: > > > | | +--rw l2-acl {l2-acl}? > | | | +--rw destination-mac-address? yang:mac-address > | | | +--rw destination-mac-address-mask? yang:mac-address > | | | +--rw source-mac-address? yang:mac-address > | | | +--rw source-mac-address-mask? yang:mac-address > | | | +--rw ethertype? eth:ethertype > > | | +--rw ipv4-acl {ipv4-acl}? > | | | +--rw dscp? inet:dscp > | | | +--rw ecn? uint8 > | | | +--rw length? uint16 > | | | +--rw ttl? uint8 > | | | +--rw protocol? uint8 > | | | +--rw source-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operation? operator > | | | +--rw destination-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operations? operator > | | | +--rw ihl? uint8 > | | | +--rw flags? bits > | | | +--rw offset? uint16 > | | | +--rw identification? uint16 > | | | +--rw destination-ipv4-network? inet:ipv4-prefix > | | | +--rw source-ipv4-network? inet:ipv4-prefix > | | +--rw ipv6-acl {ipv6-acl}? > | | | +--rw dscp? inet:dscp > | | | +--rw ecn? uint8 > | | | +--rw length? uint16 > | | | +--rw ttl? uint8 > | | | +--rw protocol? uint8 > | | | +--rw source-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operation? operator > | | | +--rw destination-port-range! > | | | | +--rw lower-port inet:port-number > | | | | +--rw upper-port? inet:port-number > | | | | +--rw operations? operator > | | | +--rw next-header? uint8 > | | | +--rw destination-ipv6-network? inet:ipv6-prefix > | | | +--rw source-ipv6-network? inet:ipv6-prefix > | | | +--rw flow-label? inet:ipv6-flow-label > > > The difference though is small and comes down to a preference. Select one > feature statement and get one container with everything in it, or define > multiple feature statements and assemble together the pieces to define the ACE > entry. Again, I think you mix up the features available vs the structure of the data. This is the current list of features (which again, I want to change but that's separate): * l2-acl * ipv4-acl * ipv6-acl * mixed-ipv4-acl * mixed-ipv6-acl * l2-l3-ipv4-ipv6-acl * tcp-acl * udp-acl * icmp-acl * any-acl As per your second example above we have an ipv4-acl container under matches, i.e. /access-list/acl/aces/ace/matches/ipv4-acl. It is only possible to define ipv4 matches if one of the following features are present: * ipv4-acl * mixed-ipv4-acl * l2-l3-ipv4-ipv6-acl Thus you write an if-feature statement to reflect that, like this: if-feature "ipv4-acl mixed-ipv4-acl l2-l3-ipv4-ipv6-acl"; So you see, the tight coupling you have between the data structure and the if-features isn't necessary. I think the structure should first be established without features and then features can be inserted where they make sense to make part of the model optional. Starting with the list of features and then designing the structure around them makes for a much less natural data structure IMHO. Kind regards, Kristian.
- [netmod] WG Last Call: draft-ietf-netmod-acl-mode… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Acee Lindem (acee)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Acee Lindem (acee)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Dean Bogdanovic
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Thomas Nadeau
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal