+1 It should represent business logic rather than a subset of existing features.
Regards, Jeff > On Aug 23, 2016, at 2:41 PM, Sam Aldrin <[email protected]> wrote: > > Model design shouldn't be limited by the device capabilities, rather it > should be agnostic. > The existing IETF model is more of a YANG version of CLI, which is rather > limiting from operational perspective. > > How do we (operators) like to see ACL model should be? take a look at the > model we published (work in progress) at > <https://github.com/openconfig/public/tree/master/release/models/acl> > > -sam > >> On Mon, Aug 22, 2016 at 7:04 AM, Adrian Pan <[email protected]> wrote: >> Hi Dean, >> >> >> >> 3) With the model definition, even the acl-type is configured as Ethernet, >> the operator still can configure the matches of ace under the acl as ipv4 or >> ipv6, right? >> >> >> >> No, if ACL type is ethernet, then all ACEs are expected to be ethernet. >> >> [Adrian] I understand your point, but this is not reflected in the model, if >> according to the model, the operator still can configure the acl-type as >> Ethernet, while configure the ace of the acl as ipv4, and this should be >> valid configuration. >> >> >> is this the model design intention? >> >> >> >> If acl-type is of one family, then only ace with match condition from that >> family are expected to be in the acl. If you want to combine them, please >> use mixed type. >> >> [Adrian] if it’s only expected to be the same as the acl-type, but without >> the restriction in the model, you can’t avoid the operator configuration to >> mix the acl-type and the ace matches. So my thinking is that, can we add the >> restriction in the model for this as below to better reflect the model >> design intention? >> >> >> >> >> >> >> >> container matches { >> >> description >> >> "Definitions for match criteria for this Access List >> >> Entry."; >> >> >> >> container ace-ipv4 { >> >> when "../../acl-type='ipv4-acl'"; >> >> description "IPv4 Access List Entry."; >> >> uses packet-fields:acl-ip-header-fields; >> >> uses packet-fields:acl-ipv4-header-fields; >> >> } >> >> container ace-ipv6 { >> >> when "../../acl-type='ipv6-acl'"; >> >> description "IPv6 Access List Entry."; >> >> uses packet-fields:acl-ip-header-fields; >> >> uses packet-fields:acl-ipv6-header-fields; >> >> } >> >> container ace-eth { >> >> when "../../acl-type='eth-acl'"; >> >> description >> >> "Ethernet Access List entry."; >> >> uses packet-fields:acl-eth-header-fields; >> >> } >> >> } >> >> >> >> >> >> Thanks >> >> Adrian >> >> >> >> From: Dean Bogdanovic [mailto:[email protected]] >> Sent: Monday, August 22, 2016 5:39 PM >> To: Adrian Pan <[email protected]> >> Cc: [email protected]; [email protected]; [email protected]; netmod WG >> <[email protected]> >> Subject: Re: Question about acl-type in draft-ietf-netmod-acl-model-08 >> >> >> >> (+netmod mailing list) >> >> Adrian, >> >> >> >> Please see inline >> >> On Aug 22, 2016, at 2:27 AM, Adrian Pan <[email protected]> wrote: >> >> >> >> Dear authors, >> >> >> >> I have some questions about ietf acl model as below, your reply is >> appreciated. >> >> >> >> 1) In the model definition acl-type is one key of the acl, also in the >> description it says that the acl-type could be ethernet, IPv4, IPv6, mixed, >> in case the acl-type is mixed, what’s the identifier should be? >> >> Should it be augmented by different vendor? Since I don’t see the >> definition about it. >> >> >> >> As mixed ACLs are not supported by all vendors, those are not part of the >> standard model. Iit is up to the vendor to augment the ace-type and select >> an identifier to their liking. >> >> >> >> >> 2) In the “mix” case, the “matches” the ace list can be the combination of >> Ethernet,ipv4,ipv6 for different ace, right? >> >> >> >> Or another combination, again depends on what that particular vendor >> supports. >> >> >> 3) With the model definition, even the acl-type is configured as Ethernet, >> the operator still can configure the matches of ace under the acl as ipv4 or >> ipv6, right? >> >> >> >> No, if ACL type is ethernet, then all ACEs are expected to be ethernet. >> >> >> is this the model design intention? >> >> >> >> If acl-type is of one family, then only ace with match condition from that >> family are expected to be in the acl. If you want to combine them, please >> use mixed type. >> >> >> >> Dean >> >> >> >> >> module: ietf-access-control-list >> +--rw access-lists >> +--rw acl* [acl-type acl-name] >> +--rw acl-name string >> +--rw acl-type acl-type >> +--ro acl-oper-data >> +--rw access-list-entries >> +--rw ace* [rule-name] >> +--rw rule-name string >> +--rw matches >> | +--rw (ace-type)? >> >> >> 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."; >> >> } >> >> >> >> >> >> >> Thanks >> >> Adrian >> >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
