On 03/11/2017 08:42, Kristian Larsson wrote:
On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
On 02/11/2017 16:41, Kristian Larsson wrote:
On Thu, Nov 02, 2017 at 12:53:29PM +0000, Robert Wilton wrote:
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.
Ah, right. Sorry, I was thinking that match-on-l2-eth-hdr and
match-on-ipv4-hdr would imply mixed-ipv4-acl. My bad.
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.
Since I work for a network that aspires of being v6 only I quite
like this ;)
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.
I don't agree. Given the length we've gone in trying to convey the
match capabilities of the platform I think we can afford to give
implementors some options when it comes to attachment too! :)
I agree that interface vs global are two different styles, and happy if
the model supports both.
But for interface attachments, if there can be one generic way that can
apply to all platforms (perhaps with further constraints) then that will
be easier for clients to code to.
If different vendors do interface attachment in different ways then that
ends up being more code on the client side.
Arguing that one way of doing ACL attachment is better than
another is futile and my personal opinion is that there simply is
no one way that's better than all else. A single global
attachment point like what Linux does is not better or worse from
the per interface ACL style that most router vendors employ. It's
just different. I believe the model should allow vendors and
users to express the most common forms we currently have. Not all
ways, but the two or three most common ways, which probably
covers the vast majority of all platforms.
OK, would be happy for 2 ways:
- interfaces
- global
With each of them generic enough to apply reasonably widely.
The current model is an ill fit for platforms that attach filters
globally, like most host firewalls (Linux *tables, OpenBSD pf,
FreeBSD ipfw etc) or the vast majority of firewalls (Juniper SRX,
Cisco ASA, Checkpoint etc). There must be different attachment
options for "per interface" vs "global".
Sure.
As for the per-interface style options
* current draft; a list of ACLs of varying "type", evaluated in
specified order, per-interface and per direction
* three separate ACLs for ethernet, ipv4 and ipv6 and
per-interface and per direction
I think that the current model accommodates both of these.
For the 3 separate ACLs, the vendor would "deviate" the model with
additional constraints so that there could only be one ACL of each type
in the list for an interface.
Given that the model allows mixed ACLs, this approach still seems
reasonable and quite generic to me.
The only vendor I know of that have a single attachment point on
an interface is Huawei. However, it's not just an attachment
point for ACLs but for what Huawei calls a "traffic-policy" which
mixes in ACLs and QoS in the same place. It is so different from
everything else that deviations or augmentations will no doubt be
required to express what they have. The other large router
vendors; Cisco, Juniper and Nokia, all use separate attachment
points for ipv4, ipv6 and ethernet.
Shouldn't we have a model that supports;
* virtually all host network stacks
* virtually all firewalls
* the vast majority of high end routers
Yes, if we can.
Thanks,
Rob
Rather than:
* no currently existing platform (or is there one I don't know of?)
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 ...
+1 on augmentation of interfaces.
kll
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
