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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 02 November 2017 08:50 UTC

Return-Path: <mjethanandani@gmail.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 2316613FA74 for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 01:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fi_65-Avr_f2 for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 01:50:38 -0700 (PDT)
Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2269113F89D for <netmod@ietf.org>; Thu, 2 Nov 2017 01:50:38 -0700 (PDT)
Received: by mail-io0-x242.google.com with SMTP id p186so12165041ioe.12 for <netmod@ietf.org>; Thu, 02 Nov 2017 01:50:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=DJG+f+xFnibAc9FibBFS/C416QXBQw3ibFR90Fbjsk0=; b=RzV3GtOLaiqTAQ/QMnfT5qjqCOuUlhFyGnsiwfMEy1DoR8/6H2d2iBaI3Iri6Pat1j dLkz2yRG0CAVNX8RpcZ4RjgD2H4o2msGZtK/Km1qAHkCpMF+ZlEkC9UOu1OxfWog7E2c cpBn5twU5sYpZTsAuTXIWhP3aoA4967IWafgCnYsUWifeqji/FQHOt4t/TEB0c3s3uyt 2jw1cYl/njSR1fXVTZWuO7gYyBA2M2TcxG4aX+O+spzKUNBNxnLBXBfZeXmZwT44wBw3 URFCHrsprAqYMfGxHgX5iyjIO4DMJINaeoSWItPhGYvIYzuhEaUz0ifpFNZY0K7wjDXW bHvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=DJG+f+xFnibAc9FibBFS/C416QXBQw3ibFR90Fbjsk0=; b=HC6wws3+ZJMuZq9ZdEl5Oe2w+XjdqZhRk44/rsTYD5ilnPHHN1TjD2i6bVKvqJS7lm O3POOV+npiSFMYqfxeqohtJ36DpELH0X+Nj0cKcswfxU420px3fMZ7bdyT2SRLO5Osi5 YMYZiHV/ONbqjTa+VwqJwKSNOYCG3SMVZ9+rYrvXM0HZIJX3P6sJY+Lti/XZYOymC9e5 loPAmP4VkK3dKLsULpktZF9qwEzi4byX7moyo2Eicac5neBgmxy1N0swArDQSCMASBhT rwXCPJJC/V2jy9JNMXTjjI2IQKKeC8g4A5CxjRGXtFt4TeFXlulba9ZLxSweBmMX8/zJ Tu8Q==
X-Gm-Message-State: AJaThX5NtXvEstvfLjfjlATybVfbAeqjpsJypBhtXrxos/r7uw8YHpuZ 6bEHMJDvRX/L4NmKuOUZIFCeCY/W
X-Google-Smtp-Source: ABhQp+RBBZMzOg4OZx52p4Nh53G5N7uBqfeFKqzfiU6DMQ7Kyov23bxGUL/Ek9ELpu0v2+DYeohoHA==
X-Received: by 10.107.68.10 with SMTP id r10mr3579366ioa.202.1509612637349; Thu, 02 Nov 2017 01:50:37 -0700 (PDT)
Received: from [192.168.1.199] ([103.25.76.180]) by smtp.gmail.com with ESMTPSA id x137sm1540308itb.37.2017.11.02.01.50.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Nov 2017 01:50:36 -0700 (PDT)
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> <20171102074318.GC12688@spritelink.se>
Mime-Version: 1.0 (1.0)
In-Reply-To: <20171102074318.GC12688@spritelink.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
X-Mailer: iPad Mail (13G36)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Date: Thu, 2 Nov 2017 15:20:34 +0630
To: Kristian Larsson <kristian@spritelink.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Sdmlypkb0pmRCBwkjGhHpB8UjSQ>
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 08:50:40 -0000

Kristian,

I hear you. What I am providing is the rational for the current design. 

I would like to hear from others in the WG. We have been reviewing this draft for the last couple of years, and we are now at the tail end of the LC. I would really like to see this draft move forward, particularly since it is not broken.

Thanks.

> On Nov 2, 2017, at 2:13 PM, Kristian Larsson <kristian@spritelink.net> wrote:
> 
>> 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.

Mahesh Jethanandani
mjethanandani@gmail.com