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

Dean Bogdanovic <ivandean@gmail.com> Thu, 02 November 2017 10:36 UTC

Return-Path: <ivandean@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 E7E5013F66E for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 03:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 Iiv7mWdK6XYg for <netmod@ietfa.amsl.com>; Thu, 2 Nov 2017 03:36:07 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 1D2BF13F666 for <netmod@ietf.org>; Thu, 2 Nov 2017 03:36:07 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id b15so5780981qkg.9 for <netmod@ietf.org>; Thu, 02 Nov 2017 03:36:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ti1aabCZaAYs1BKuemfWAEMxm1NPF9EROA664+ZS3gI=; b=Tr5rlaO3GufKnbYZ0p6JMdlxSh9HjKkYYykzOFOegmk5xwCnc1oMS5B/pkUfCtVSfO iVNB0qa61dQJJtHrfl8gRX05onQ9ZUpk2RQMJIcV6l8qvxo+zM4+pUcB4gK41HMIK/8s HJr84bIGlhzvFVqTZ3EY9BPVF4848RRkMxKZ3L1vY0LG2sbLQJMNtRmvu95iA92ASkgM rSkK+g2D7YZf93VQs9tWKIEXvIzyVKWTD4K4KLVIRiUjs7d/8P/6XgKIirtxBIDzkPjE CVemcGOSZNuf36eetHXdbT1YgA4jSM5VolrR7qhRfWXUK7TOVbLCOYiZmvw3iclKKkW8 i7bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ti1aabCZaAYs1BKuemfWAEMxm1NPF9EROA664+ZS3gI=; b=YiQQgBCtFeevhP5zHP8oXBFvHPdEzCG5IzX1p4cFdAhyjyZeZQYfNHtSoNQT7Xs+lr ufBkBd9sRTagpNzL0GB3r3raO+nCqaIpBaMydmoj9cfSxAtDzB8kKjyIV4xARaqdn/nd AsMp87kkTB79OWN+wfTfJJCaeSb6WMd9mP2G8Q5CfYOZ+rOqeIG0wH+y08VoRPhjpFGC BI78GbSM7gjIEmQbBzXB5bBlxEQgxHxPPI/Vam8qH9myya7FNMtvoZvMyqGUWKg832oh zVpGgFXVdlGB2DZN4yQeIlgLLYKeUCBL0uBieeYLB7grC7PzYuzBqwD1/bIZKyHktMfK AAsQ==
X-Gm-Message-State: AMCzsaVYgREOJiDVmA/BUzNaqXCV8/CdWRHWfFEHOzMcHtWFEW4v6Wfw Je1378di0OAgG+iilVPhWhQ=
X-Google-Smtp-Source: ABhQp+S4EY0m0LwYF7C6wyCRE2frmFnNfeCK7z/QOOI9gfmex/RjptnchCiV3cmxlANhjOfoncGXeA==
X-Received: by 10.55.191.195 with SMTP id p186mr4064757qkf.152.1509618966118; Thu, 02 Nov 2017 03:36:06 -0700 (PDT)
Received: from ?IPv6:2601:19b:880:14c8:683e:6d99:664a:3459? ([2601:19b:880:14c8:683e:6d99:664a:3459]) by smtp.gmail.com with ESMTPSA id m6sm1878459qkh.90.2017.11.02.03.36.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 03:36:05 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dean Bogdanovic <ivandean@gmail.com>
In-Reply-To: <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>
Date: Thu, 02 Nov 2017 06:36:03 -0400
Cc: Kristian Larsson <kristian@spritelink.net>, "netmod@ietf.org" <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BDDF286-4B72-4EE6-9CC2-07BBCDA6F53E@gmail.com>
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> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wHhqiHi_qAm7Daor8yQVENwibkk>
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 10:36:09 -0000

I agree with points raised by Juergen and Kristian. Because of design changes I have stepped down as co-author of the draft.

> On Nov 2, 2017, at 4:50 AM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> 
> 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
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod