Two alternative ways to express source protocol condition in routing policy may requires vendor-awarness on controller side..

[rszarecki]

1. public/release/models/policy/openconfig-routing-policy.yang

   Line 776 in e84d592

   leaf install-protocol-eq {

   
   and

2. public/release/models/network-instance/openconfig-network-instance-policy.yang

   Line 81 in e84d592

   container match-protocol-instance {

   
   are essentially redundant. Hence one implementation can select to support only 1. while other only 2. As result controller that generate routing policy configuration would need to denerate 2 variants and distribute according to network device capability. This contradict OpenConfig fundamental goal.

The 2. provides higer level of granularity, hence IMHO 1. (install-protocol-eq) shaould be deprecated.

One can argue that 2. reqires explicit specification of protocol's process/agent/instance identifier. This concern can be addressed by defining default value of "DEFAULT" (similiarly to [network-instance/protocols/protocol]

public/release/models/network-instance/openconfig-network-instance.yang

Line 1296 in e84d592

default "DEFAULT";

).

In case when multiple process/agent/instance of given protocol (e.g. ISIS) are enabled in single network-instance (what is rare deployment use case) AND intent is to match on this protocol in policy w/o discrimination by process/aget/instance (what make case even more rare), the 2. would requires explicit list of all this instances - each in sepate statement.

---

Note: The "name" and "identifier" are used inconsistently between

public/release/models/network-instance/openconfig-network-instance-policy.yang

Line 49 in e84d592

grouping protocol-instance-policy-config {

and

public/release/models/network-instance/openconfig-network-instance.yang

Line 1281 in e84d592

grouping protocols-config {

[rszarecki]

EXAMPLE:

Let assume deployment where we have single network-instance "DEFAULT" running one BGP instance "BGP" and one ISIS instance "isis".

/network-instances/network-instance[name=default]/protocols/protocol[identifier=BGP][name=BGP]:
{
...
}
/network-instances/network-instance[name=default]/protocols/protocol[identifier=ISIS][name=isis]:
{
...
}

Let asume further that all isis routes are "best and active" and all isis routes need to be advertised to some of BGP peers (PeerGrp0) and not advertosed to other BGP peers (PeerGrp1). Hence redistribution of all isis routes to BGP Local-RIB is enabled via /network-instances/network-instance[name=default]/table-connections
Since all isis routes are in Local-RIB they must be filtered out in export route-policy on sessions where they should NOT be advertised. This requires export policy to express consitions checking if route source is isis protocols.

using metod [1] (install-protocol-eq)

/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/conditions/config/
install-protocol-eq: ISIS
/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/actions/config/
policy-result: REJECT_ROUTE

Or using metod [2] (match-protocol-instance)

/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-identifier: isis
routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-name: ISIS
/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/actions/config/
policy-result: REJECT_ROUTE

---

Now lets extend out example by considering that ADDITIONALY second ISIS instance is running in same network-instance - "isis2". And ther eis another subset of BGP peers (PeerGrp2) that should recive ISIS routes form instance "isis2" but not form insatnce "isis". This may not be satisfied using metod [1]. Hence here are possible implementations:

using mix of metod [1] (install-protocol-eq) and [2] (match-protocol-instance)

/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/conditions/config/
install-protocol-eq: ISIS
/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/actions/config/
policy-result: REJECT_ROUTE

/routing-policy/policy-definitions/policy-definition[name="PeerGrp2_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-identifier: isis
routing-policy/policy-definitions/policy-definition[name="PeerGrp2_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-name: ISIS
/routing-policy/policy-definitions/policy-definition[name="PeerGrp2_out"]/statements/statement[name="Reject_isis"]/actions/config/
policy-result: REJECT_ROUTE

Or using metod [2] (match-protocol-instance)

/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-identifier: isis
routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-name: ISIS
/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis"]/actions/config/
policy-result: REJECT_ROUTE
definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis2"]/conditions/match-protocol-instance/config/
protocol-identifier: isis2
routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis2"]/conditions/match-protocol-instance/config/
protocol-name: ISIS
/routing-policy/policy-definitions/policy-definition[name="PeerGrp1_out"]/statements/statement[name="Reject_isis2"]/actions/config/
policy-result: REJECT_ROUTE

/routing-policy/policy-definitions/policy-definition[name="PeerGrp2_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-identifier: isis
routing-policy/policy-definitions/policy-definition[name="PeerGrp2_out"]/statements/statement[name="Reject_isis"]/conditions/match-protocol-instance/config/
protocol-name: ISIS
/routing-policy/policy-definitions/policy-definition[name="PeerGrp2_out"]/statements/statement[name="Reject_isis"]/actions/config/
policy-result: REJECT_ROUTE

---

If we asume all implementations always suppot both - [1] (install-protocol-eq) and [2] (match-protocol-instance) - then it is up to controller to decide. But this assumption is risky, and some implementations may skip one of methods - e.g. because given implementation do not support multiple instances of same protocol (so skip [2]) or because it does (so skip[1] as redundant).
Therefore deprecating [1] enforces unification.

[dplore]

Added to community meeting agenda on April 4, 2024

[dplore]

Jeff Haas has comments from OC community meeting that we need to consider the case where one wants to match on the source routing table. I think to try to make this clear, we need some example policy which one thinks install-protocol-eq is required and evaluate if that could be implemented with only the match-protocol-instance option.

[rszarecki]

I have looked into this some time ago. Any logic expressed with ‘install-protocol-eq’ could be expressed with ‘match-protocol-instance’ However opposite is not true. ‘Match-protocol-instance’ is functional superset.

…

-------------- Rafal Szarecki

On Thu, Apr 4, 2024 at 05:26 Darren Loher ***@***.***> wrote: Jeff Haas has comments from OC community meeting that we need to consider the case where one wants to match on the source routing table. I think to try to make this clear, we need some example policy which one thinks install-protocol-eq is required and evaluate if that could be implemented with only the match-protocol-instance option. — Reply to this email directly, view it on GitHub <#931 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALDSOVKARBTPZC7EOB3DFGTY3VWJ3AVCNFSM6AAAAAA22Q2BWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZXGUYTONRTG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>