Hi,
See below for some clarifying questions.
"Sterne, Jason (Jason)" <jason.ste...@alcatel-lucent.com> 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.";
What exactly does "primary intended type of match criteria" mean?
How is the ace-type related to the acl-type? Shouldn't the
ace-type-specific params be conditional (with "when") based on the
acl-type?
/martin
> }
>
> 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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
