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)
> <eina...@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 <mjethanand...@gmail.com
>> <mailto:mjethanand...@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)
>>> <eina...@cisco.com <mailto:eina...@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 <l...@cisco.com
>>>> <mailto:l...@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
>> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
>
Mahesh Jethanandani
mjethanand...@gmail.com
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
