Hi Martin, I think you raised those questions before about the model and they are useful to discuss but are they specific to my proposed modification to make the type mandatory or do your questions apply equally to the current v3 model as-is ?
We may want to fork off two somewhat independent email threads here: 1) making type part of the key (what I hoped to focus on in this email thread) 2) use acl-type somehow in some constraints on the ace match criteria (your main point) Jason -----Original Message----- From: Martin Bjorklund [mailto:m...@tail-f.com] Sent: Monday, September 21, 2015 3:14 To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory Hi, See below for some clarifying questions. "Sterne, Jason (Jason)" <jason.ste...@alcatel-lucent.com> wrote: > Hi all, > > I met with Dean at IETF93 and we agreed that I should send a specific > proposal to the list for this. Here it is: > > ----------------------------------------------------- > Replace the following current snippets from model-03: > ----------------------------------------------------- > > list acl { > key "acl-name"; > ... > } > > leaf acl-type { > type acl-type; > description > "It is recommended to have an Access Control List with > uniform access list entries, all of the same type. When > this type is not explicitly specified, if vendor > implementation permits, the access control entries > in the list can be mixed, > by containing L2, L3 and L4 entries"; } > > identity ip-acl { > base acl:acl-base; > description > "IP Access Control List is a common name for lists that contain > layer 3 and/or layer 4 match conditions."; } > > identity eth-acl { > base acl:acl-base; > description > "Ethernet Access Control List is name for layer 2 Ethernet > technology Access Control List types, like 10/100/1000baseT or > WiFi Access Control List"; > } > > -------------------- > with the following: > -------------------- > > list acl { > key "acl-type acl-name"; > ... > } > (note this is similar construct to the routing model: > list routing-protocol {key "type name"... ) > > leaf acl-type { > type acl-type; > description > "Type of access control list. Indicates the primary intended > type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc) > used in the list instance."; What exactly does "primary intended type of match criteria" mean? How is the ace-type related to the acl-type? Shouldn't the ace-type-specific params be conditional (with "when") based on the acl-type? /martin > } > > identity ipv4-acl { > base acl:acl-base; > description > "ACL that primarily matches on fields from the IPv4 header > (e.g. IPv4 destination address) and layer 4 headers (e.g. TCP destination > port). An acl of type ipv4-acl does not contain matches on fields in > the ethernet header or the IPv6 header."; } > > identity ipv6-acl { > base acl:acl-base; > description > "ACL that primarily matches on fields from the IPv6 header > (e.g. IPv6 destination address) and layer 4 headers (e.g. TCP destination > port). An acl of type ipv6-acl does not contain matches on fields in > the ethernet header or the IPv4 header."; } > > identity eth-acl { > base acl:acl-base; > description > "ACL that primarily matches on fields in the ethernet header. > An acl of type eth-acl does not contain matches on fields in > the IPv4 header, IPv6 header or layer 4 headers."; } > > > --------------------------------------- > Potential future augmentation of type: > ---------------------------------------- > > For future mixed types vendors (or the ietf) could augment the acl-type-base > with types like the following: > > identity mixed-l3-acl { > base "access-control-list:acl-type-base"; > description "ACL that contains a mix of entries that primarily match on > fields > in IPv4 headers and entries that primarily match on fields in IPv6 > headers. > Matching on layer 4 header fields may also exist in the list. > An acl of type mixed-l3-acl does not contain matches on fields in > the ethernet header."; > } > > identity mixed-l2-l3-acl { > base "access-control-list:acl-type-base"; > description "ACL that contains a mix of entries that primarily match on > fields > in ethernet headers, entries that primarily match on fields in IPv4 > headers, > and entries that primarily match on fields in IPv6 headers. Matching > on layer 4 > header fields may also exist in the list."; > } > > Regards, > Jason > > -----Original Message----- > From: Sterne, Jason (Jason) > Sent: Sunday, July 19, 2015 12:58 > To: Sterne, Jason (Jason); netmod@ietf.org > Subject: RE: ACL Model 03 - ACL Type should be mandatory > > Given the data models below in some of the major implementations it also > seems like we should also (re-)consider having the 'type' as part of the ACL > key ("type name"). > > In all those cases below it looks like an operator can currently configure > two different ACLs (e.g. an IPv4 and an IPv6 ACL) with the same name/id via > their CLI (e.g. a v4 ACL called "my-acl" and a v6 ACL called "my-acl"). > > How would those lists be read in a <get-config> via the ietf ACL YANG modules > ? We'd all have to mangle the names and reserve special names/prefix-chars > (e.g. _ipv4-my-acl and _ipv6-my-acl) to send them back to a NC client. I'm > not sure if there is much of a disadvantage of just having type in the key > (assuming it is mandatory as advocated below). > > I also looked briefly at the Brocade YANG models on github. It looks like > they have multiple lists as well for v4 vs v6 (and even or different types of > normal vs extended ACLs - that could be handled by augmenting the type with a > 'v4-extended' type for example). > > Regards, > Jason > > -----Original Message----- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Sterne, > Jason (Jason) > Sent: Friday, July 17, 2015 23:35 > To: netmod@ietf.org > Subject: [netmod] ACL Model 03 - ACL Type should be mandatory > > 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 > _______________________________________________ > 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
