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

Sonal Agarwal <sagarwal12@gmail.com> Sat, 04 November 2017 18:01 UTC

Return-Path: <sagarwal12@gmail.com>
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 4C17813FBC7 for <netmod@ietfa.amsl.com>; Sat, 4 Nov 2017 11:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 LPqQC0rThrFb for <netmod@ietfa.amsl.com>; Sat, 4 Nov 2017 11:01:14 -0700 (PDT)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 28E8613FBB8 for <netmod@ietf.org>; Sat, 4 Nov 2017 11:01:14 -0700 (PDT)
Received: by mail-qt0-x22b.google.com with SMTP id n61so6703757qte.10 for <netmod@ietf.org>; Sat, 04 Nov 2017 11:01:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wtcusBII4kTzaidOuxuXdJGnH2LpGgI42vWvykjMA5w=; b=DokrI7xRZp5ol66Kc9eRGsSft1ZOMVbsb49HoowG9ZRN4PIIfDqeacpbQ40eFTRHKG yRWOEYYwApUhO4Vxj0R6qdcT4Lu942uALaydR5X3JRFPkMXI/DMk8P2KC+NnQH0+0Ne0 G8o2P2m4wqrcCZMkGZ0HkEMwXuwBQ21gRjdPsh9rKCty8Titfztrin9eMECsqsp+MmN1 NsJKcAF8tsiyN5viZ32Fh9Fiwkcd9UDXG8h/9pwhIBfF12JtZ7pvTzg24ycrSpAfP3CH i4VosWjkgisuKJRV9Es357NmYj7tZyzGA4KveLTtw8N9Wwuyuny1oSOEtdeTUMmb4J98 2Egg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wtcusBII4kTzaidOuxuXdJGnH2LpGgI42vWvykjMA5w=; b=mMexcsc8M6Tv5+QBmjchiHAlfYalTnYdv8m6SQCkVASUm0umrHLSYd22/xAecKED0s gLaZgwylXmERf8Uni4EjptN6IaPE7qK/Voq68W+KG23gYrNTuNk9ULAtucfGqGSyV2kY DjegbkOLodm2GuzS28NHJCgElD6kF040vEDqGUKGltwKxEZ7E+UJeVaTyCg6lt74q7iA rhP/7D0BrY1f/of6WHDOmfnJBSCL0ovSCVcH77cb/e4kye/gVixgYIkJJxPVtyrpTz8G 4S7GaJZ2XlC7osFMeP/OYxs0fPcYNhM5YDmucW0/JFThUMkuGALzJZhKBibPwjB/ZCbl W4AA==
X-Gm-Message-State: AMCzsaVvOUYONGeuwn98IY4NZeJEyvjYBK7dND18wPGbzjZaSO4sN5W9 5sD1Tps1bdLrvm9LU+0qfff1CocixNL371Mlo/RQGg==
X-Google-Smtp-Source: ABhQp+Rp4Qy9wHJ/iuGK2eFYFsGmPY40tGNArio2bYSF71GtPddbSufnzCReq3IS29AVCEzc9qqHnablzYKKU7ANPTA=
X-Received: by 10.200.7.74 with SMTP id k10mr14959173qth.279.1509818473331; Sat, 04 Nov 2017 11:01:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.109.136 with HTTP; Sat, 4 Nov 2017 11:01:12 -0700 (PDT)
In-Reply-To: <63d922fe-0f83-f5e7-44a0-7d8abe58aa12@cisco.com>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <ac9fc676-80f7-723d-9a85-c99fbb122476@cisco.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <c90aa6c1-340e-2225-f960-73c1395041c5@cisco.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <22bb1ad7-070b-68e1-b35a-bce01204b840@cisco.com> <20171103101225.GJ12688@spritelink.se> <63d922fe-0f83-f5e7-44a0-7d8abe58aa12@cisco.com>
From: Sonal Agarwal <sagarwal12@gmail.com>
Date: Sat, 4 Nov 2017 11:01:12 -0700
Message-ID: <CAMMHi8gV7GCM9=hHXfQBwbEMpzYqDTkp77AQnNv5UATnC4XQBQ@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Kristian Larsson <kristian@spritelink.net>, netmod@ietf.org
Content-Type: multipart/alternative; boundary="f403043a82ccc73fa9055d2c01bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/z55ovr-Y2SJyveQvPs9eAK0HpeI>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Nov 2017 18:01:16 -0000

