On Fri, Nov 3, 2017 at 3:40 AM, Robert Wilton <[email protected]> wrote:
> > > 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. > > > IOS-XR allows IPV4 and IPV6 ACL's on L3 interfaces. It allows Ethernet > ACL's on L2 interfaces Sonal. > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
