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

[Sonal Agarwal <[e-mail]>]

On Fri, Nov 3, 2017 at 3:40 AM, Robert Wilton <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>