Hi all, I think we need to revisit this discussion about how ACL type works in draft-ietf-netmod-acl-model-03.
It should be mandatory and we should separate v4 from v6. Vendors can augment for future "mixed" types (or maybe we should make an if-feature for a "mixed" type now that means "anything goes"). We should follow existing common implementations for this in order to foster better adoption. Cisco IOS-XR has separate lists for ipv4 and ipv6 and part of specifying the list: ipv4 access-list <name> ipv6 access-list <name> Junos has separate lists for v4 and v6: access-list <xyz> ... ipv6 access-list <abc> ... ALU SR OS has separate lists for v4, v6 and mac: config filter ip-filter <abc> config filter ipv6-filter <def> config filter mac-filter <ghi> Huawei uses separate lists for v4 and v6: acl number 3000 acl ipv6 number 3000 Please see below with [>>JTS] Regards, Jason -----Original Message----- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Andy Bierman Sent: Monday, June 01, 2015 17:00 To: Nabil Michraf Cc: netmod@ietf.org Subject: Re: [netmod] mandatory ACL type (was "comments on acl-model-02") Hi, That appears to be the current version on the data-tracker. I agree with you that the access-control-list-type leaf should be mandatory. I noticed that the example in Figure 2 has an extra 'top' container and the namespace for 'access-lists' is missing. Andy On Mon, Jun 1, 2015 at 11:31 AM, Nabil Michraf <nabil.mich...@gmail.com> wrote: > Hi all, > > Can you please clarify if we are talking about > https://www.ietf.org/id/draft-ietf-netmod-acl-model-02.txt or some > other draft? > I just want to make sure I am looking at the right ACL model version. > > Thank you, > Nabil > > On Mon, Jun 1, 2015 at 7:06 AM, Dana Blair (dblair) <dbl...@cisco.com> > wrote: >> >> >> >> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)" >> <jason.ste...@alcatel-lucent.com> wrote: >> >> >Hi guys, >> > >> >Extracting my comments about ACL type into its own thread. I saw >> >Martin also had some comments on this topic. >> > >> >The ACL type was mandatory in an older version of the draft and I >> >think we should put it back as mandatory. Implementations that >> >don't *need* that leaf value can work fine whether they get it >> >during ACL creation or not but some implementations need to know the type. >> >> We don¹t want to make the ACL type mandatory because then we have to >> a create a new type for every combination of match criteria. The >> model should support any combination of match criteria with typing >> optional to map to pre-existing implementations. This is a tradeoff >> between making the model backward compatible with existing >> implementations but make it flexible enough so that a new match >> criteria doesn¹t require a new type. [>>JTS] We can just create a "mixed" (i.e. unspecified) type and put it under an if-feature. Existing implementations have a single type (and require knowing the type at list creation time). >> >> > >> >It would also be good to create separate identities for >> >IPv4-access-control-list and IPv6-access-control-list instead of >> >bundling them into IP-access-control-list. If we're separating into >> >types in the model it should be the 3 basic types in the base model: v4, >> >v6 and enet. >> >> A vendor specific augmentation/implementation could do this, but the >> model needs to support inclusion of ipv4 and ipv6 in the same acl. >> I¹m aware of outstanding customers requests for combining ipv4 rules >> and ipv6 rules in the same acl, but most implementations have not >> caught up to this. When it comes to managing acls there shouldn¹t be >> this distinction between IPv6 and IPv4. They are both IP addresses. [>>JTS] Again - let's focus on capturing common existing implementations in these standard models (while also allowing for augmentation and flexibility). V4 and V6 are in separate lists today. A future mixed list can use the "mixed" type or invent a new "v4+v6" type. >> >> > >> >That would also help if we decide to put some constraints that >> >allow/disallow certain matching criteria when the type is a specific >> >value (e.g. don't allow a v6 address match in a v4 list). >> > We'd have to be careful about how those constraints are formulated >> >though - especially if we want to allow augmentations of the >> >list-type for "mixed" ACLs. A new "mixed-v4-enet" type (identity) >> >would also need to use the destination-ipv4-network matching >> >criteria (can "when" or "must" logic be changed by an augmentation ? I'm >> >not sure that works). >> >> Yes, would have to be careful, and defining constraints based on existing >> implementations could be a very slippery slope. Vendors should be able >> to map to their implementations and/or have a proprietary >> augmentation that constrains things more according to >> their implementation. Proprietary augmentations could be proposed, and >> reviewed for standardization. [>>JTS] The draft doesn't have any constraints based on type so I suppose this point is moot. >> >> thanks, >> Dana >> >> > >> >Regards, >> >Jason >> > >> > >> >_______________________________________________ >> >netmod mailing list >> >netmod@ietf.org >> >https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
