On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
> One further refinement might also be to make the ACL type features a bit more
> hierarchical as well, but I don't know if that makes it too complex?
I was pondering this for a bit but I'm not sure it actually
helps.
> For example, the model could define separate features for what type of ACE
> matching is supported by the device, separately from what types of ACE
> combinations are allowed.
>
> E.g.
>
> // New 'match type' features.
>
> feature match-on-l2-eth-hdr {
> // Device can match on L2 Ethernet header fields.
> }
> feature match-on-ipv4-hdr {
> // Device can match on IPv4 header fields.
> }
> feature match-on-ipv6-hdr {
> // Device can match on IPv6 header fields.
> }
>
>
> The existing ACL type features could then depend on these:
>
>
> feature l2-acl {
> if-feature "match-on-l2-eth-hdr";
> description "Layer 2 ACL supported";
> }
>
> feature ipv4-acl {
> if-feature "match-on-ipv4-hdr";
> description "Layer 3 IPv4 ACL supported";
> }
>
> feature ipv6-acl {
> if-feature "match-on-ipv6-hdr";
> description "Layer 3 IPv6 ACL supported";
> }
>
> feature mixed-ipv4-acl {
> if-feature "match-on-l2-eth-hdr and "match-on-ipv4-hdr";
> description "Layer 2 and Layer 3 IPv4 ACL supported";
> }
> ...
Features dependent on features... inception. I didn't even know
this was possible with YANG. Learned something today \o/
Anyway, I don't think you can actually deduce that a device
supports an ACL that maches on ethernet and IPv4 based on that it
supports matching on Ethernet headers and IPv4 headers.
For example, on IOS XR there are "ethernet-service access-list"
which can match on Ethernet headers but they are distinct from
ipv4 access-list and they use different attachment points under
an interface. IPv6 is yet another ACL with its own attachment
point... you cannot mix them in the same ACL. I guess they are
logically evaluated in order, so ethernet first, and if it passes
that then the ipvX ACL is evaluated. I believe the situation is
similar on JUNOS.
Which brings us to how to define attachment points. By using YANG
features a device can declare what ACL types it supports but if
the device has different attachment points then there should
probably be some constraint on what ACL type is attached where.
Are we seeking to have a single style of attachment points? I
think that's difficult in reality. Linux has one style, where a
single global "ACL" is defined. Most routers use per interface
ACL and as seen, they split it up on ethernet vs IP (and v4 vs
v6). I doubt one can be said to be better than the other so
trying to argue that everyone should converge on one way is
pointless. Similarly supporting every different style is also
futile as it's completely against the point of standardisation.
The pragmatic compromies is likely to support a few ways and any
vendor that needs something radically different need to build
their own model, do augment, deviate, refine or whatever. Other
thoughts?
An example (from the top of my head so excuse syntax errors):
grouping interface-attach {
choice attach-style {
case mixed {
if-feature mixed-acl;
leaf-list mixed {
description "Any type of ACL that can match on ethernet, ipv4, ipv6 or
anything else";
ordered-by user;
type leafref {
path "/access-list/acl/acl-name"; // we can apply any acl-type
}
}
}
case specific-acl {
if-feature specific-acl;
leaf-list ethernet {
description "ACL for Ethernet";
ordered-by user;
type leafref {
path "/access-list/acl/acl-name";
}
must 'derived-from(deref(.)/../acl-type, eth-acl)';
}
leaf-list ipv4 {
description "ACL for IPv4";
ordered-by user;
type leafref {
path "/access-list/acl/acl-name";
}
must 'derived-from(deref(.)/../acl-type, ipv4-acl)';
}
leaf-list ipv6 {
description "ACL for IPv6";
ordered-by user;
type leafref {
path "/access-list/acl/acl-name";
}
must 'derived-from(deref(.)/../acl-type, ipv6-acl)';
}
}
}
}
// ACLs attached under interface, like most big routers do it
augment "/if:interfaces/if:interface" {
if-feature interface-acl;
container acl {
description
"ACL attachment point";
container ingress {
uses interface-attach;
}
container egress {
uses interface-attach;
}
}
}
// ACL globally attached, like on a Linux machine
augment /access-list {
if-feature global-attach;
leaf system-acl {
type leafref {
path "/access-list/acl/acl-name";
}
}
}
Kind regards,
Kristian.
--
Kristian Larsson KLL-RIPE
+46 704 264511 [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
