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

Sonal Agarwal <sagarwal12@gmail.com> Wed, 17 January 2018 03:13 UTC

Return-Path: <sagarwal12@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 A67AF12EC5C for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 19:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level:
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uztBBquXI3d5 for <netmod@ietfa.amsl.com>; Tue, 16 Jan 2018 19:13:11 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 C227712D949 for <netmod@ietf.org>; Tue, 16 Jan 2018 19:13:10 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id u10so20923655qtg.2 for <netmod@ietf.org>; Tue, 16 Jan 2018 19:13:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iD2dTQW4kNnuGbyxW72NvfFxcawdDHjDSYaayzUE3Oc=; b=qgOyNfr6NwY+6LQv/lsWNA+QmTny4tUepsNlyki8rP0mhrVv2et9iuV/Q+DEUbpD6+ VO10qRoraPCWD1LEbDqNOFyvBfql+GFaZP6DESCaeINJMpvsqS6O+ZpvE7aNRWA8IGc9 5KXSg6Yfd1n0QfPQB6Kya9e7ACtXHroQUxha3Mnsrp3k9x938Dx8fSy5puNBjzUbn6Ge 6iKPREaqIBGkoGVlirwQoapjmaIsrXqfd0xFi8jRbszJNF+LKcl3xkNki3oyDVCxuxT/ eVzyMoJhgALoL2rMINcoG0tL1gp8qpZDy4NwNZX1vACtYCZZBfL6rQ9A5/cD7nZvmFlB F04Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iD2dTQW4kNnuGbyxW72NvfFxcawdDHjDSYaayzUE3Oc=; b=Q00BAgktVCEolcwUEIelJcwKRK52C42F1HhanlzpUOLpqnajN077v8NbkCaYhjvDjM E2NtNSRAmTkHBqR/eVI1KTlBp9Q0JFoJKQVqfqYzH62LwDhyZSNGPemlWJZXsoU50rBp KEABHUJ6VdZa/q2yQyRSwLPPtuwSNdGprUmtivfmYjLeglCbMgK34/kP5Pn8YVl4id7Q 77fOchhuVKd+ut+ohxwOdivnLh7Ly4QB1a3SzVp3lhmLLj+CPvOeFRHfT2LRrh3RHrUp IPVG16abg6KqwGv8ZTehmLrnFL/e6Db3PwihOdGIhtjfhnKonTklp9tOIsoh6hgXO8Mu 0oYg==
X-Gm-Message-State: AKwxytfw9iFRWG0DvdFc57KhB3J4+aCk0i1mCdmcA4Sl6AdxNru1+SL6 q95Q4lIJxGbc/uBxC6Ul1oh7F8WrcUKVBs4bFzg=
X-Google-Smtp-Source: ACJfBouQkGHABaLdC16W0zu/Ys6G2C/9CXXOsOVfFtNHsyFMacHUGVzOBJ4E8FkPgeeq1X/FPVJA3G9PcYyaIMjOoRU=
X-Received: by 10.200.43.68 with SMTP id 4mr4830946qtv.265.1516158789809; Tue, 16 Jan 2018 19:13:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.96.11 with HTTP; Tue, 16 Jan 2018 19:13:08 -0800 (PST)
In-Reply-To: <C1C5B935-7E7D-45E7-94E4-F02C20897AA9@gmail.com>
References: <20171102074318.GC12688@spritelink.se> <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> <CAMMHi8ge4cbrVgRK8=xtJLNYCG1+p+Jh6pFeCy9sEMZP674FHQ@mail.gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <fe8b601a-2a02-8011-b913-a49f2f486971@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> <bbe624c1-0766-9519-56d6-835ee305274d@cisco.com> <FE3FE735-65FF-4206-A672-54CD4BF7AF56@gmail.com> <7ba191c8-d03d-ad2f-d9c1-2a035b0bb336@cisco.com> <C1C5B935-7E7D-45E7-94E4-F02C20897AA9@gmail.com>
From: Sonal Agarwal <sagarwal12@gmail.com>
Date: Tue, 16 Jan 2018 19:13:08 -0800
Message-ID: <CAMMHi8ijfLfOm_i0QBahtzQ1mU9NRoVrSaKD_6Yj88Z0Jfy6ZQ@mail.gmail.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Eliot Lear <lear@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a11404f4c16fa170562f03af3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zCVr0PCTIe0cEPKPA3R1kj5Nfyk>
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, 17 Jan 2018 03:13:15 -0000

