On 03/11/2017 10:12, Kristian Larsson wrote:
On Fri, Nov 03, 2017 at 09:30:01AM +0000, Robert Wilton wrote:
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:
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.
Cool.
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.
Fair enough. I actually discussed this solution off-list
yesterday evening but failed to bring it up as a potential
solution now ;)
Given that the model allows mixed ACLs, this approach still seems reasonable
and quite generic to me.
Sure. I guess the XPath on IOS XR, which supports one eth acl,
one ipv4 acl and one ipv6 acl per interface becomes a little
tricky. Like we have to do count() based on acl-type I guess to
prevent two ACLs of the same type being set (or say that the
translation mechanism should logically merge multiple ACLs).
Yes. I thought XR either allowed a v4 and a v6 ACLs, or no IP ACL and
just an Ethernet ACL.
If so the constraint should be something very roughly like:
- deviate add max-elements 2
- deviate add unique "type"
- deviate add must (count(set-name) != 2, or acl_type != eth).
Or, if one of each type is allowed, then this would just be:
- deviate add max-elements 3
- deviate add unique "type"
JUNOS also has different attachment points that each accept a
list of ACLs so it's just a matter of putting a constraint on
accepted acl-type and the translation mechanism just sorts based
on acl-type.
I'm happy with this :)
Cool.
Rob
kll
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
