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 protected]> wrote:
>
> 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 protected]
>> <mailto:[email protected]>> wrote:
>>
>> 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 protected] <mailto:[email protected]>> wrote:
>>>
>>> We need to be able to attach any one ACL to a whole range of different
>>> places. Just speaking from the Cisco platform perspective, I may attach an
>>> ACL to:
>>>
>>> Interfaces
>>> NAT configuration
>>> Class maps for QoS policy
>>> Class maps for FW policy
>>> …etc…
>>>
>>> Not sure if we have any global attachment points today, but if we did, I’d
>>> want to be able to use the same ACL definition anywhere I need it, not in
>>> just one on N places.
>>>
>>> Cheers,
>>>
>>> Einar
>>>
>>>> On 13 Dec 2017, at 20:29, Mahesh Jethanandani <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> My understanding is that you would attach an ACL either to an interface or
>>>> globally. Not both.
>>>>
>>>>> On Dec 13, 2017, at 12:25 PM, Einar Nilsen-Nygaard (einarnn)
>>>>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>>>>>> <mailto:[email protected]>> 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 protected] <mailto:[email protected]>> 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 protected]
>>>>>>>> <mailto:[email protected]>> 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 protected] <mailto:[email protected]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>>>
>>>>>>
>>>>>> Mahesh Jethanandani
>>>>>> [email protected] <mailto:[email protected]>
>>>>>
>>>>
>>>> Mahesh Jethanandani
>>>> [email protected] <mailto:[email protected]>
>>>
>>
>> Mahesh Jethanandani
>> [email protected] <mailto:[email protected]>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
