Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Fri, 2 Oct 2015 19:59:44 +0000

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-masked]] 
Sent: Friday, September 25, 2015 12:35
To: Sterne, Jason (Jason); [email-masked]
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-masked] on behalf of [email-masked]>
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-masked]
>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-masked]] On Behalf Of Sterne, 
>Jason
>(Jason)
>Sent: Friday, July 17, 2015 23:35
>To: [email-masked]
>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-masked]] On Behalf Of Andy Bierman
>Sent: Monday, June 01, 2015 17:00
>To: Nabil Michraf
>Cc: [email-masked]
>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-masked]>
>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-masked]>
>> wrote:
>>>
>>>
>>>
>>> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
>>> <[email-masked]> 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-masked]
>>> >https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod