On 02/11/2017 16:41, Kristian Larsson wrote:
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/
This just means that a device cannot say that it supports a
"mixed-ipv4-acl" ACL unless it supports classifying traffic on Ethernet
and classifying traffic on IPv4.
So the 'match type' feature specify what header fields the hardware is
capable of match on. E.g. a basic L2 device might say that is only
matches on the Ethernet header.
The "ACL types" features specify what combination of header fields can
be combined into a single ACL.
The real benefit for defining "match type" is that the unsupported
fields in the ACL can then be cleanly left out of the device schema.
E.g. a hypothetical new breed of IPv6 only routers that only support
matching on match-on-ipv6-hdr, and don't want to carry v4 baggage.
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.
The YANG is stating the reverse:
- You can enable the feature that matches on mixed ACLs, if and only
if, you support matching on Ethernet header fields and IPv4 header fields.
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.
So for XR, you might just list the following features:
feature match-on-l2-eth-hdr;
feature match-on-ipv4-hdr;
feature match-on-ipv6-hdr;
feature l2-acl;
feature ipv4-acl;
feature ipv6-acl;
I.e. it individually supports L2, v4, and v6 ACLs, but a given ACL cannot have
mixed entries.
Probably the vendors would need to augment this module with addition
configuration restrictions to which ACLs can be applied together on an
interface. E.g. either an L2 or L3 ACL. If an L3 ACL it can either be a v4
ACL, a v6 ACL, or one of each.
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.
I think that this is probably hard to encode in a generic model. As per
above, I suspect that such constraints may be more cleanly implemented
as vendor specific deviations.
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?
For interface attachments I think that the approach in the draft looks
OK, and reasonably generic, but will need vendor deviations. This is
probably OK.
Personally, I would put the ACL interface attachment points as an
augmentation of if:interfaces/interface rather than having a separate
top level list, but perhaps that is just want I am used to ...
Thanks,
Rob
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;
}
}
}
I think that the existing model is g
// 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.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
