Right, it's not about the concept as such, I think we've agreed that having a global attachment point is fine. It's just that we need to polish the actual implementation and seeing how it be good to merge the current PR I suggested we put the global attachment point in a separate PR. Eases the workflow :)
kll Mahesh Jethanandani <mjethanand...@gmail.com> writes: > For now. > > Kristian and I discussed this, and agreed that we will pull it in in a new > pull request. > >> On Nov 29, 2017, at 4:08 PM, Sonal Agarwal (agarwaso) <agarw...@cisco.com> >> wrote: >> >> Are you removing the definition of “global” ACL? >> >> - >> leaf global { >> - >> if-feature global-attachment; >> - >> type >> empty; >> - >> description >> - >> "ACL rule is global"; >> - } >> >> The remaining changes look fine to me. >> >> Thanks, >> --- >> Sonal Agarwal >> >> From: Mahesh Jethanandani <mjethanand...@gmail.com >> <mailto:mjethanand...@gmail.com>> >> Date: Wednesday, November 29, 2017 at 12:11 PM >> To: NetMod WG <netmod@ietf.org <mailto:netmod@ietf.org>> >> Cc: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" >> <rwil...@cisco.com <mailto:rwil...@cisco.com>>, Jeffrey Haas >> <jh...@juniper.net <mailto:jh...@juniper.net>>, Cisco Employee >> <agarw...@cisco.com <mailto:agarw...@cisco.com>>, Kristian Larsson >> <k...@spritelink.net <mailto:k...@spritelink.net>>, Kristian Larsson >> <k...@dev.terastrm.net <mailto:k...@dev.terastrm.net>>, Martin Bjorklund >> <m...@tail-f.com <mailto:m...@tail-f.com>> >> Subject: Re: [netmod] IETF ACL model >> >> The updated commit here >> <https://github.com/netmod-wg/acl-model/pull/19/commits/37e4c030180ae052a5fae26ca86813970fc6b4bf> >> takes care of restoring “type" to "acl-type", fixes some indentation >> issues, adds a choice for “l3" where either “ipv4" or “ipv6" can be >> selected, and a similar choice at “l4" that allows either “tcp", “udp" or >> “icmp" to be selected, and removes changes for “global" attachment point. >> Will add the last item as a separate commit. >> >> Unless I hear objections, I will roll the pr/18 changes into the master >> branch in 48 hours. >> >>> On Nov 28, 2017, at 2:17 AM, Martin Bjorklund <m...@tail-f.com >>> <mailto:m...@tail-f.com>> wrote: >>> >>> Mahesh Jethanandani <mjethanand...@gmail.com >>> <mailto:mjethanand...@gmail.com>> wrote: >>>> An updated version of the model has been posted as part of the PR here >>>> <https://github.com/netmod-wg/acl-model/commit/2477cd400cce6d39933c908ad97da27ff759588b >>>> >>>> <https://github.com/netmod-wg/acl-model/commit/2477cd400cce6d39933c908ad97da27ff759588b>>. >>>> >>>> The particular change removes any-acl from the model, expands on eth >>>> (to ethernet), removes acl- prefix for things like acl-type and >>>> acl-name. Please review. >>> >>> I think 99% of the changes in this PR look good. The one >>> exception is the typedef that used to be called "acl-type". I think >>> it should still be called "acl-type". "type" is too broad. NOTE, >>> this is just the typedef; the leaf /access-lists/acl/type should keep >>> its name ("type"). >>> >>> >>> /martin >>> >>> >>> >>>> >>>>> On Nov 27, 2017, at 5:17 AM, Kristian Larsson <k...@dev.terastrm.net >>>>> <mailto:k...@dev.terastrm.net>> >>>>> wrote: >>>>> >>>>> >>>>> Robert Wilton <rwil...@cisco.com <mailto:rwil...@cisco.com>> writes: >>>>> >>>>>> Thinking about this some more. I'm not sure what it means for the "ACL >>>>>> Type" to be "any-acl". It seems that the "match any packet" should be >>>>>> a >>>>>> type of ACE, e.g. perhaps as the last entry of an ACL, rather than a >>>>>> type of ACL. >>>>> >>>>> Yes, I agree as so far that any-acl makes no sense as an acl-type. The >>>>> way I understood acl-type, and the way that vendors have told me it >>>>> will >>>>> be used, is to say "this is an IPv4 ACL" and then on an attachment >>>>> point >>>>> you can specify that only ACLs of acl-type ipv4-acl can be attached to >>>>> the interface. That makes perfect sense. I do not see how any-acl can >>>>> map into this. >>>>> >>>>> I agree that any-acl is logically a type of ACE but we don't have an >>>>> ace-type and the exact same information can IMHO already be conveyed >>>>> WITHOUT the any-acl type and thus it has no reason to exist. Nor do we >>>>> need a feature for it. >>>>> >>>>> From what I can tell the any-acl container in the ACE should be used >>>>> to >>>>> explicitly signify a match on "any". Think of IOS style ipv4 acl: >>>>> permit ip any any >>>>> >>>>> We have to provide a source and destination so this would be a rather >>>>> explicit mapping of that. However, our structure in this YANG model is >>>>> just completely different than an IOS command so I don't see why we >>>>> should try and mimic IOS in the YANg model. >>>>> >>>>> Not specifying a destination IP address means we match on any >>>>> destination IP address. The same is true for any other field we can >>>>> match on. Not setting a match implies we don't try to match on that >>>>> field, thus we allow "any" value. I think the logical continuation of >>>>> this is that for an ACE with no matches defined at all, we match any >>>>> packet. I think we can update the text to better explain this. >>>>> >>>>> >>>>> >>>>>> Otherwise if the ACL type is "any-acl" then this only allows two types >>>>>> of ACLs to be defined, neither of which seem to be particularly >>>>>> useful: >>>>>> (1) An ACL that matches all traffic and permits it, i.e. the same as >>>>>> having no ACL at all. >>>>>> (2) An ACL that matches all traffic and drops. >>>>>> >>>>>> So I think perhaps the answer here is to define neither ACL type >>>>>> "any-acl" nor leaf "any". The presumption could be that any ACE that >>>>>> is >>>>>> configured to match no fields implicitly matches all packets (because >>>>>> all non specified fields are treated as wildcards), and then applies >>>>>> the >>>>>> permit/deny rule associated with the ACE. This logic can apply to all >>>>>> ACL types. >>>>> >>>>> Yes yes yes :) >>>>> >>>>> Kristian. >>>> >>>> Mahesh Jethanandani >>>> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> >>>> >> >> Mahesh Jethanandani >> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > > Mahesh Jethanandani > mjethanand...@gmail.com _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod