Proposal for IP AFT streaming prefix filter
dplore opened this issue · 3 comments
Operationally it is often neceessary to only stream a sub-set of the afts model. Today one can subscribe to portions of the aft tree, partitioned by address family for example. But if one subscribes to as, the ipv4-unitcast subtree, all routes are streamed.
We have operational use cases to only stream a subset of the ipv4/ipv6 trees. To do this, we could create a prefix list and reference this in new OC path(s) as an "AFT Streaming Filter. For example:
/defined-sets/ipv4-prefix-sets/ipv4-prefix-set['myprefixes']/config/prefix = '1.1.1.0/24'
/defined-sets/ipv4-prefix-sets/ipv4-prefix-set['myprefixes']/config/prefix = '2.2.2.0/24'
/routing-policy/policy-definitions/policy-definition/statements/statement/conditions/match-prefix-set['myprefixes']/config/match-set-options = ANY
This is an idea for a new path:
/network-instances/network-instance/afts/ipv4-unicast/filter/config/name = leafref to /defined-sets/ipv4-prefix-sets/ipv4-prefix-set['myprefixes']
Thoughts on this?
First comment is just that filtering is increasingly becoming more and more of an issue if you consider the size of the schemas in combination with multi-dimensional scale. This is not unique to AFT but rather I would rather like to envision a uniform method to "suppress" and select schema nodes/values.
Either in the protocol layer (which in this case would be specific to g* services) or via schema r/w objects (much like what you have here but more generic not specific to any one domain or construct) - the latter could be leveraged for other interfaces/operations.
Thinking about this idea of a generic filter, perhaps one could have an 'EXCEPT' clause in a gNMI Subscribe which could list paths the caller doesn't want to receive. Subscribe allows positive filtering, except would allow negative filtering. This could be generic. Although it doesn't serve this use case very well. The issue for this use case is the positive / Subscribe filter is 10's of thousands of elements which does not scale well on a per-subscription basis. Large filters like this need to be saved as configuration. Off the top of my head, it seems any time one is configuring a filter as part of configuration is that it will be schema dependent.
First comment is just that filtering is increasingly becoming more and more of an issue if you consider the size of the schemas in combination with multi-dimensional scale. This is not unique to AFT but rather I would rather like to envision a uniform method to "suppress" and select schema nodes/values.
Either in the protocol layer (which in this case would be specific to g* services) or via schema r/w objects (much like what you have here but more generic not specific to any one domain or construct) - the latter could be leveraged for other interfaces/operations.
Do you have a suggestion for a schema to implement filtering which would be generic?