I have reviewed the changes and they look good to me.

Thanks,
Sonal.


On Fri, Jan 12, 2018 at 2:07 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

> An updated version of the draft, along with changes to remove icmp-off
> from the model, and updates to examples has been posted in the PR here
> <https://github.com/netmod-wg/acl-model/pull/20>. If there are no
> objections to the changes by Tuesday, I will pull in the PR, and publish
> the draft.
>
> Cheers.
>
> On Jan 12, 2018, at 7:35 AM, Eliot Lear <lear@cisco.com> wrote:
>
> Ok.  What is left to agree on at this point?
>
> Thanks Mahesh,
>
> Eliot
>
> On 11.01.18 02:21, Mahesh Jethanandani wrote:
>
> Hi Einar,
>
> I can work on updating the draft as soon as we agree on the changes.
> Should take only a couple of days to turn around and publish the draft.
>
> On Jan 9, 2018, at 11:35 PM, Eliot Lear <lear@cisco.com> wrote:
>
> Hi Mahesh,
>
> Thanks for this work.  I think this is okay.  In the case of MUD we simply
> won't have the other container.  Can I please ask that you get the draft
> out quickly as draft-ietf-opsawg-mud has been waiting quite some time for
> this work to complete.
>
> Eliot
>
> On 10.01.18 04:08, Mahesh Jethanandani wrote:
>
> I have pulled in the changes as they relate to:
>
> - moving “interface-acl” under the container “attachment-points” making it
> local to that container.
> - reverting “acl-type” to “type”
> - removed “interface-all-aggregate” feature
> - simplified source port and destination port definition
>
> The pull request for the changes can be found here.
>
> https://github.com/netmod-wg/acl-model/pull/20
>
> After discussing with some of the original contributors, decided not to
> include the change as it relates to augmenting ietf-interfaces. We did not
> find that the change had a particular advantage over the current
> implementation. Even if we do not completely understand how ACLs might be
> attached “globally” or on something that is not an interface, having the
> flexibility to attach them to other attachment points is important. Keeping
> it as interface-ref gives us that flexibility.
>
> Cheers.
>
> On Dec 18, 2017, at 4:31 AM, Eliot Lear <lear@cisco.com> wrote:
>
> So long as nobody expects an interface construct in a MUD file, I'm happy.
>
> On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
>
> Eliot,
>
> Nothing can force an implementation to have to implement either
> the ietf-interfaces model or the augmentation in the
> ietf-access-control-list model. I appreciate your desire for modularity and
> cohesiveness, but I would resist #1, because I feel that the majority of
> users will be targeting interface-based attachment over time. I’ve adde
> back in use of the “interface-attachment” feature (which I took out as part
> of refactoring interface attachment). Part of:
>
> https://github.com/netmod-wg/acl-model/pull/21
>
>
> The augments part of the tree now looks like:
>
>   augment /if:interfaces/if:interface:
>     +--rw acls *{interface-attachment}*?
>        +--rw ingress
>        |  +--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
>           +--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
>
> Cheers,
>
> Einar
>
>
> On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisco.com> wrote:
>
> Einar,
>
> I think this change is fine, with one exception.  I would rather the
> augment to the interface not be required for implementations that don't
> actually have interfaces.  I understand that there may be two ways to go
> about this:
>
>    1. Separate out the augment into a separate module (same doc is fine);
>    or
>    2. Somehow "feature-ize" the augment.
>
> I don't know how to do (2) but if you do, that's okay by me.
>
> Eliot
>
> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
>
> All,
>
> After a series of discussions on- and off-list, I have a candidate PR that
> includes the changes in the PR Mahesh sent out plus some more edits. Please
> see consolidated PR here:
>
> https://github.com/netmod-wg/acl-model/pull/21
>
>
> Main changes in addition to Mahesh’s PR are:
>
>
>    - Moved interface attachment to be via an interface augmentation.
>    - Restructured port matches slightly under both IPv4 and IPv6
>    containers.
>    - Removed unnecessary identity 'interface-acl-aggregate’.
>    - Removed action ‘icmp-off’, can be augmented later.
>
>
> For reference, here is the current YANG tree plus “--ietf” logs:
>
> 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang
> ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD" (should
> be date)
> module: ietf-access-control-list
>     +--rw access-lists
>        +--rw acl* [name]
>           +--rw name    string
>           +--rw type?   acl-type
>           +--rw aces
>              +--rw ace* [name]
>                 +--rw name          string
>                 +--rw matches
>                 |  +--rw (l2)?
>                 |  |  +--:(eth)
>                 |  |     +--rw eth {match-on-eth}?
>                 |  |        +--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 (l3)?
>                 |  |  +--:(ipv4)
>                 |  |  |  +--rw ipv4 {match-on-ipv4}?
>                 |  |  |     +--rw dscp?                       inet:dscp
>                 |  |  |     +--rw ecn?                        uint8
>                 |  |  |     +--rw length?                     uint16
>                 |  |  |     +--rw ttl?                        uint8
>                 |  |  |     +--rw protocol?                   uint8
>                 |  |  |     +--rw (source-port-range-or-operator)?
>                 |  |  |     |  +--:(range)
>                 |  |  |     |  |  +--rw source-port-lower
> inet:port-number
>                 |  |  |     |  |  +--rw source-port-upper
> inet:port-number
>                 |  |  |     |  +--:(operator)
>                 |  |  |     |     +--rw source-operator
> operator
>                 |  |  |     |     +--rw source-port
> inet:port-number
>                 |  |  |     +--rw (destination-port-range-or-operator)?
>                 |  |  |     |  +--:(range)
>                 |  |  |     |  |  +--rw destination-port-lower
>  inet:port-number
>                 |  |  |     |  |  +--rw destination-port-upper
>  inet:port-number
>                 |  |  |     |  +--:(operator)
>                 |  |  |     |     +--rw destination-operator
>  operator
>                 |  |  |     |     +--rw destination-port
>  inet:port-number
>                 |  |  |     +--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
>                 |  |  +--:(ipv6)
>                 |  |     +--rw ipv6 {match-on-ipv6}?
>                 |  |        +--rw dscp?                       inet:dscp
>                 |  |        +--rw ecn?                        uint8
>                 |  |        +--rw length?                     uint16
>                 |  |        +--rw ttl?                        uint8
>                 |  |        +--rw protocol?                   uint8
>                 |  |        +--rw (source-port-range-or-operator)?
>                 |  |        |  +--:(range)
>                 |  |        |  |  +--rw source-port-lower
> inet:port-number
>                 |  |        |  |  +--rw source-port-upper
> inet:port-number
>                 |  |        |  +--:(operator)
>                 |  |        |     +--rw source-operator
> operator
>                 |  |        |     +--rw source-port
> inet:port-number
>                 |  |        +--rw (destination-port-range-or-operator)?
>                 |  |        |  +--:(range)
>                 |  |        |  |  +--rw destination-port-lower
>  inet:port-number
>                 |  |        |  |  +--rw destination-port-upper
>  inet:port-number
>                 |  |        |  +--:(operator)
>                 |  |        |     +--rw destination-operator
>  operator
>                 |  |        |     +--rw destination-port
>  inet:port-number
>                 |  |        +--rw destination-ipv6-network?
> inet:ipv6-prefix
>                 |  |        +--rw source-ipv6-network?
>  inet:ipv6-prefix
>                 |  |        +--rw flow-label?
> inet:ipv6-flow-label
>                 |  +--rw (l4)?
>                 |  |  +--:(tcp)
>                 |  |  |  +--rw tcp {match-on-tcp}?
>                 |  |  |     +--rw sequence-number?          uint32
>                 |  |  |     +--rw acknowledgement-number?   uint32
>                 |  |  |     +--rw data-offset?              uint8
>                 |  |  |     +--rw reserved?                 uint8
>                 |  |  |     +--rw flags?                    bits
>                 |  |  |     +--rw window-size?              uint16
>                 |  |  |     +--rw urgent-pointer?           uint16
>                 |  |  |     +--rw options?                  uint32
>                 |  |  +--:(udp)
>                 |  |  |  +--rw udp {match-on-udp}?
>                 |  |  |     +--rw length?   uint16
>                 |  |  +--:(icmp)
>                 |  |     +--rw icmp {match-on-icmp}?
>                 |  |        +--rw type?             uint8
>                 |  |        +--rw code?             uint8
>                 |  |        +--rw rest-of-header?   uint32
>                 |  +--rw egress-interface?    if:interface-ref
>                 |  +--rw ingress-interface?   if:interface-ref
>                 +--rw actions
>                 |  +--rw forwarding    identityref
>                 |  +--rw logging?      identityref
>                 +--ro statistics {acl-aggregate-stats}?
>                    +--ro matched-packets?   yang:counter64
>                    +--ro matched-octets?    yang:counter64
>
>   augment /if:interfaces/if:interface:
>     +--rw acls
>        +--rw ingress
>        |  +--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
>           +--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
>
> Comments welcome!
>
> Cheers,
>
> Einar
>
>
>
> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <
> einarnn@cisco.com> wrote:
>
>
>
> On 14 Dec 2017, at 08:21, Sonal Agarwal <sagarwal12@gmail.com> wrote:
>
> Hi Einar,
>
> You had 3 questions for me on all the several e-mail threads.
> 1. Global attachment point
> 2. icmp-off
> 3. acl-aggregate-interface stats.
>
> For (1), my first preference is to have the model define attachment point
> for interfaces only.
>
>
> einarnn> I have some diffs, layered on top of Mahesh’s PR to
> netmod-wg/acl-model that do this. Nearly like the augmentation I have
> below. Feel free to take a look at:
>
> https://github.com/mjethanandani/acl-model/pull/3
>
>
> However, Kristian wants the global attachment point as well so that he can
> add the ACL to the linux tables.
>
>
> einarnn> I think Kristian doesn’t feel a global attachment point needs to
> be in this first revision. But he can confirm.
>
> If an ACL is attached globally, does this mean it is per direction or does
> it mean it is across directions?
>
>
> einarnn> I don’t know right now :-)
>
> This global ACL may not be applicable to any of Cisco's service provider
> routers as I don't see any platform actually replicating the ACL to all
> line cards and attaching it in ingress and egress directions across all
> interfaces.
>
>
> einarnn> Per other emails, I don’t think we understand this enough yet to
> specify it, so I suggest we just leave it out for now. Nothing in the model
> prevents a “global attachment point” being added later once we understand
> what it really means.
>
> For (2), I am ok with removing icmp-off.
>
>
> einarnn> Done in my PR above.
>
> For (3), this would have to be a combination of ACL stats across all
> interfaces for all ACL's. Something like this is possible on an XR box
> where ACES have counter names associated with it. Let's chat about this
> offline tomorrow.
>
>
> einarnn> I’ll ping you to clarify, and we can bring any conclusion back to
> the list.
>
> Cheers,
>
> Einar
>
>
>
> Sonal.
>
>
> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani <
> 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> 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/nam
>> e
>>     |           +--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/nam
>> e
>>                 +--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> 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
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>