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

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 13 December 2017 21:09 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 AABE61242EA for <netmod@ietfa.amsl.com>; Wed, 13 Dec 2017 13:09:14 -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 GucSdjVK8EzI for <netmod@ietfa.amsl.com>; Wed, 13 Dec 2017 13:08:59 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 C0C38127867 for <netmod@ietf.org>; Wed, 13 Dec 2017 13:08:59 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id j124so2026410pfc.2 for <netmod@ietf.org>; Wed, 13 Dec 2017 13:08:59 -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=CsWpFQi8u698Su5KWpIa5cdrLX/PPSESFl1Buvnf4NM=; b=Xz4sZ6DGoUYy5Ufjox22ufhK06/HFMfqYD89oLD22KmnGwfMuW9M89xfDpzv1UDb9N vftW49O/rYI6H3DuqUZN4xBfVt+oF+W1KQJT9u3TG7CaFCCcfWflLg0V7ayvRhv9eVR7 8yd49aGaKWhIASTUW10kaQOLzw4Ekhw9gAACKd3PdWC+YR56TqvUpQQ9QMCwRBY+HIQq QiNlveZNtIP5m+2tdB1/0OZQn1HuSz+vofktY+iOqB6aTG2iXiDQNc0hggrh2fFjSj42 MWEFl1E2Q8YV86W+xdtk4DtzCIzpxxywVPcmm2dC8pBtvn6a+UdDeRmsZfcKfprDTf0v nQzQ==
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=CsWpFQi8u698Su5KWpIa5cdrLX/PPSESFl1Buvnf4NM=; b=O/unmm9A6H8ub2Ur2GZokfBZXysUD0ptS0Y5peAdXHCg2+JPKaTC8DBxmrkQWLrBQu oc42c7fiGtRxiLOuMza0n6M+kbAfeBjZqWwDDmyat7Wv3J6X8bUCy64oSipGT71NL9sf B60stg6+a9hH6QNCBPuSGkTOBCl4sWe3W07OKD4/unz9hlEW2V2ETvVbzVr6CKxHh6La D5cFI4aw+kY+Zbk/JUUafTdC9z/MkZj8qNIp6gYhPuFqs49dFImgEb56cykGKv/gqSYG WRd4Fmy9XC5iH5g7gmkU5duhOx9X2vW0kemcM1OeKD3z8hkZW10KWP4A2v/6g/GI5n7o eo5Q==
X-Gm-Message-State: AKGB3mKsRq9TvlJrV+vfqLrAiVOggtPFBTlLA9fsQaD1Vng4udWjqhvj Q79vj+Mpif20OpCCRts8iro=
X-Google-Smtp-Source: ACJfBostxLP2Xp3PNSdizXThtW1HjjC3XXRxDrJW35xDd5ZP+jsth7+YA2ZieDuhse+1919s19S9fg==
X-Received: by 10.84.242.69 with SMTP id c5mr7105272pll.73.1513199339253; Wed, 13 Dec 2017 13:08:59 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net (108-247-125-249.lightspeed.sntcca.sbcglobal.net. [108.247.125.249]) by smtp.gmail.com with ESMTPSA id k197sm4011310pga.42.2017.12.13.13.08.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Dec 2017 13:08:58 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AE319B3B-1F56-44E0-802D-59E74A1B2AEC"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@cisco.com>
Date: Wed, 13 Dec 2017 13:08:56 -0800
Cc: Eliot Lear <lear@cisco.com>, Kristian Larsson <kristian@spritelink.net>, "netmod@ietf.org" <netmod@ietf.org>
Message-Id: <5CBC1C7B-FB4C-4313-9BE3-BEF618C62DA2@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> <FEA5251F-990C-4948-91F6-44AE25E016AE@gmail.com> <70C53C47-5C0A-4635-BC98-EBC9AD4130CB@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/TUrFNSTYYTVt5X8FqtjU2JdNhvM>
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 21:09:15 -0000

You can use the same ACL definition to attach to different points in the system, provided they do not overlap. Otherwise, you are just wasting CAM entries. Global and interface attachment points will overlap with each other, because global means ‘any’ interface.

> On Dec 13, 2017, at 12:40 PM, Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com>; wrote:
> 
> We need to be able to attach any one ACL to a whole range of different places. Just speaking from the Cisco platform perspective, I may attach an ACL to:
> 
> Interfaces
> NAT configuration
> Class maps for QoS policy
> Class maps for FW policy
> …etc…
> 
> Not sure if we have any global attachment points today, but if we did, I’d want to be able to use the same ACL definition anywhere I need it, not in just one on N places.
> 
> Cheers,
> 
> Einar
> 
>> On 13 Dec 2017, at 20:29, Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>> 
>> 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 <mailto: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 <mailto:mjethanandani@gmail.com>
> 

Mahesh Jethanandani
mjethanandani@gmail.com