From e60dadbb2a48ac768e148989ac120921f496f9fb Mon Sep 17 00:00:00 2001 From: sachendras <44847441+sachendras@users.noreply.github.com> Date: Fri, 3 Nov 2023 11:11:13 -0700 Subject: [PATCH 1/4] Update network_instance_redistribution.md --- doc/network_instance_redistribution.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/network_instance_redistribution.md b/doc/network_instance_redistribution.md index e531a66b4..4df6717f2 100644 --- a/doc/network_instance_redistribution.md +++ b/doc/network_instance_redistribution.md @@ -22,7 +22,8 @@ In numerous use cases an operator wishes to take routes that exist in one protoc In those implementations that maintain a (virtual-) RIB per protocol, the operator must configure explicit connections between these tables, usually alongside a policy to allow such inter-protocol advertisement to occur. While no such configuration is required in those implementations that utilise a single RIB, it is notable that even in these implementations a protocol will not advertise another protocol's routes from the RIB by default (since such a setup would mean that for instance, the BGP DFZ would be re-advertised into the IGP at peering edge devices, which is clearly not desirable). Instead, an operator must create explicit configuration that matches routes installed into the RIB by a particular protocol, and then "import" these routes into the protocol that is expected to advertise them. -In this latter case, the use of an import policy within a particular protocol instance is equivalent to the former - with the only difference being the context in which the policy is defined. With a table per protocol, an explicit configuration of redistributing routes from protocol A to protocol B is specified. In the latter case, the target protocol (protocol B) is specified, and a policy is used to select the source protocols from which routes may be imported for advertisement. +In this latter case, the use of an import policy within a particular protocol instance is equivalent to the former - with the only difference being the context in which the policy is defined. With a table per protocol, an explicit configuration of redistributing routes from protocol A to protocol B is specified. In the latter case, the target protocol (protocol B) is specified, and a policy is used to select the source protocols from which routes may be imported for advertisement. +In both cases, it is important that the destination protocol (protocol B) in this case only place the redistributed routes from the source protocol (protocol A in this case) in its "advertisement RIB view", but do not use those routes in the active/installed/forwarding route selection process and,consequently, do not place them in the FIB (forwarding information base). ## OpenConfig Approach to Protocol RIB Interconnection @@ -35,6 +36,8 @@ An OpenConfig `routing-policy` is specified along with the connection - allowing It is expected that protocol-specific attributes (e.g., BGP communities) are set by such an import policy, allowing routes that are redistributed to carry information relating to their source (e.g., an IGP route may be tagged with a specific community using policy to indicate its provenance). +In the absense of an import-policy for table-connections, default-import-policy should take effect. In the absence of both, no routes should be allowed to be redistributed. + ## Examples of OpenConfig Network instance ### Example: Aggregate Routes Redistributed to IS-IS Level 2 From 4e39d746f394806eb665b70ede7acd754d16eab9 Mon Sep 17 00:00:00 2001 From: sachendras <44847441+sachendras@users.noreply.github.com> Date: Fri, 3 Nov 2023 11:16:01 -0700 Subject: [PATCH 2/4] Update openconfig-network-instance.yang --- .../openconfig-network-instance.yang | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/release/models/network-instance/openconfig-network-instance.yang b/release/models/network-instance/openconfig-network-instance.yang index d680f4a9a..ee5b5a740 100644 --- a/release/models/network-instance/openconfig-network-instance.yang +++ b/release/models/network-instance/openconfig-network-instance.yang @@ -48,7 +48,13 @@ module openconfig-network-instance { virtual switch instance (VSI). Mixed Layer 2 and Layer 3 instances are also supported."; - oc-ext:openconfig-version "4.2.1"; + oc-ext:openconfig-version "4.2.2"; + + revision "2023-11-03" { + description + "Add reference URL for Route Redistribution rules"; + reference "4.2.2"; + } revision "2023-11-01" { description @@ -487,6 +493,10 @@ module openconfig-network-instance { for the connection are available for the destination protocol to advertise, or match within its policies."; + reference + "Route Redistribution in OpenConfig Network Instance: + https://github.com/openconfig/public/blob/master/doc/network_instance_redistribution.md#interconnection-of-protocol-ribs"; + leaf src-protocol { type leafref { path "../config/src-protocol"; From 8d1040d5b54de7ab53d86445d8ec9a0ad9668995 Mon Sep 17 00:00:00 2001 From: sachendras <44847441+sachendras@users.noreply.github.com> Date: Fri, 3 Nov 2023 11:23:14 -0700 Subject: [PATCH 3/4] Update openconfig-network-instance-l2.yang --- .../network-instance/openconfig-network-instance-l2.yang | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/release/models/network-instance/openconfig-network-instance-l2.yang b/release/models/network-instance/openconfig-network-instance-l2.yang index 2f93312ca..16a41451d 100644 --- a/release/models/network-instance/openconfig-network-instance-l2.yang +++ b/release/models/network-instance/openconfig-network-instance-l2.yang @@ -24,7 +24,13 @@ submodule openconfig-network-instance-l2 { Layer 2 network instance configuration and operational state parameters."; - oc-ext:openconfig-version "4.2.1"; + oc-ext:openconfig-version "4.2.2"; + + revision "2023-11-03" { + description + "Add reference URL for Route Redistribution rules"; + reference "4.2.2"; + } revision "2023-11-01" { description From 7374d1fa4a84a42e2b82b62874ed22e05afbdc09 Mon Sep 17 00:00:00 2001 From: sachendras <44847441+sachendras@users.noreply.github.com> Date: Fri, 3 Nov 2023 12:01:08 -0700 Subject: [PATCH 4/4] Update doc/network_instance_redistribution.md Co-authored-by: Darren Loher --- doc/network_instance_redistribution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/network_instance_redistribution.md b/doc/network_instance_redistribution.md index 4df6717f2..d35b67fdd 100644 --- a/doc/network_instance_redistribution.md +++ b/doc/network_instance_redistribution.md @@ -23,7 +23,7 @@ In numerous use cases an operator wishes to take routes that exist in one protoc In those implementations that maintain a (virtual-) RIB per protocol, the operator must configure explicit connections between these tables, usually alongside a policy to allow such inter-protocol advertisement to occur. While no such configuration is required in those implementations that utilise a single RIB, it is notable that even in these implementations a protocol will not advertise another protocol's routes from the RIB by default (since such a setup would mean that for instance, the BGP DFZ would be re-advertised into the IGP at peering edge devices, which is clearly not desirable). Instead, an operator must create explicit configuration that matches routes installed into the RIB by a particular protocol, and then "import" these routes into the protocol that is expected to advertise them. In this latter case, the use of an import policy within a particular protocol instance is equivalent to the former - with the only difference being the context in which the policy is defined. With a table per protocol, an explicit configuration of redistributing routes from protocol A to protocol B is specified. In the latter case, the target protocol (protocol B) is specified, and a policy is used to select the source protocols from which routes may be imported for advertisement. -In both cases, it is important that the destination protocol (protocol B) in this case only place the redistributed routes from the source protocol (protocol A in this case) in its "advertisement RIB view", but do not use those routes in the active/installed/forwarding route selection process and,consequently, do not place them in the FIB (forwarding information base). +In both cases, the destination protocol (protocol B) only installs the redistributed routes from the source protocol (protocol A) in its "advertisement RIB view". The redistributed routes are not installed in the FIB (forwarding information base) and therefore are not used for forwarding. ## OpenConfig Approach to Protocol RIB Interconnection