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

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 13 December 2017 20:29 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 DD10E128BBB for <netmod@ietfa.amsl.com>; Wed, 13 Dec 2017 12:29:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 EJiwRCvru2mY for <netmod@ietfa.amsl.com>; Wed, 13 Dec 2017 12:29:38 -0800 (PST)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 0EB1D126FDC for <netmod@ietf.org>; Wed, 13 Dec 2017 12:29:38 -0800 (PST)
Received: by mail-pg0-x22e.google.com with SMTP id o2so1812142pgc.8 for <netmod@ietf.org>; Wed, 13 Dec 2017 12:29:38 -0800 (PST)
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:message-id:references :to; bh=sUnaNq1/TdzpGdR+UZ/XaKfo3WsuT7Vc9qAg2BsdiTA=; b=dg9XvmYY7KLwLmdUFd20YD6Pjv56h/2V82rkJhkQAMbMPXsgULpBokr5qySP3bslxW IF+zYflI2X92tWpqA17eter44nRcIKPyrZbu/f6XZLAyGDqE3UjSLcWpg7VV6dCW3Rk6 M++4yZCmGMMPB3vE8Xi62gJ/JRbU/7z+maKvQk3iUDkXfeVJcUQRbi75FAJU9srE+NQq qpt/NepingmT043gVnubXS45XgTzw8qBZ8yBGfnT9hp8tSFbpdH5azOKsUXE5P1bcUBD aSlisdx8OJdbWYPJCHgTR49q1hx8lcgjESavEPPqDEhWd5tYNqtL2oHeXKpQmEnfncW9 0PmA==
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 :message-id:references:to; bh=sUnaNq1/TdzpGdR+UZ/XaKfo3WsuT7Vc9qAg2BsdiTA=; b=FX+RfoBpTBeejW7JzzVUQ/Or0/Msg+xJXSCgTN2XZ7a65BxoBNSwuBKn0gNWtRkbsq Sx60hNs8NPejFoBuBp/jC2tygtqxxyFNVD8cUjirqYMZj34O6eJ4hnoSEYe4T7e+0WZT c3BVGODjzRHMWJfz8x8oBWOZ22jmH4lJ5J3sQAS+9O209I40RgqM47e1cgf1ZHMfS3EC x5Sano3/F05lNCsFveuT+GEIYjK3l8PJqrTVXMKk6nlmmczhIPmYpeOSHQCDaljKwOF+ d+HQDvRa0Vx8N1KjZI6H9g/dQhzX7eazoGdFfhh02rhejGHX9E/6kQnj9FNHRE0/QPw6 68hg==
X-Gm-Message-State: AKGB3mKmjiwJ1vSYRJqer2gntPUQ8Aqa/22QJTMb1QrMMuHNsugfUzeH iRBt2kg760B0F0eA/+jTlz8Fz80v
X-Google-Smtp-Source: ACJfBoubNmI+2IzbN0Y7tZ8wqeP7DV0v8zJ2v/hR31/rYwMNz6SanWr/NPNgZ6hJ2+3a8p7VGFEDSA==
X-Received: by 10.159.249.9 with SMTP id bf9mr6817842plb.86.1513196977578; Wed, 13 Dec 2017 12:29:37 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:4c65:acaa:7a67:d727]) by smtp.gmail.com with ESMTPSA id j62sm4562577pfc.18.2017.12.13.12.29.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Dec 2017 12:29:35 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_12CCA54D-8FDD-4A65-A7FE-2E935D0D1499"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com>
Date: Wed, 13 Dec 2017 12:29:31 -0800
Cc: Eliot Lear <lear@cisco.com>, Kristian Larsson <kristian@spritelink.net>, "netmod@ietf.org" <netmod@ietf.org>
Message-Id: <FEA5251F-990C-4948-91F6-44AE25E016AE@gmail.com>
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> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <B63D5700-C13B-4D2D-9439-0E4471906374@gmail.com> <a75cf59c-7f5e-0b3b-0ace-ec9be9f67116@cisco.com> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <42A2F0C4-52FD-4894-8D08-092BB2B0772B@cisco.com>
To: "Einar Nilsen-Nygaard (einarnn)" <einarnn@cisco.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/vpL972BREoB6BIBy4g38Mk7lfcA>
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: Wed, 13 Dec 2017 20:29:41 -0000

