Import Policy in OSPF Configuration

[sbarguil]

I would be usefull to include the apply-policy container into the /network-instances/network-instance/protocols/protocol/ospfv2/global configuration. This will allow to import routes learnt from other protocols into OSPF whitout using the table connections, providing more control, flexibiity in the protocols configuration.

The functionality will be equivalent to some well know config attributes like:

• Huawei: ospf [ process-id ] import-route { limit limit-number | { bgp [ permit-ibgp ] | direct | unr | rip [ process-id-rip ] | static | isis [ process-id-isis ] | ospf [ process-id-ospf ] } [ cost cost | type type | tag tag | route-policy route-policy-name ] * }

• Nokia: ospf import policy-name [policy-name]: The import route policy name, up to a maximum of 5. Allowed values are any string up to 32 characters long composed of printable, 7-bit ASCII characters. If the string contains special characters (#, $, spaces, etc.), the entire string must be enclosed within double quotes. The specified names must already be defined.

This feature is already supported in Openconfig for the BGP protocol under the peer and Neighboor configuration:

module: openconfig-network-instance
  +--rw network-instances
     +--rw network-instance* [name]
        +--rw name                       -> ../config/name
        +--rw protocols
           +--rw protocol* [identifier name]
              +--rw identifier          -> ../config/identifier
              +--rw name                -> ../config/name
              +--rw config
              +--rw bgp
              |  +--rw global
              |  +--rw neighbors
              |  |  +--rw neighbor* [neighbor-address]
              |  |     +--rw apply-policy
              |  |     |  +--rw config
              |  |     |  |  +--rw import-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |  |  +--rw default-import-policy?   default-policy-type
              |  |     |  |  +--rw export-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |  |  +--rw default-export-policy?   default-policy-type
              |  |     |  +--ro state
              |  |     |     +--ro import-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |     +--ro default-import-policy?   default-policy-type
              |  |     |     +--ro export-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |     +--ro default-export-policy?   default-policy-type
              |  +--rw peer-groups
              |  |  +--rw peer-group* [peer-group-name]
              |  |     +--rw peer-group-name       -> ../config/peer-group-name
              |  |     +--rw apply-policy
              |  |     |  +--rw config
              |  |     |  |  +--rw import-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |  |  +--rw default-import-policy?   default-policy-type
              |  |     |  |  +--rw export-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |  |  +--rw default-export-policy?   default-policy-type
              |  |     |  +--ro state
              |  |     |     +--ro import-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |     +--ro default-import-policy?   default-policy-type
              |  |     |     +--ro export-policy*           -> /oc-rpol:routing-policy/policy-definitions/policy-definition/name
              |  |     |     +--ro default-export-policy?   default-policy-type

[sbarguil]

Complementing the details with the Juniper reference Ospf Policy Configuration

Understanding OSPF Routing Policy

Each routing policy is identified by a policy name. The name can contain letters, numbers, and hyphens (-) and can be up to 255 characters long. To include spaces in the name, enclose the entire name in double quotation marks. Each routing policy name must be unique within a configuration. Once a policy is created and named, it must be applied before it is active.

In the import statement, you list the name of the routing policy used to filter OSPF external routes from being installed into the routing tables of OSPF neighbors. You can filter the routes, but not link-state address (LSA) flooding. An external route is a route that is outside the OSPF Autonomous System (AS). The import policy does not impact the OSPF database. This means that the import policy has no impact on the link-state advertisements.

In the export statement, you list the name of the routing policy to be evaluated when routes are being exported from the routing table into OSPF.

---

The sample scenario exposed in previous session was the following:

1. It can be defined a BGP policy using the installed-protocol as static:

     <routing-policy xmlns="http://openconfig.net/yang/routing-policy">
       <policy-definitions>
         <policy-definition>
           <name>test</name>
           <config>
             <name>test</name>
           </config>
           <statements>
             <statement>
               <name>1</name>
               <config>
                 <name>1</name>
               </config>
               <conditions>
                 <config>
                   <install-protocol-eq xmlns:oc-pol-types="http://openconfig.net/yang/policy-types">oc-pol-types:STATIC</install-protocol-eq>
                 </config>
               </conditions>
               <actions>
                 <config>
                   <policy-result>ACCEPT_ROUTE</policy-result>
                 </config>
               </actions>
             </statement>
           </statements>
         </policy-definition>
       </policy-definitions>
     </routing-policy>

2. Apply this BGP policy in a bgp-neigboor session.

This will redistribute the static routes into the BGP protocol without using the table connections.

[robshakir]

I think we have a disconnect here in the understanding of what import-policy is doing within the BGP model. Here, this is the policy that is applied for routes that are received from a particular BGP neighbour -- i.e., the policy which determines which routes in the Adj-RIB-In-Pre make it into the Adj-RIB-In-Post.

Here, I believe you're proposing to use the import-policy to mean "routes that should be made accessible to the OSPF process". This is a different case, and is what table-connections are designed to do.

Let's discuss why we needed table connections: we have two 'designs' of routing table management -- one where there is a single routing table that is populated by all protocols, and you can reference routes from another protocol, the other is one whereby there are explicit connections needed to be made between protocols to allow redistribution. To abstract this, we have to choose some representation in OpenConfig that determines whether routes are automagically available from one protocol to another, vs. being implicitly available. There isn't really a middle ground.

If we create the kind of logic that you're proposing here, it will have different behaviours on different systems -- a system that does not have the implicit connection will have zero routes available to it within BGP to match on static, whereas one that does will have the static routes to match on. This breaks our vendor-neutrality.

Thus, I don't think we should accept changes like this -- we should require table-connections. Yes, this requires some thought as to how to map to the case that we have the implicit connections (essentially a policy that is implicitly there saying from protocol <not-this-protocol> then deny in the chain), but it keeps consistency of representation and expected behaviours in the models.

[robshakir]

One further thought: in this case, having two vendor implementations isn't really applicable -- since it violates the approach of having a vendor neutral set of behaviours for something quite fundamental. In this case, we're more interested in having one representation that can be mapped to multiple implementations (see, for instance, the requirement for a subinterface on an interface -- we did not say "oh, there are multiple implementations that allow an IP directly on the interface" and therefore support both, since this would have different behaviours on different systems).

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.