Hi, Oscar:
I have read the latest version of draft-dbb-netmod-acl, the problem statement 
and gap analysis are interesting, here are a few comments on this draft:
1.For problem statement in section 4.3 and section 4.5, I am wondering how  do 
you feel encrypted traffic at the transport layer, e.g., TLS layer or QUIC 
layer,
I feel it is hard, you might read one of presentation slides for IAB MTEN 
workshop, one gap we identify is ACL fall short to deal with encrypted traffic.
But for unencrypted traffic, yes, the ACL extension provide fine granularity 
access control.

2.For section 3.2, I feel the solution seems not complete, how defined set is 
used, in the match, it lack a example to explain how it is used.

3.For section 3.1, it is a good extension, but I understand the idea is to 
apply the same action to a set of prefixes, let's say two prefixes, since the 
destination-ipv6-network is defined as an array, I am wondering whether the 
action should be changes into 2 actions in an array:
   {
     "ietf-access-control-list:acls": {
       "acl": [
         {
           "name": "prefix-list-support",
           "type": "ipv6-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "my-test-ace",
                 "matches": {
                   "ipv6": {
                     "destination-ipv6-network": [
                       "2001:db8:6401:1::/64",
                       "2001:db8:6401:c::/64"
                     ],
                     "source-ipv6-network":
                       "2001:db8:1234::/96",
                     "protocol": 17,
                     "flow-label": 10000
                   },
                 },
                 "actions": {
                   "forwarding": [ "accept","accept"]
                 }
               }
             ]
           }
         }
       ]
     }
   }
Maybe one alternative solution is to use template, if we want to Manipulate 
Lists of Prefixes

4.I feel flags defined in RFC9519 is confusing, how does the controller know 
which packet is the last fragment, which packet is not, which packet needs to 
be fragmented, which one not,the fragment action is controlled by the ingress 
node, configuring flags seems wrong to me.

5. For section 3.3 "Bind ACLs to Devices, Not Only Interfaces", do we have 
solution to this problem? If not, I think draft-ma-opsawg-ucl-acl-00 provide 
excatly the solution you are looking for if my understanding is correct, to 
address the limitation of IP address based access control, no need to tie to 
the specific interface of the device, or a single device.

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

Reply via email to