Jason,
> On Apr 29, 2016, at 3:33 PM, Sterne, Jason (Nokia - CA) > <jason.ste...@nokia.com> wrote: > > 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 believe that we have to add text that metadata can be match conditions in an ACL. In this case, I would add an example at the end of the document to show how it can be done through augmentation. > > 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" leaf refs). I think that would be a good example to show how to augment model. Dean > > Jason > > -----Original Message----- > From: EXT Ladislav Lhotka [mailto:lho...@nic.cz] > Sent: Friday, April 22, 2016 9:49 > To: Dean Bogdanovic; Sterne, Jason (Nokia - CA) > Cc: netmod WG > Subject: Re: [netmod] input Interface match > > Dean Bogdanovic <ivand...@gmail.com> writes: > >> Any other opinions on this issue? There were quite a few hands in the >> 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 > >> >> Dean >> >>> On Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) >>> <jason.ste...@nokia.com> wrote: >>> >>> 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:ivand...@gmail.com] >>> Sent: Friday, April 08, 2016 9:25 >>> To: Sterne, Jason (Nokia - CA) >>> Cc: netmod WG >>> Subject: Re: [netmod] input Interface match >>> >>> 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) >>> <jason.ste...@nokia.com <mailto:jason.ste...@nokia.com>> wrote: >>> >>> 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:netmod-boun...@ietf.org >>> <mailto:netmod-boun...@ietf.org>] On Behalf Of EXT Dean Bogdanovic >>> Sent: Thursday, April 07, 2016 11:12 >>> To: netmod WG >>> Subject: [netmod] input Interface match >>> >>> 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 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
