> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA)
> <[email protected]> wrote:
>
> Hi all,
>
> The ACL model is converging on a small core set of functionality that is
> fairly common.
>
> But I think the matching on input-interface should be removed from the model
> (or at the least put inside a feature flag).
>
> Matching on basic IPv4/IPv4/MAC header fields is common functionality. But
> having that input-interface match on metadata in the core model is out of
> place. It should be left to further extension drafts or vendor specific
> augmentations (along with whatever other metadata might be useful or
> vendor-specific).
>
> ACLs are typically assigned to interfaces as shown in section A.3. of the ACL
> draft. That is the most common use case.
>
> Actually matching on input-interface in the ACL rules themselves is not basic
> core ACL functionality. Nokia SR OS does not have that capability. Does
> IOS-XR ? Brocade ? others ?
Cisco and Juniper support matching on input interface. It is useful when you
want to filter on general traffic coming from interface.
Cisco
match input-interface
match input-vlan
Junos
family any {
filter L2_filter {
term t1 {
from {
interface fe-0/0/0.0;
}
then {
policer p1;
count c1;
}
}
}
}
Brocade supports matching based on interface, Dell supports VLAN matching,
Arista supports input interface matching, Redback supports matching against
input interface for logging, so it is pretty standard across multiple vendors
Dean
> If some major implementations don’t do it, and it isn’t necessary for
> typical basic ACL use, then it should be removed (or feature flagged).
>
> Regards,
> Jason
>
> _______________________________________________
> netmod mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