On Fri, Nov 3, 2017 at 3:40 AM, Robert Wilton <rwilton@cisco.com>; wrote:

>
>
> On 03/11/2017 10:12, Kristian Larsson wrote:
>
>> On Fri, Nov 03, 2017 at 09:30:01AM +0000, Robert Wilton wrote:
>>
>>>
>>> On 03/11/2017 08:42, Kristian Larsson wrote:
>>>
>>>> On Thu, Nov 02, 2017 at 05:38:02PM +0000, Robert Wilton wrote:
>>>>
>>>>> On 02/11/2017 16:41, Kristian Larsson wrote:
>>>>>
>>>>>> Are we seeking to have a single style of attachment points? I
>>>>>> think that's difficult in reality. Linux has one style, where a
>>>>>> single global "ACL" is defined. Most routers use per interface
>>>>>> ACL and as seen, they split it up on ethernet vs IP (and v4 vs
>>>>>> v6). I doubt one can be said to be better than the other so
>>>>>> trying to argue that everyone should converge on one way is
>>>>>> pointless. Similarly supporting every different style is also
>>>>>> futile as it's completely against the point of standardisation.
>>>>>>
>>>>>> The pragmatic compromies is likely to support a few ways and any
>>>>>> vendor that needs something radically different need to build
>>>>>> their own model, do augment, deviate, refine or whatever. Other
>>>>>> thoughts?
>>>>>>
>>>>> For interface attachments I think that the approach in the draft looks
>>>>> OK,
>>>>> and reasonably generic, but will need vendor deviations. This is
>>>>> probably
>>>>> OK.
>>>>>
>>>> I don't agree. Given the length we've gone in trying to convey the
>>>> match capabilities of the platform I think we can afford to give
>>>> implementors some options when it comes to attachment too! :)
>>>>
>>> I  agree that interface vs global are two different styles, and happy if
>>> the
>>> model supports both.
>>>
>> Cool.
>>
>>
>>
>> As for the per-interface style options
>>>>   * current draft; a list of ACLs of varying "type", evaluated in
>>>>     specified order, per-interface and per direction
>>>>   * three separate ACLs for ethernet, ipv4 and ipv6 and
>>>>     per-interface and per direction
>>>>
>>> I think that the current model accommodates both of these.
>>>
>>> For the 3 separate ACLs, the vendor would "deviate" the model with
>>> additional constraints so that there could only be one ACL of each type
>>> in
>>> the list for an interface.
>>>
>> Fair enough. I actually discussed this solution off-list
>> yesterday evening but failed to bring it up as a potential
>> solution now ;)
>>
>>
>> Given that the model allows mixed ACLs, this approach still seems
>>> reasonable
>>> and quite generic to me.
>>>
>> Sure. I guess the XPath on IOS XR, which supports one eth acl,
>> one ipv4 acl and one ipv6 acl per interface becomes a little
>> tricky. Like we have to do count() based on acl-type I guess to
>> prevent two ACLs of the same type being set (or say that the
>> translation mechanism should logically merge multiple ACLs).
>>
> Yes.  I thought XR either allowed a v4 and  a v6 ACLs, or no IP ACL and
> just an Ethernet ACL.
>
>

> IOS-XR allows IPV4 and IPV6 ACL's on L3 interfaces. It allows Ethernet
> ACL's on L2 interfaces


   Sonal.


> If so the constraint should be something very roughly like:
> - deviate add max-elements 2
> - deviate add unique "type"
> - deviate add must (count(set-name) != 2, or acl_type != eth).
>
> Or, if one of each type is allowed, then this would just be:
> - deviate add max-elements 3
> - deviate add unique "type"
>
>
>> JUNOS also has different attachment points that each accept a
>> list of ACLs so it's just a matter of putting a constraint on
>> accepted acl-type and the translation mechanism just sorts based
>> on acl-type.
>>
>> I'm happy with this :)
>>
> Cool.
>
> Rob
>
>
>>     kll
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>