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). 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 :) kll -- Kristian Larsson KLL-RIPE +46 72 5479985 [email protected] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
