Subject: [netmod] input Interface match

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 7 Apr 2016 11:11:31 -0300

As the action item from the netmod WG and, hopefully, last open item in the ACL draft is the leaf input interface in the metadata grouping 

grouping metadata {
    description
      "Fields associated with a packet which are not in
      the header.";
    leaf input-interface {
      type if:interface-ref {
        require-instance false;
      }
      description
        "Packet was received on this interface.";
    }
  }
}

Here are two questions:
One
Do want to have a metadata grouping in the basic ACL model? If yes, we have to put in some leafs in there. There are implementations which use metadata as match condition

If we agree that metadata grouping is not needed in the basic model, then the authors would remove the grouping from the model and I believe that no more discussion is needed on this point

Dean

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 8 Apr 2016 12:20:40 +0000

Hi Dean,

Just to clarify -> the main question posed in the WG meeting was about the input-interface match criteria.  From the meeting minutes:

Chairs: call for if interface should be in base:
    6 prefer NOT having it in the doc at all
    5 prefer having it in, but as a feature
    2 prefer having it in the doc as required

Maybe we should get agreement on what to do about input-interface (on the list) first and then we can figure out what to do about the metadata grouping.

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). Many major implementations do not support matching on input-interface (Cisco IOS-XR, Nokia SR OS, Brocade, others).  The typical way to associate ACLs and Interfaces is by assigning an ACL to an interface as shown in section A.3. of the ACL draft.   There is some discussion of this on the NETMOD thread "Remove input-interface (metadata) from netmod-acl-model-07 ?".

Regards,
Jason

From: netmod [mailto:[email-masked]] On Behalf Of EXT Dean Bogdanovic
Sent: Thursday, April 07, 2016 11:12
To: netmod WG
Subject: [netmod] input Interface match

grouping metadata {

    description

      the header.";

    leaf input-interface {

      type if:interface-ref {

        require-instance false;

      }

      description

    }

  }

}

Here are two questions:
One

Dean

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 8 Apr 2016 09:25:17 -0300

Jason,

After looking at the document and the model, it is also about having metadata grouping in the model. If you want to have metadata grouping in the model, then you have to have something inside and then input-interface questions comes up. If you don’t have to have metadata grouping in the base model, everything is easy.

I believe this is the right question

Dean

> On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) <[email-masked]> wrote:
> 
> Hi Dean,
>  
> 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). Many major implementations do not support matching on input-interface (Cisco IOS-XR, Nokia SR OS, Brocade, others).  The typical way to associate ACLs and Interfaces is by assigning an ACL to an interface as shown in section A.3. of the ACL draft.   There is some discussion of this on the NETMOD thread “Remove input-interface (metadata) from netmod-acl-model-07 ?”.
>  
> Regards,
> Jason
>

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 8 Apr 2016 12:25:57 +0000

Hi Dean,

We should remove the metadata grouping from the base model.  It is out of place with the rest of the model and a fairly clean line to draw as a boundary for future extension/augmentation.

Regards,
Jason

From: EXT Dean Bogdanovic [mailto:[email-masked]]
Sent: Friday, April 08, 2016 9:25
To: Sterne, Jason (Nokia - CA)
Cc: netmod WG
Subject: Re: [netmod] input Interface match

Jason,

Dean

On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Dean,

Regards,
Jason

grouping metadata {

    description

      the header.";

    leaf input-interface {

      type if:interface-ref {

        require-instance false;

      }

      description

    }

  }

}

Here are two questions:
One

Dean

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 21 Apr 2016 08:41:28 -0400

Any other opinions on this issue? There were quite a few hands in the air during the WG meeting

Dean

> On Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) <[email-masked]> wrote:
> 
> Hi Dean,
>  
> On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Dean,
>  
> From: netmod [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of EXT Dean Bogdanovic

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 22 Apr 2016 15:49:01 +0200

> air during the WG meeting

Unlike packet header fields, metadata are very much
implementation-specific, and may also depend on the context -
e.g. whether packet filtering is ingress or egress.

The draft cites nftables but in fact nftables includes several metadata
items, not only input-interface:

http://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation

I would suggest to think about other aspects of ACL type, such as
"ingress-acl" versus "egress-acl", and either define additional leafs for these
aspects or utilize multiple inheritance of identities that is possible
in YANG 1.1.

Then, I would extend the "metadata" grouping with other reasonably
common metadata items (for example, output-interface or packet-length),
and make each item conditional via "when" and/or "if-feature".

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 29 Apr 2016 19:33:44 +0000

Hi guys,

I agree that we may want to consider other metadata items and also agree they will tend to be more implementation-specific.  But rather than hold up this base ACL model for metadata why don't we treat metadata in either a follow up extension draft or leave them to vendor-specific augmentations (if there isn't enough commonality).

I don't think this model should have ingress vs egress as an attribute of an ACL. An ACL is directionless on its own and direction can be part of how it is applied to an object (e.g. maybe an augmentation to the interfaces module to add "ingress-acl" and "egress-acl" leafrefs).

Jason

-----Original Message-----
From: EXT Ladislav Lhotka [mailto:[email-masked]] 
Sent: Friday, April 22, 2016 9:49
To: Dean Bogdanovic; Sterne, Jason (Nokia - CA)
Cc: netmod WG
Subject: Re: [netmod] input Interface match

> air during the WG meeting

Unlike packet header fields, metadata are very much implementation-specific, and may also depend on the context - e.g. whether packet filtering is ingress or egress.

The draft cites nftables but in fact nftables includes several metadata items, not only input-interface:

I would suggest to think about other aspects of ACL type, such as "ingress-acl" versus "egress-acl", and either define additional leafs for these aspects or utilize multiple inheritance of identities that is possible in YANG 1.1.

Then, I would extend the "metadata" grouping with other reasonably common metadata items (for example, output-interface or packet-length), and make each item conditional via "when" and/or "if-feature".

Lada

>> From: netmod [mailto:[email-masked] 
>> <mailto:[email-masked]>] On Behalf Of EXT Dean Bogdanovic
>> As the action item from the netmod WG and, hopefully, last open item 
>> in the ACL draft is the leaf input interface in the metadata grouping
>>  
>> grouping metadata {
>>     description
>> Do want to have a metadata grouping in the basic ACL model? If yes, 
>> we have to put in some leafs in there. There are implementations 
>> which use metadata as match condition
>>  
>> If we agree that metadata grouping is not needed in the basic model, 
>> then the authors would remove the grouping from the model and I 
>> believe that no more discussion is needed on this point
>>  
>> Dean
>