"Sterne, Jason (Jason)" <[email protected]> writes:
> 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"... )
Well, originally we had "name" as the only key but some routing folks
insisted on having "type" as the second key. Personally, I am not
entirely sold to this idea.
The thing is: YANG requires config lists to have keys but it doesn't
mean these keys need to be the same as parameters that are understood as
keys in a CLI.
One advantage of having YANG list keys separate from "public" keys is
that a user is free to change the public keys, and it also doesn't break
any internal references in the configuration. If you have "acl-type" and
"acl-name" as YANG list keys, then they cannot be changed.
So in fact I'd suggest to have an opaque ID as the only list key, and
then "acl-name" and "acl-type" as non-key leafs, perhaps subject to a
unique constraint.
Lada
>
> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
