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