Subject: [netmod] comments on acl-model-02

From: "Sterne, Jason (Jason)" <[email-masked]>
Date: Mon, 23 Mar 2015 22:56:02 +0000

Hi all,

I know there are some updates & discussions happening (maybe right now) around the ACL model and I wanted to add some input.

A) It would 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.

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

B) I preferred the type as mandatory in an older version of the draft and would like to see it as part of the key. That allows the same acl-name to be reused per type.  That maps better to a mix of implementations that have a single global namespace and implementations that have a namespace per acl type. 

If some vendors allow mixing types and have a single global namespace then they could augment with a "mixed" type and always use that in their lists. Are there actually vendors who mix types in a single list ?  I'd imagine it is more common to use multiple lists on a target (e.g. interface) to achieve mixed-layer ACLs rather than mixing the rules for multiple layers in the same ACL.

C) entries are "ordered-by user" in the current version. Some implementations use integers as ACE entry keys. That can work in the current model (e.g. by augmenting the entry name string type with a 'pattern' statement) if we either:
i) remove the "ordered-by user" and let vendors augment with that statement, or
ii) make that an if-feature ace-user-ordered

D) The proposed solution of making source-port-range a presence container and then having 'lower-port' as mandatory (with the constraint that lower-port < upper-port) seems like a good one.

E) Please make the metadata optional with an if-feature (or make each of input-interface & time-range their own if-features).  Or drop those out of the model and leave them to augmentations.

F) minor editorial:  In section 3 there is a sentence about Metadata that mentions 'destination prefix length'.  I'm not sure that makes sense. That is more of a matching criteria (i.e. a rule in a routing filter) than a piece of metadata about a particular packet.

Regards,
Jason