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

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 6 Dec 2017 10:23:28 -0800

Moving to the next issue on the list

> On Nov 3, 2017, at 1:42 AM, Kristian Larsson <[email-masked]> wrote:
> 
>> Personally, I would put the ACL interface attachment points as an
>> augmentation of if:interfaces/interface rather than having a separate top
>> level list, but perhaps that is just want I am used to ...
> 
> +1 on augmentation of interfaces.

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”.

Cheers.

Mahesh Jethanandani
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 6 Dec 2017 20:43:02 +0100

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.

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 13 Dec 2017 14:57:02 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Dec 2017 16:00:26 +0100

I like this because ACLs will be used in many different ways, and
expecting that a single model be augmented for each attachment seems a
bit unrealistic.

Eliot

On 12/13/17 3:57 PM, Einar Nilsen-Nygaard (einarnn) wrote:
> 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
>
>
>> [email-masked] <mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 13 Dec 2017 12:10:35 -0800

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) <[email-masked]> wrote:
> 
>> On 6 Dec 2017, at 19:43, Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 

Mahesh Jethanandani
[email-masked]

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 13 Dec 2017 20:25:02 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Einar

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 13 Dec 2017 12:29:31 -0800

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) <[email-masked]> wrote:
> 
>> On 13 Dec 2017, at 20:10, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> [email-masked] <mailto:[email-masked]>
> 

Mahesh Jethanandani
[email-masked]

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 13 Dec 2017 20:40:44 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Einar

Cheers,

Einar

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 13 Dec 2017 13:08:56 -0800

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) <[email-masked]> wrote:
> 
> Interfaces
> NAT configuration
> Class maps for QoS policy
> Class maps for FW policy
> …etc…
> 
>> On 13 Dec 2017, at 20:29, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

Mahesh Jethanandani
[email-masked]

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 13 Dec 2017 21:15:29 +0000

I’m not sure we have a clear enough common understanding of “global” as yet to be able to say that we should make the provisioning of an ACL on an interface or “globally” mutually exclusive in the model. I think attaching an ACL to a specific interface in either the ingress or egress direction is well-understood, and with a shared understanding across vendors and operators such that either an interface augmentation or a “external” list , with no mention of global, makes sense.

Cheers,

Einar

On 13 Dec 2017, at 21:08, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 13, 2017, at 12:40 PM, Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>> wrote:

  *   Interfaces
  *   NAT configuration

Cheers,

Einar

Cheers,

Einar

Cheers,

Einar

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 13 Dec 2017 16:30:22 -0500

Maybe it would help to say “to all interfaces” instead of “globally”? 

	—Tom

> On Dec 13, 2017, at 4:15 PM, Einar Nilsen-Nygaard (einarnn) <[email-masked]> wrote:
> 
>> On 13 Dec 2017, at 21:08, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Dec 13, 2017, at 12:40 PM, Einar Nilsen-Nygaard (einarnn) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> [email-masked]

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 14 Dec 2017 00:02:35 +0000

Tom,

If we were to introduce this, yes, that (or some similar term) may help clarify. But I think that at the moment we have suggested that we leave this issue out of the initial draft until it is better understood what we should specify.

I think the question at this point is whether explicit ACL to interface binding should be done via interface augmentations or via a list of interface references in the ACL model. Both examples are shown below, but I’ll pull them up for clarity:

Cheers,

Einar

On 13 Dec 2017, at 21:30, Thomas Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

—Tom

On Dec 13, 2017, at 4:15 PM, Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Einar

  *   Interfaces
  *   NAT configuration

Cheers,

Einar

Cheers,

Einar

Cheers,

Einar

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Sonal Agarwal <[email-masked]>
Date: Thu, 14 Dec 2017 00:21:46 -0800

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. However, Kristian wants the global attachment point as
well so that he can add the ACL to the linux tables. If an ACL is attached
globally, does this mean it is per direction or does it mean it is across
directions? 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.

For (2), I am ok with removing icmp-off.

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.

Sonal.

On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani <
[email-masked]> 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 6 Dec 2017, at 19:43, Eliot Lear <[email-masked]> wrote:
>
>
>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 14 Dec 2017 18:50:13 +0000

On 14 Dec 2017, at 08:21, Sonal Agarwal <[email-masked]<mailto:[email-masked]>> wrote:

Hi Einar,

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.

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 <[email-masked]<mailto:[email-masked]>> 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.

Cheers,

Einar

Mahesh Jethanandani

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Sat, 16 Dec 2017 13:19:52 +0000

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

    +--rw acls

Comments welcome!

Cheers,

Einar

On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Einar,

Cheers,

Einar

Sonal.

Cheers,

Einar

Mahesh Jethanandani

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Dec 2017 12:29:50 +0100

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:
>
>> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>> 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:
>>
>> einarnn> I think Kristian doesn’t feel a global attachment point
>> needs to be in this first revision. But he can confirm.
>>
>>> 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.
>>
>>> 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.
>>
>>> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani
>>> <[email-masked] <mailto:[email-masked]>> 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)
>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>>>
>>>
>>>     Mahesh Jethanandani
>>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>>
>>>
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 17 Dec 2017 13:00:38 +0100

On Sun, Dec 17, 2017 at 12:29:50PM +0100, Eliot Lear wrote:

> I would rather the augment to the interface not be required for
> implementations that don't actually have interfaces.

Do you have an example of such a device / implementation?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Eliot Lear <[email-masked]>
Date: Sun, 17 Dec 2017 13:17:06 +0100

> Do you have an example of such a device / implementation?

Yes.  Manufacturer Usage Descriptions.  In this case the access-lists of
the ACL model are used to build out an intent description relating to a
device.  There is no specific interface assigned to that intent.

Eliot

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Sun, 17 Dec 2017 14:34:52 +0000

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:

The augments part of the tree now looks like:

    +--rw acls {interface-attachment}?

Cheers,

Einar

On 17 Dec 2017, at 11:29, Eliot Lear <[email-masked]<mailto:[email-masked]>> 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:

Eliot

Comments welcome!

Cheers,

Einar

Hi Einar,

Cheers,

Einar

Sonal.

Cheers,

Einar

Mahesh Jethanandani

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Dec 2017 13:31:34 +0100

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:
>
>     +--rw acls *{interface-attachment}*?
>        +--rw ingress
>        |  +--rw acl-sets
>        |     +--rw acl-set* [name]
>> 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:
>>
>>> 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:
>>>
>>>> netmod-wg/acl-model that do this. Nearly like the augmentation I
>>>> have below. Feel free to take a look at:
>>>>
>>>>> However, Kristian wants the global attachment point as well so
>>>>> that he can add the ACL to the linux tables.
>>>>
>>>> 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 (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.
>>>>
>>>>>     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.
>>>>>
>>>>>>     “ingress-acls" to “ingress”, etc. to give a single root for
>>>>>>     the augmentation if preferred.
>>>>>>
>>>>>>     Cheers,
>>>>>>
>>>>>>     Einar
>>>>>>
>>>>>>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Dec 2017 21:11:33 +0100

Presuming this issue is behind us, are all WGLC comments addressed?  Can
we expect to see a new draft soon?

Eliot

On 18.12.17 13:31, Eliot Lear wrote:
>>>>>> If an ACL is attached globally, does this mean it is per
>>>>>> direction or does it mean it is across directions?
>>>>>