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
