Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 9 Jun 2016 07:35:45 -0700

Dean/Acee,

Is this a relevant example of ACL being configured on an interface?

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/addr_serv/configuration/guide/b_ipaddr_cg42a9k/b_ipaddr_cg42a9k_chapter_01.html#task_1049371

Talking to implementers, the feature is very much desired.

Mahesh Jethanandani
[email-masked]

> On Apr 2, 2016, at 4:39 AM, Dean Bogdanovic <[email-masked]> wrote:
> 
> Hi Acee,
> 
>> On Mar 31, 2016, at 8:17 AM, Acee Lindem (acee) <[email-masked]> wrote:
>> 
>> Hi Dean, 
>> 
>> From: netmod <[email-masked]> on behalf of Dean Bogdanovic <[email-masked]>
>> Date: Thursday, March 31, 2016 at 5:26 AM
>> To: "Sterne, Jason (Nokia - CA)" <[email-masked]>
>> Cc: netmod WG <[email-masked]>
>> Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?
>> 
>> 
>>> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) <[email-masked]> wrote:
>>> 
>>> Hi all,
>>>  
>>> The ACL model is converging on a small core set of functionality that is fairly common.
>>>  
>>> But I think the matching on input-interface should be removed from the model (or at the least put inside a feature flag).
>>>  
>>> Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But having that input-interface match on metadata in the core model is out of place.  It should be left to further extension drafts or vendor specific augmentations (along with whatever other metadata might be useful or vendor-specific).
>>>  
>>> ACLs are typically assigned to interfaces as shown in section A.3. of the ACL draft.   That is the most common use case.
>>>  
>>> Actually matching on input-interface in the ACL rules themselves is not basic core ACL functionality.  Nokia SR OS does not have that capability.  Does IOS-XR ?  Brocade ?  others ?
>> 
>> Cisco and Juniper support matching on input interface. It is useful when you want to filter on general traffic coming from interface.
>> 
>> Cisco
>> match input-interface
>> match input-vlan
>> 
>> These are “class-map”  sub-commands - not “access-list" sub-commands. So you are referring to the general functionality rather than specifically functionality supported by access-list? 
> 
> According to the Cisco website (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swacl.html)
> 
> Note The ACL must be an extended named ACL.
> 
> – match input-interface interface-id-list
> – match ip dscp dscp-list
> – match ip precedence ip-precedence-list
> 
>> 
>> 
>> 
>> Junos
>> family any {
>> filter L2_filter {
>> term t1 {
>> from {
>> interface fe-0/0/0.0;
>> }
>> then {
>> policer p1;
>> count c1;
>> }
>> }
>> }
>> }
>> 
>> Brocade supports matching based on interface, Dell supports VLAN matching, Arista supports input interface matching, Redback supports matching against input interface for logging,
>> 
>> If you are referring to “log-input”, this indicates to include the input-interface in the log message. Cisco supports this as well. 
>> 
>> Thanks,
>> Acee 
>> 
>> 
>> so it is pretty standard across multiple vendors
>> 
>> Dean
>> 
>>>      If some major implementations don’t do it, and it isn’t necessary for typical basic ACL use, then it should be removed (or feature flagged).
>>>  
>>> Regards,
>>> Jason 
>>>  
>>> _______________________________________________
>>> netmod mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 9 Jun 2016 14:58:08 +0000

Hi Mahesh, 

From:  Mahesh Jethanandani <[email-masked]>
Date:  Thursday, June 9, 2016 at 10:35 AM
To:  Dean Bogdanovic <[email-masked]>
Cc:  Acee Lindem <[email-masked]>, netmod WG <[email-masked]>
Subject:  Re: [netmod] Remove input-interface (metadata) from
netmod-acl-model-07 ?

>Dean/Acee,

I initially misread this as “Dear Acee” ;^)

>http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/a
>ddr_serv/configuration/guide/b_ipaddr_cg42a9k/b_ipaddr_cg42a9k_chapter_01.
>html#task_1049371
>
>

In the same way I misread your salutation, I think you’ve misinterpreted
this example as it applies to including interface in the ACL model. If you
examine the referenced configuration html closely, you’ll see that the ACL
is a reusable packet-matching policy that is applied to an interface
rather than the interface being included in the ACL rules themselves. In
IOS-XR, the command to apply the ACL to an interface is “{ipv4 | ipv6}
access-group <acl-name>” specified in interface configuration submode. Is
there something in the text that I’m missing?

>Talking to implementers, the feature is very much desired.

As the initial implementor of the function on Redback SEOS (now Ericsson
IPOS), I can confirm that attaching an ACL to an interface is, indeed, an
essential function.

Thanks,
Acee 

