Re: [netmod] IETF ACL model

[Martin Bjorklund <[e-mail]>]

Mahesh Jethanandani <[e-mail]> wrote:
> [Taking the discussion to the mailing list]
> 
> The summary of the discussion happening on a private thread has to
> do with the ‘any’ container (now leaf) definition in the ACL model
> for something that matches anything, much like a ‘*’ would do in
> regex. The discussion has come down to: 
> 
> - leave the definition as is, so users would have to explicitly define it
>   pro: It is explicit and there would be no confusion about its
>   presence or absence.

>   con: It is verbose, in that every access list entry would have to
>   define it.
> 
> - remove the any definition, so an absence of the definition implies
>   match on all.

It wouldn't be the *absence* that implies match on all, but rather it
is the explicit setting of the type to 'any-acl' that means match on
all:

  <acl>
    <name>my-any-acl</name>
    <type>any-acl</type>
  </acl>

Having to also define the leaf "any" as well would just be redundant:

  <acl>
    <name>my-any-acl</name>
    <type>any-acl</type>
    <aces>
      <ace>
        <name>my-any-rule</name>
        <any/>
      </ace>
    </aces>
  </acl>


BTW, I support Kristian's suggestion of have just the "name" as the
key in the "acl" list, and making "type" mandatory.

I also suggest you remove redundant prefixes in the leaf names,
e.g. as above s/acl-type/type/ s/acl-name/name/ and
s/rule-name/name/.  This is how we usually name nodes in the IETF YANG
models.

> The text in the draft would have to be updated to
>   state this, and YANG parsers would need to watch out for the
>   non-definition in the match container.
> 
> Opinion? Preferences?
> 
> p.s. Current CLI configurations require explicit declaration of ‘any’.

But do they also have the acl type definition?


/martin



> 
> > On Nov 20, 2017, at 2:20 PM, Jeff Haas <[e-mail]> wrote:
> > 
> >> 
> >> On Nov 20, 2017, at 4:54 PM, Kristian Larsson <[e-mail]> wrote:
> >> 
> >> 
> >> 
> >> On 2017-11-20 18:26, Jeff Haas wrote:
> >>> IMO, the contention here is a consequence of proof by assertion. >
> >>>> On Nov 17, 2017, at 5:56 AM, Kristian Larsson <[e-mail] <mailto:[e-mail]>> wrote:
> >>>> 
> >>>>>> 
> >>>>>> Changes I'd like to see to this PR:
> >>>>>> * remove any-acl completely as it serves no purpose (we achieve
> >>>>>>  this through a ACE with no match conditions)
> >>>>> Will let Jeff respond as he articulated this requirement. Agree that most platforms have deny as the default. But what if the ace entry is something like this:
> >>>>> access-list 11 permit tcp any any
> >>>>> Would the absence of match rules for IP addresses imply any any?
> >>>> 
> >>>> An absence of any match means it matches on everything. If there are no IP matches at all, then yes, it implies any source or destination address. I don't see why we would need to explicitly have an any-acl container or leaf to point this out. With the same concept applied uniformly you would explicitly call out "any" matches for all types of matches. That would be extremely verbose.
> >>> Where in the model does it say that the absence of a matches container implies a match all vs. match none?
> >>> Where in the normative text of the internet-draft does it say that?
> >>> In the absence of either of the above, an "any" removes ambiguity.
> >>> FWIW, I'm totally fine with removing the any; however you *MUST* clarify the above.  Preferably both in the matches container and also in the normative text.  For my part, I think it's easier on the parser if you basically require at least one item from the container so you don't have to deal with optional contents.  But I'm not the one writing yang parsers for a living.
> >> 
> >> I think it's clear that if no match condition is defined for a particular (header) field then that means any value will match. It is only an extension of this that no match conditions at all means we match any and all packets. I think that is logical.
> >> 
> >> This can naturally be spelled out in the text :)
> > 
> > You think it's clear, but where is it in the document or model?
> > 
> > Of such "implied clarity" is many interop bugs made. :-P
> > 
> > -- Jeff
> > 
> >> 
> >> Kind regards,
> >>  Kristian.
> 
> Mahesh Jethanandani
> [e-mail]
>