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); 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
