Jason,
We investigate your proposal and will add acl-type as key to acl list in
our next version of draft.
acl in the draft.
list acl {
key "acl-type acl-name";
...
Leaf acl-name {…}
leaf acl-type {...}
...
}
Thanks,
Lisa
On 9/20/15, 1:23 PM, "netmod on behalf of Sterne, Jason (Jason)"
<[email protected] on behalf of [email protected]>
wrote:
>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); [email protected]
>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:[email protected]] On Behalf Of Sterne, Jason
>(Jason)
>Sent: Friday, July 17, 2015 23:35
>To: [email protected]
>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:[email protected]] On Behalf Of Andy Bierman
>Sent: Monday, June 01, 2015 17:00
>To: Nabil Michraf
>Cc: [email protected]
>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 <[email protected]>
>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) <[email protected]>
>> wrote:
>>>
>>>
>>>
>>> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
>>> <[email protected]> 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
>>> >[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
>>
>
>_______________________________________________
>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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
