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

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Sun, 20 Sep 2015 20:23:58 +0000

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Sep 2015 09:13:57 +0200 (CEST)

Hi,

See below for some clarifying questions.

"Sterne, Jason (Jason)" <[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:
> 

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

---

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Mon, 21 Sep 2015 13:11:27 +0000

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:[email-masked]] 
Sent: Monday, September 21, 2015 3:14
To: Sterne, Jason (Jason)
Cc: [email-masked]
Subject: Re: [netmod] ACL Model 03 - ACL Type should be mandatory

Hi,

"Sterne, Jason (Jason)" <[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:
> 
>      by containing L2, L3 and L4 entries"; }
> 
> identity ip-acl {
>   base acl:acl-base;
>   description
>      layer 3 and/or layer 4 match conditions."; }
> 
> identity eth-acl {
>   base acl:acl-base;
>   description

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

>     the ethernet header or the IPv6 header."; }
> 
> identity ipv6-acl {
>   base acl:acl-base;
>   description
>     the ethernet header or the IPv4 header."; }
>   
> identity eth-acl {
>   base acl:acl-base;
>   description
>      the IPv4 header, IPv6 header or layer 4 headers."; }
> 
> 
> >> 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 
> >> >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.
> 
> 
> >> >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).
> >>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 Sep 2015 15:16:33 +0200 (CEST)

"Sterne, Jason (Jason)" <[email-masked]> 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 ?
> 

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

> > For future mixed types vendors (or the ietf) could augment the
> > acl-type-base with types like the following:
> > 
> >   identity mixed-l3-acl {
> > 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
> > 
> > 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").
> > 
> > [>>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).
> > 
> > >>
> > >> >
> > [>>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.
> > 
> > >>
> > >> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Sep 2015 16:23:21 +0200

> I met with Dean at IETF93 and we agreed that I should send a specific proposal to the list for this.  Here it is:

Well, originally we had "name" as the only key but some routing folks
insisted on having "type" as the second key. Personally, I am not
entirely sold to this idea.

The thing is: YANG requires config lists to have keys but it doesn't
mean these keys need to be the same as parameters that are understood as
keys in a CLI.

One advantage of having YANG list keys separate from "public" keys is
that a user is free to change the public keys, and it also doesn't break
any internal references in the configuration. If you have "acl-type" and
"acl-name" as YANG list keys, then they cannot be changed.

So in fact I'd suggest to have an opaque ID as the only list key, and
then "acl-name" and "acl-type" as non-key leafs, perhaps subject to a
unique constraint.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 21 Sep 2015 14:50:21 +0000

>entirely sold to this idea.

Why not? Existing products support these semantics… Different types of
access-list should have independent name spaces (i.e., one should be able
to have an IP ACL named foo, an IPv6 ACL named foo, and a L2 ACL named
foo). 

Thanks,
Acee 

>>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).
>>
>>augment for future "mixed" types (or maybe we should make an if-feature
>>for a "mixed" type now that means "anything goes").
>>
>> [>>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).
>>
>>>>
>>>> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Sep 2015 20:43:50 +0200

> On 21 Sep 2015, at 16:50, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

Sure, but that’s (I assume) how the operators see and address the ACLs in their CLI or other user interface, and this needn’t change at all. But sometimes operators might also want to change the name of one of the lists from “foo” to “bar”, and this wouldn’t be possible if the name is a list key as required by YANG - except via deleting the ACL and creating it again with a different name, which is hardly an attractive option.

Lada