Thanks Lisa. Are you also planning to split the acl-type into: ipv4-acl ipv6-acl eth-acl ?
That matches how most ACLs are managed today and is also more in sync with the ace-type choice statement. Regards, Jason -----Original Message----- From: Lisa (Yi) Huang [mailto:[email protected]] Sent: Friday, September 25, 2015 12:35 To: Sterne, Jason (Jason); [email protected] Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory Jason, We investigate your proposal and will add acl-type as key to acl list in our next version of draft. acl in the draft. list acl { key "acl-type acl-name"; ... Leaf acl-name {.} leaf acl-type {...} ... } Thanks, Lisa On 9/20/15, 1:23 PM, "netmod on behalf of Sterne, Jason (Jason)" <[email protected] on behalf of [email protected]> 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."; >} > >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); [email protected] >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:[email protected]] On Behalf Of Sterne, >Jason >(Jason) >Sent: Friday, July 17, 2015 23:35 >To: [email protected] >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:[email protected]] On Behalf Of Andy Bierman >Sent: Monday, June 01, 2015 17:00 >To: Nabil Michraf >Cc: [email protected] >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 ><[email protected]> >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) >> <[email protected]> >> wrote: >>> >>> >>> >>> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)" >>> <[email protected]> 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 >>> >[email protected] >>> >https://www.ietf.org/mailman/listinfo/netmod >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> > >_______________________________________________ >netmod mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/netmod >_______________________________________________ >netmod mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/netmod >_______________________________________________ >netmod mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
