On 9/21/15, 10:23 AM, "netmod on behalf of Ladislav Lhotka"
<netmod-boun...@ietf.org on behalf of lho...@nic.cz> wrote:
>"Sterne, Jason (Jason)" <jason.ste...@alcatel-lucent.com> 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.
Why not? Existing products support these semantics… Different types of
access-list should have independent name spaces (i.e., one should be able
to have an IP ACL named foo, an IPv6 ACL named foo, and a L2 ACL named
foo).
Thanks,
Acee
>
>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); netmod@ietf.org
>> 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:netmod-boun...@ietf.org] On Behalf Of Sterne,
>>Jason (Jason)
>> Sent: Friday, July 17, 2015 23:35
>> To: netmod@ietf.org
>> 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:netmod-boun...@ietf.org] On Behalf Of Andy Bierman
>> Sent: Monday, June 01, 2015 17:00
>> To: Nabil Michraf
>> Cc: netmod@ietf.org
>> 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
>><nabil.mich...@gmail.com> 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) <dbl...@cisco.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 4/13/15, 10:11 AM, "Sterne, Jason (Jason)"
>>>> <jason.ste...@alcatel-lucent.com> 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
>>>> >netmod@ietf.org
>>>> >https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
