Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson <[e-mail]>]

On Tue, Oct 31, 2017 at 11:47:54AM +0100, Eliot Lear wrote:
> Hi Kristian,
> 
> Just my view below:
> 
> 
> On 10/31/17 11:25 AM, Kristian Larsson wrote:
> 
> > This brings us to the acl-type. It seems to me that this is
> > primarily for being able to do YANG validation when a device does
> > NOT support a unified model. I.e. if Linux nftables was all we
> > wanted to model, then we wouldn't need this and the only
> > (implied) acl-type would be l2-l3-ipv4-acl. In reality though, we
> > need acl-type because most current network devices out there have
> > per-AFI types and we want to be able to say:
> >  * this interface attachment point can only do ipv4-acl
> > And still be able to validate the data based on the YANG model.
> > Is this correct? It seems like one hell of a design trade-off to
> > be able to achieve that. Wouldn't we be better off with actually
> > having different list of ACLs, again vastly simplifying the
> > attachment points and making data validation much easier?
> 
> This reflects, IMHO, the complexity of the situation.  You want
> consistent policy implemented to the full extent of device
> capabilities.

I'd argue we are not achieving that anyway because of the
previously mentioned container mess. I.e. on a a Cisco I'd have
to do matches/ipv4-acl/foo while on my Linux machine I'd do
matches/l2-l3-ipv4-ipv6-acl/foo. Thus multiple ACLs need to be
generates for any heterogenous network. We missed the goal with
the model.


>  That means that if someone wants to generate a mixed mode
> ACL, they can.  But if we attempt to separate those mixed modes on the
> device, can we guarantee that we have gotten the intent correct and
> consistent with, say, what would have been the mixed mode?  I think
> that's how we got here but others can speak more authoritatively.  And
> keep in mind, all of this ties to efficient use of device resources, and
> so there's a lot of h/w optimization seemingly going on here.

So how is the current situation better than doing:

module: ietf-access-control-list
    +--rw access-lists
       +--rw acl [acl-name] <<< this is the unified one
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ethernet
       |        |  +--rw ipv4
       |        |  +--rw ipv6
       |        ...

       +--rw ipv4-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

       +--rw ipv6-acl* [acl-name]
       |  +--rw acl-name    string
       |  +--rw aces
       |     +--rw ace* [rule-name]
       |        +--rw rule-name          string
       |        +--rw matches
       |        |  +--rw ipv4
       |        ...

I'm really bothered by the compound key consisting of acl-type
and the acl-name since attachment points then need to reference
both.  It's also weird because I don't think choosing the
acl-type is really a choice of the user but more of a limitation
of the platform.

One approach would be to change the key to only be the acl-name
but let the acl-type leaf remain, perhaps make it mandatory or
default to some unified acl-type. I think it's still possible to
implement a constraint on this, right? Like if a platform only
supports a specific type at some attachment point it can add a
constraint on the acl-type by doing deref() on the leafref.

module a-vendor-module {
  list interfaces {
		leaf ingress-acl {
		  type leafref {
			  path "/acl:access-lists/acl/acl-name";
			}
			must 'yangexp:deref(.)/../acl-type="ipv4-acl"';
		}
  }
}

I think that looks much nicer. Am I missing something?

It would create a single namespace for all ACL types which is
potentially a problem for some vendors when doing backwards
mapping, like they have separate ipv4 and ipv6 acls today and
when starting to support this new model you could end up in a
collision. But if that is the case, would it not be okay to just
prefix the type to the name as part of the data translation?

Kind regards,
   Kristian.

-- 
Kristian Larsson                                        KLL-RIPE
[phone]                                [e-mail]