>>But I think the matching on input-interface should be removed from the
>>model (or at the least put inside a feature flag).
>> 
>>Matching on basic IPv4/IPv4/MAC header fields is common functionality.
>>But having that input-interface match on metadata in the core model is
>>out of place.  It should be left to further extension drafts or vendor
>>specific augmentations (along
>> with whatever other metadata might be useful or vendor-specific).
>>
>>
>> 
>>ACLs are typically assigned to interfaces as shown in section A.3. of
>>the ACL draft.   That is the most common use case.
>> 
>>Actually matching on input-interface in the ACL rules themselves is not
>>basic core ACL functionality.  Nokia SR OS does not have that
>>capability.  Does IOS-XR ?  Brocade ?  others ?
>>
>>
>>
>>
>>Cisco and Juniper support matching on input interface. It is useful when
>>you want to filter on general traffic coming from interface.
>>
>>Cisco
>>match input-interface
>>match input-vlan
>>
>>
>>
>>
>
>These are “class-map”  sub-commands - not “access-list" sub-commands. So
>you are referring to the general functionality rather than specifically
>functionality supported by access-list?
>
>
>
>
>
>According to the Cisco website
>(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/sof
>tware/release/12-2_55_se/configuration/guide/3750xscg/swacl.html)
>
>________________________________________
>
>
>>Brocade supports matching based on interface, Dell supports VLAN
>>matching, Arista supports input interface matching, Redback supports
>>matching against input interface for logging,
>>
>>
>>
>>
>>
>
>If you are referring to “log-input”, this indicates to include the
>input-interface in the log message. Cisco supports this as well.
>
>Thanks,
>Acee 
>
>
>>     If some major implementations don’t do it, and it isn’t necessary
>>for typical basic ACL use, then it should be removed (or feature
>>flagged).
>> 
>>Regards,
>>Jason 
>> 
>>netmod
>> mailing list

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 9 Jun 2016 17:57:39 -0700

> On Jun 9, 2016, at 7:58 AM, Acee Lindem (acee) <[email-masked]> wrote:
>> 

You are correct. I was thinking of interface as one of the parameters in the ACL rule, where this example is of configuring an ACL under an interface. 

> IPOS), I can confirm that attaching an ACL to an interface is, indeed, an

And this is more of a question to the authors - unless I am missing something, where and how is this achieved today?

Mahesh Jethanandani
[email-masked]

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 10 Jun 2016 01:59:01 +0000

It is shown in the draft as an example of how to augment the interface module.

Just to be clear -> the link you sent to the Cisco doc does not show the use of 'metadata' or an input-interface match criteria. 

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Thursday, June 09, 2016 20:58
To: Acee Lindem (acee)
Cc: netmod WG
Subject: Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

> In the same way I misread your salutation, I think you’ve 
> misinterpreted this example as it applies to including interface in 
> the ACL model. If you examine the referenced configuration html 
> closely, you’ll see that the ACL is a reusable packet-matching policy 
> that is applied to an interface rather than the interface being 
> included in the ACL rules themselves. In IOS-XR, the command to apply 
> the ACL to an interface is “{ipv4 | ipv6} access-group <acl-name>” 
> specified in interface configuration submode. Is there something in the text that I’m missing?

> As the initial implementor of the function on Redback SEOS (now 
> Ericsson IPOS), I can confirm that attaching an ACL to an interface 
> is, indeed, an essential function.

>>> But I think the matching on input-interface should be removed from 
>>> the model (or at the least put inside a feature flag).
>>> 
>>> But having that input-interface match on metadata in the core model 
>>> is out of place.  It should be left to further extension drafts or 
>>> vendor specific augmentations (along with whatever other metadata 
>>> might be useful or vendor-specific).
>>> 
>>> 
>>> 
>>> Actually matching on input-interface in the ACL rules themselves is 
>>> not basic core ACL functionality.  Nokia SR OS does not have that 
>>> Cisco and Juniper support matching on input interface. It is useful 
>>> when you want to filter on general traffic coming from interface.
>>> 
>>> Cisco
>>> match input-interface
>>> match input-vlan
>>> 
>>> 
>>> 
>>> 
>> 
>> These are “class-map”  sub-commands - not “access-list" sub-commands. 
>> So you are referring to the general functionality rather than 
>> specifically functionality supported by access-list?
>> 
>> 
>> 
>> 
>> 
>> – match input-interface interface-id-list – 
>> match ip dscp dscp-list – match ip precedence 
>> ip-precedence-list
>> 
>> 
>> 
>>> 
>>> 
>>> Junos
>>> family any {
>>> filter L2_filter {
>>> term t1 {
>>> from {
>>> interface fe-0/0/0.0;
>>> }
>>> then {
>>> policer p1;
>>> count c1;
>>> }
>>> }
>>> }
>>> }
>>> 

Mahesh Jethanandani
[email-masked]