Subject: Re: [netmod] Discussion on draft-huang-netmod-acl-03

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 17 Jun 2014 22:21:37 +0000

Yuekun,

Thank you for the comments. Responded in line. Thanks,

Lisa

From: YuekunLi <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] Discussion on draft-huang-netmod-acl-03

Hi Lisa/Alex/Andy,

I went through 'draft-huang-netmod-acl-03' and had a few points that I would like to discuss with you guys.

1. I have some concern on the name of the feature we're modeling here.
   'Stateless Packet Filter' is accurate to describe this feature.
   However, none of the major vendors in the industry named their features as such.
   Aligning with some major vendors would be appropriate since we're setting a standard.
   From this perspective, I would suggest using 'Access Control List (ACL)'.

<Lisa> It was one of the WG discussion conclusion to use 'Stateless Packet Filter'. The reason was the people thought that Access Control was too restrictive in application domain, and really what was specified are stateless packet filters of which access control is only one possible application. Personally, I think ACL is a better name and the first version of draft was using ACL instead of 'Stateless Packet Filter'.

2. The latest revision of this doc briefly mentioned how a SPF (ACL) is applied to a target.
   I can see that section 3.3.4 covers the topic of attaching a SPF (ACL) to an interface.
   In this case, SPF (ACL) is used for traffic filtering.
   There are quite some scenarios, however, SPFs (ACLs) are deployed in other client applications such as QoS policy and routing protocols (e.g. BGP and OSPF).
   In most of these cases, SPF (ACL) is used for classification or filtering some routing information.
   Would you consider to initiate a new draft dedicated to topics of applying SPF (ACL) to each type of targets?

<Lisa> ACL is a complex and widely used component. This draft could not cover all ACL implementations, but the design of the module is easy to extend. If there is a need for a new module, it can be created easily by following the same design pattern as SPF-IP or SPF-MAC. The new model can augment, restrict or uses grouping on the existing modules.

3. This document has had a detailed coverage on object-groups (both port object-groups and network object-groups).
   Could we consider to put object-groups in a separate module?
   The benefit of this practice is that it's easy for object-groups to be re-used by other modules besides SPF (ACL).
<Lisa> I will move the object-groups out in a different module in the new version of the draft.

4. The packet-capture feature may not be appropriate in SPF (ACL) module.
   This feature actually introduces some new 'actions' to execute after we found a match between packet and SPE (ACE).
   These actions (forward and copy) are not purely filtering actions.
   Therefore, they may not fit in the SPF (ACL) module very well.

<Lisa>There is no packet-capture in the ACL module, instead it is just a packet-capture enabler configuration leaf. Is the name itself made you bring the comment? If so, I can rename the packet-capture feature to avoid confusion.

5. In current SPF (ACL) module, each SPE (ACE) is assigned a string as its name.
   This may be too expensive in terms of memory consumption.
   Instead, a sequence number for each entry should be sufficient and easy to implement.
   Besides, sequence number does give uses the flexibilty to insert an entry to certain position of an existing SPF (ACL).

<Lisa>This is a topic that has been discussed before.  Since not all system are using sequence number, as a standard, it is trying to be generic to cover more cases. If the system only support integer as the key and memory is a concern, the key can be cast before storing.
The ACE list is an order-by-user list. This could let the user control the ACE sequence. The existing system uses sequence number to implement order by user feature. Netconf <edit-config> operation has "insert" attribute which can take the values "first", "last", "before" and "after" to indicate exactly where the ACE will go to.

6. Is it better to have a higher level abstraction above SPF (ACL) module?
   By this, I mean creating a separate module that defines some common typedef/groupings.
   And not container in this module.
   Is this going to be an improvement for the modularity?

<Lisa>In the new draft, I have moved typedef and grouping related object-groups to a new module. Hope this will help the readability.

Please let me know if there is any confusion on above points.

Thanks

---------------
Yuekun Li