Subject: Re: [netmod] mandatory ACL type (was "comments on acl-model-02")

From: "Dana Blair (dblair)" <[email-masked]>
Date: Mon, 1 Jun 2015 14:06:07 +0000

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.

>
>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.

>
>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.

thanks,
Dana

>
>Regards,
>Jason
>
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Nabil Michraf <[email-masked]>
Date: Mon, 1 Jun 2015 11:31:50 -0700

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Jun 2015 14:00:09 -0700

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