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

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 9 Jan 2018 19:08:05 -0800

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 <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 <[email-masked]> 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 <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 <[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:
>>> 
>>> Separate out the augment into a separate module (same doc is fine); or
>>> 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 <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) <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 14 Dec 2017, at 08:21, Sonal Agarwal <[email-masked] <mailto:[email-masked]>> 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 <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 <[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:
>>>>>>> 
>>>>>>> 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:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 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
>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>>> 
>>>>>> 
>>>>>> Mahesh Jethanandani
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>>> 
>> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Jan 2018 08:35:47 +0100

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:
> 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 <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> 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
>>>
>>>
>>>     +--rw acls *{interface-attachment}*?
>>>        +--rw ingress
>>>        |  +--rw acl-sets
>>>        |     +--rw acl-set* [name]
>>>> 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.
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>   * 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.
>>>>>
>>>>>
>>>>>                 |  |        +--rw dscp?                      
>>>>> inet:dscp
>>>>>> 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:
>>>>>>
>>>>>>     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?
>>>>>>
>>>>>>> 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 (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.
>>>>>>
>>>>>>> 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:
>>>>>>>>
>>>>>>>>     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
>>>>>>>>
>>>>>>>>
>>>>>>>>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>>>>
>>>>>>>
>>>>>>>     Mahesh Jethanandani
>>>>>>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>>>
>>>>>>>
>>>>>>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 10 Jan 2018 08:58:08 +0000

Mahesh,

Two things:

First, I see that you have still left in the “icmp-off” action. This was something both Kristian and I recommended removing, and I also discussed this with Sonal at the end of last year and she agreed that it should probably be removed since it seems at this point (absent anyone pointing out other implementations) to be a Cisco IOS-XR-specific feature that should probably be dealt with via a vendor augmentation initially. Can we remove this?

Second, I would really like the contributors who wish to maintain the separate ACL attachment interface list with interface references to lay out how direct interface attachment prevents ACLs being used with other attachment points. As I pointed out, direct interface attachment does not remove any flexibility at all for other future attachment points. While I’m not intrinsically opposed to a separate list with interface refs, I just want to understand the rationale as the majority of switches and routers, as far as I am aware, typically attach ACLs directly to interfaces, meaning that the pattern is well-understood by typical users of this model.

Cheers,

Einar

On 10 Jan 2018, at 03:08, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

Cheers.

On Dec 18, 2017, at 4:31 AM, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Einar

On 17 Dec 2017, at 11:29, Eliot Lear <[email-masked]<mailto:[email-masked]>> wrote:

Einar,

  1.  Separate out the augment into a separate module (same doc is fine); or
  2.  Somehow "feature-ize" the augment.

Eliot

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

Comments welcome!

Cheers,

Einar

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

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

Hi Einar,

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.

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

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

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

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

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

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

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

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

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 10 Jan 2018 17:21:13 -0800

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 <[email-masked]> 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 Dec 18, 2017, at 4:31 AM, Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 10 Jan 2018 20:16:13 -0800

> On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) <[email-masked]> wrote:
> 
> Mahesh,
> 
> Two things:
> 

You are right. It was discussed, but more to understand why we needed it. Before we remove it, let me clarify why we need it, and if after that the consensus is still to remove it, or move it to a Cisco specific augmentation, we can do it.

The idea behind having the leaf is for routers to setup a rule to accept ICMP messages, allow the router to process the message, but suggest that a response may be suppressed. That way one can have rules to receive and process ICMP messages like “destination unreachable” or “fragmentation required” that are important for routers/hosts, but prevent rogue machines from discovering machines in a sweeping ping. 

> Second, I would really like the contributors who wish to maintain the separate ACL attachment interface list with interface references to lay out how direct interface attachment prevents ACLs being…

I think the first issue in setting up alternate attachment point is, how would you do setup the alternate attachment point as a choice between it and attaching it to an interface under an augmentation. Secondly, if the ACLs are used with multiple NI, each of them referring to the global set of ietf-interfaces shared by all the instances, which the schema mount draft outlines here <https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-06#section-4>, it implies that you will need a reference to the interfaces. 

Thanks.

> 
> Cheers,
> 
> Einar
> 
> 
>> On 10 Jan 2018, at 03:08, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jan 2018 08:00:01 +0100

> The idea behind having the leaf is for routers to setup a rule to accept ICMP messages, allow the router to process the message, but suggest that a response may be suppressed. That way one can have…

This sort of thing seems to be done in other implementations by having
different rules for incoming and outgoing traffic; does the acl model
support that?

/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: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 11 Jan 2018 08:05:15 +0000

Yes, the ACL model supports ingress and egress rules that can be different.

> On Jan 11, 2018, at 07:00, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Thu, 11 Jan 2018 08:25:51 +0000

On Jan 11, 2018, at 04:16, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

On Jan 10, 2018, at 12:58 AM, Einar Nilsen-Nygaard (einarnn) <[email-masked]<mailto:[email-masked]>> wrote:

Mahesh,

Two things:

I think the first issue in setting up alternate attachment point is, how would you do setup the alternate attachment point as a choice between it and attaching it to an interface under an augmentation.

Why does it need to be a choice between the two attachment points? An ACL can be attached to one or both of interfaces and other attachment points. There is no need for a choice.

Secondly, if the ACLs are used with multiple NI, each of them referring to the global set of ietf-interfaces shared by all the instances, which the schema mount draft outlines here<https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-06#section-4>, it implies that you will need a reference to the interfaces.

Sorry, it is not clear to me what the problem is here? Are you concerned about the ACL model being mounted under a mount point, and needing to use those ACLs on globally defined interfaces? Or are you concerned about the interface model being mounted under a mount point and how global ACLs would be referenced?

Cheers,

Einar

Thanks.

Cheers,

Einar

Cheers.

Cheers,

Einar

Einar,

Eliot

Comments welcome!

Cheers,

Einar

Hi Einar,

Cheers,

Einar

Sonal.

Cheers,

Einar

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Jan 2018 16:35:37 +0100

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 <[email-masked]
>>> to include the change as it relates to augmenting ietf-interfaces.
>>> We did not find that the change had a particular advantage over the
>>>>>>> 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:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>>>     On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard
>>>>>>>>>>     (einarnn) <[email-masked] <mailto:[email-masked]>>
>>>>>>>>>>     wrote:
>>>>>>>>>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 12 Jan 2018 14:07:13 -0800

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 <[email-masked]> wrote:
> 
>>> On Jan 9, 2018, at 11:35 PM, Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Mahesh,
>>> 

Mahesh Jethanandani
[email-masked]

---

From: Sonal Agarwal <[email-masked]>
Date: Tue, 16 Jan 2018 19:13:08 -0800

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

Thanks,
Sonal.

On Fri, Jan 12, 2018 at 2:07 PM, Mahesh Jethanandani <
[email-masked]> 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.
>
> 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
>
> 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.
>
> 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:
>
> On 17 Dec 2017, at 11:29, Eliot Lear <[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:
>
> 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:
>
>    - 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.
>
>
> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn) <
> [email-masked]> wrote:
>
>
>
> On 14 Dec 2017, at 08:21, Sonal Agarwal <[email-masked]> wrote:
>
> Hi Einar,
>
> 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.
>
> 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.
>
>
> 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 Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard (einarnn) <
>> [email-masked]> 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
>>
>>
>> On 6 Dec 2017, at 19:43, Eliot Lear <[email-masked]> wrote:
>>
>>
>>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>
> Mahesh Jethanandani
> [email-masked]
>
>
>
> Mahesh Jethanandani
> [email-masked]
>
>