"Sterne, Jason (Jason)" <jason.ste...@alcatel-lucent.com> wrote: > 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)
I think they are related; if the ace match criteria has no coupling to the acl-type it is not clear to me why the acl-type is needed at all. And if there is a coupling, then I agree the acl-type should be part of the key (or made mandatory). /martin > > 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
