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

Reply via email to