My understanding is that you would attach an ACL either to an interface or globally. Not both.

> On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:
> 
> I’m happy to have a way to attach an ACL globally, but that’s orthogonal to attaching to an interface, isn’t it? Attaching ACLs directly to an interface doesn’t preclude global attachment in any way as far as I can see…or have I missed something? I’m not sure I understand why choices are an issue. The current proposal has this container:
> 
> module: ietf-access-control-list
>     +--rw access-lists
>        +--rw attachment-points
>           +--rw interface* [interface-id] {interface-attachment}?
>              +--rw interface-id    if:interface-ref
>              +--rw ingress
>              |  +--rw acl-sets
>              |     +--rw acl-set* [name]
>              |        +--rw name    -> ../../../../../../acl/name
>              |        +--rw type?   -> ../../../../../../acl/type
>              |        +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
>              |           +--ro name               -> ../../../../../../../acl/aces/ace/name
>              |           +--ro matched-packets?   yang:counter64
>              |           +--ro matched-octets?    yang:counter64
>              +--rw egress
>                 +--rw acl-sets
>                    +--rw acl-set* [name]
>                       +--rw name    -> ../../../../../../acl/name
>                       +--rw type?   -> ../../../../../../acl/type
>                       +--ro ace* [name] {interface-stats or interface-acl-aggregate}?
>                          +--ro name               -> ../../../../../../../acl/aces/ace/name
>                          +--ro matched-packets?   yang:counter64
>                          +--ro matched-octets?    yang:counter64
> 
> If we added some form of global attachment points, that might be a peer with the list of interface attachments, right? Because we’d need to support “global” and multiple “interface” attachments. It’s not an “or”, it’s an “and”. Or have I missed something?
> 
> Cheers,
> 
> Einar
> 
>> On 13 Dec 2017, at 20:10, Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>> 
>> We want to support “global” attachment point down the line, and that “global” attachment point will be one of the choices (the other being the interface), what would this augment look like. Note, as far as I know, you cannot augment inside a choice node.
>> 
>>> On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com <mailto:einarnn@cisco.com>> wrote:
>>> 
>>> Perhaps like this, as an augmentation to the interface:
>>> 
>>>   augment /if:interfaces/if:interface:
>>>     +--rw ingress-acls
>>>     |  +--rw acl-sets
>>>     |     +--rw acl-set* [name]
>>>     |        +--rw name              -> /access-lists/acl/name
>>>     |        +--rw type?             -> /access-lists/acl/type
>>>     |        +--ro ace-statistics* [name] {interface-stats}?
>>>     |           +--ro name               -> /access-lists/acl/aces/ace/name
>>>     |           +--ro matched-packets?   yang:counter64
>>>     |           +--ro matched-octets?    yang:counter64
>>>     +--rw egress-acls
>>>        +--rw acl-sets
>>>           +--rw acl-set* [name]
>>>              +--rw name              -> /access-lists/acl/name
>>>              +--rw type?             -> /access-lists/acl/type
>>>              +--ro ace-statistics* [name] {interface-stats}?
>>>                 +--ro name               -> /access-lists/acl/aces/ace/name
>>>                 +--ro matched-packets?   yang:counter64
>>>                 +--ro matched-octets?    yang:counter64
>>> 
>>> Could also put an “aces” container above both these & rename “ingress-acls" to “ingress”, etc. to give a single root for the augmentation if preferred.
>>> 
>>> Cheers,
>>> 
>>> Einar
>>> 
>>> 
>>>> On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com <mailto:lear@cisco.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
>>>>> How does one move the interface attachment point, currently an
>>>>> 'interface-ref', to an augmentation of the if:interfaces/interface,
>>>>> inside of the ‘acl’  container? Down the line we might need to have an
>>>>> container for "attachment points" to accommodate the possibility of
>>>>> attaching an ACL either to an interface or “globally”.
>>>>> 
>>>> 
>>>> Keeping in mind that one use is that an ACL doesn't attach to an
>>>> interface at all.
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>>> 
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
> 

Mahesh Jethanandani
mjethanandani@gmail.com