Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92FCC126CD6 for ; Sat, 9 Dec 2017 21:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjjMubKcBSZD for ; Sat, 9 Dec 2017 21:09:45 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCE11267BB for ; Sat, 9 Dec 2017 21:09:44 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id l24so9461491pfj.6 for ; Sat, 09 Dec 2017 21:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=2URI5Ti9wgmhVRVBxMAK31DeD6iv5nxGZx86T7Nuddo=; b=LEkiPu7w6B1V7hDUiNR+Hpy9DzBs+q20f0Q7mkjnyDyT27CnaI70o5Qro3aiG0eBeo 1bx3c6TzyRO3va8c/vNDas6OGf9UCYNOMj6VJamqwHZ8HHb+EUPppG9a+Lh3wDXmoEG5 phvX5oNsYTLELQ9Y0+XsYpK1sIPfB3AS+Eu7RIVx3TQKK2AZWqlBMehlrFQXXdsn7aPW EFNQImRtw8OSVMU3RPujRKA5ts3kqZsSnVbMdfhat6b6Js2tBnJhSBnwE/p0iaWnKw0O LxdV9GG37G0laI9Qs2jXaPRMvXBDo+348YyzfPcrRw5FsHhhwmBzzhn74bsb1HbB/i7P GoDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2URI5Ti9wgmhVRVBxMAK31DeD6iv5nxGZx86T7Nuddo=; b=iL6t9C/fbm2wmUk0+QGrSf4Kqc/sX4LFn3tp6jXM+FaxVjW0cbCPexSNiamTuNxZPM EBS+NiskqDIz5MTG08WnZ2pfjHcGEpb8zCI5HWU6J1ZovcOY6g/xp1WvuX7ucS1qm1G4 ofYWcqDdTrnK7Yq+0Cb668DdgK7gokrMTHQoUHsaJfRkADCZ563Hl4+UfLlaZkxN/aWy ctOFZzVLgYs1yeZ5wFpzWSxQJPBhEjO/Tw59kUFeh5N1YuSV7au0Deoz6kVn1aiB0V9k epjSvwqztVCNXex4Iz/LhggKATK18yA8ueGR+MwHFZtbPBX7k/07fU8MDZ9blhKoQSAp Wutg== X-Gm-Message-State: AJaThX4ZQlFjWc5+S4AWfPvoyEaOKsnwXXLoNoSrGsjhWF7QVNqOJooy r2PxoiWUMA0plJ14C5gaOdaFTS2x0/Y= X-Google-Smtp-Source: AGs4zMb6GYIiFmWZNdsBCqznFaz94tQ3qOemL9mLht4CVTCPyD84TGjkvWM6dNm250ei7ApG+fPzZA== X-Received: by 10.101.66.66 with SMTP id d2mr34185213pgq.244.1512882583874; Sat, 09 Dec 2017 21:09:43 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:597a:fdc9:4d62:1b47]) by smtp.gmail.com with ESMTPSA id c28sm20819116pfe.69.2017.12.09.21.09.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Dec 2017 21:09:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Sat, 9 Dec 2017 21:09:41 -0800 Cc: Robert Wilton , Jeffrey Haas , Sonal Agarwal , Kristian Larsson , Kristian Larsson , Martin Bjorklund Message-Id: References: <87y3mr3loc.fsf@dev.terastrm.net> <20171128.111715.2283575031970124402.mbj@tail-f.com> To: NetMod WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] IETF ACL model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 05:09:47 -0000 --Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This PR tries to = address what are hopefully the last set of comments before we publish = the draft for LC. Unless I hear objections, I will roll in these changes by the end of the = week (Dec. 15). > On Nov 29, 2017, at 12:11 PM, Mahesh Jethanandani = wrote: >=20 > The updated commit here = takes care of restoring =E2=80=9Ctype" to = "acl-type", fixes some indentation issues, adds a choice for =E2=80=9Cl3" = where either =E2=80=9Cipv4" or =E2=80=9Cipv6" can be selected, and a = similar choice at =E2=80=9Cl4" that allows either =E2=80=9Ctcp", =E2=80=9C= udp" or =E2=80=9Cicmp" to be selected, and removes changes for = =E2=80=9Cglobal" attachment point. Will add the last item as a separate = commit. >=20 > Unless I hear objections, I will roll the pr/18 changes into the = master branch in 48 hours. >=20 >> On Nov 28, 2017, at 2:17 AM, Martin Bjorklund > wrote: >>=20 >> Mahesh Jethanandani > wrote: >>> An updated version of the model has been posted as part of the PR = here >>> = >. >>>=20 >>> 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. >>=20 >> 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"). >>=20 >>=20 >> /martin >>=20 >>=20 >>=20 >>>=20 >>>> On Nov 27, 2017, at 5:17 AM, Kristian Larsson > >>>> wrote: >>>>=20 >>>>=20 >>>> Robert Wilton > = writes: >>>>=20 >>>>> 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=20 >>>>> type of ACL. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> =46rom 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 >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>>> 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=20 >>>>> having no ACL at all. >>>>> (2) An ACL that matches all traffic and drops. >>>>>=20 >>>>> So I think perhaps the answer here is to define neither ACL type=20= >>>>> "any-acl" nor leaf "any". The presumption could be that any ACE = that >>>>> is >>>>> configured to match no fields implicitly matches all packets = (because=20 >>>>> 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=20 >>>>> ACL types. >>>>=20 >>>> Yes yes yes :) >>>>=20 >>>> Kristian. >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>>=20 >=20 > Mahesh Jethanandani > mjethanandani@gmail.com Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This PR tries to address what are hopefully the last = set of comments before we publish the draft for LC.

Unless I hear objections, I will roll = in these changes by the end of the week (Dec. 15).

On Nov 29, 2017, at 12:11 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

The updated = commit here takes care of = restoring =E2=80=9Ctype" to "acl-type", fixes some indentation issues, = adds a choice for =E2=80=9Cl3" where either =E2=80=9Cipv4" or =E2=80=9Cipv= 6" can be selected, and a similar choice at =E2=80=9Cl4" that allows = either =E2=80=9Ctcp", =E2=80=9Cudp" or =E2=80=9Cicmp" to be selected, = and removes changes for =E2=80=9Cglobal" 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 <mbj@tail-f.com> = wrote:

Mahesh Jethanandani <mjethanandani@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/2477cd400cce6d399= 33c908ad97da27ff759588b>.

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 = <kll@dev.terastrm.net>
wrote:


Robert Wilton <rwilton@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.

=46rom 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
mjethanandani@gmail.com


Mahesh Jethanandani
mjethanandani@gmail.com


Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_303E1E62-296D-44F1-9493-DD34A562B4D4--