Hi all,

Another topic that I still think warrants more discussion is the use of 
explicit entry numbers for ACEs instead of arbitrary string names.   Names are 
great for objects like ACLs, interfaces, etc but we should really consider 
using explicit order based on a numerical key for ACEs.

ACEs can have a text 'description' leaf to explain their purpose (instead of 
trying to overload that into a limited name).

Some may feel that numbered IDs are "archaic".  I agree for lists where entries 
don't really have any order relative to each other but just because numerical 
ACEs have been around for a long time doesn't mean they are a bad idea. 

Why a numerical ID ?
- as per the brief exchange between Andy & I below:  explicit numerical entry # 
will play nicer with SNMP and other non-NETCONF/YANG methods to access the data
- numbered ACEs are just easier for people to read & manipulate.  You can 
easily refer to an ACE and someone else can find it in the list quickly.  
- there are many implementations out there that use numerical ACE IDs and 
operators are used to managing them that way
- It is easier to create blocks of IDs for different sections of the ACL and to 
understand where those blocks live in the ACL relative to eachother (e.g. 
entries inserted by FlowSpec go here, entries inserted by RADIUS go here).
- High speed data paths use TCAMs for ACLs and in the end those use numerical 
IDs for ordering/precedence.  Reflecting that up towards the device config 
layer allows optimizations to avoid/reduce reordering in the device.

Regards,
Jason

On Tue, Mar 24, 2015 at 4:50 PM, Sterne, Jason (Jason) 
<[email protected]> wrote:
> Hi guys,
>
...snip...
>
> Maybe it isn’t a priority for some systems but I also wonder how SNMP would 
> represent ordered acl-entries if there isn't a sequence number that can be 
> used as (at least part of) the key.
>

User-ordered lists are YANG-specific.
I advice against using them if you want multiple protocols like SNMP and CLI to 
work with the data.


> Regards,
> Jason
>


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

Reply via email to