. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "1" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "oc-rpol" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "OpenConfig working group" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "openconfig-routing-policy" . . . . . . . . . . . "OpenConfig working group\nnetopenconfig@googlegroups.com" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "This module describes a YANG model for routing policy\nconfiguration. It is a limited subset of all of the policy\nconfiguration parameters available in the variety of vendor\nimplementations, but supports widely used constructs for managing\nhow routes are imported, exported, and modified across different\nrouting protocols. This module is intended to be used in\nconjunction with routing protocol configuration models (e.g.,\nBGP) defined in other modules.\n\nRoute policy expression:\n\nPolicies are expressed as a set of top-level policy definitions,\neach of which consists of a sequence of policy statements. Policy\nstatements consist of simple condition-action tuples. Conditions\nmay include mutiple match or comparison operations, and similarly\nactions may be multitude of changes to route attributes or a\nfinal disposition of accepting or rejecting the route.\n\nRoute policy evaluation:\n\nPolicy definitions are referenced in routing protocol\nconfigurations using import and export configuration statements.\nThe arguments are members of an ordered list of named policy\ndefinitions which comprise a policy chain, and optionally, an\nexplicit default policy action (i.e., reject or accept).\n\nEvaluation of each policy definition proceeds by evaluating its\ncorresponding individual policy statements in order. When a\ncondition statement in a policy statement is satisfied, the\ncorresponding action statement is executed. If the action\nstatement has either accept-route or reject-route actions, policy\nevaluation of the current policy definition stops, and no further\npolicy definitions in the chain are evaluated.\n\nIf the condition is not satisfied, then evaluation proceeds to\nthe next policy statement. If none of the policy statement\nconditions are satisfied, then evaluation of the current policy\ndefinition stops, and the next policy definition in the chain is\nevaluated. When the end of the policy chain is reached, the\ndefault route disposition action is performed (i.e., reject-route\nunless an an alternate default action is specified for the\nchain).\n\nPolicy 'subroutines' (or nested policies) are supported by\nallowing policy statement conditions to reference another policy\ndefinition which applies conditions and actions from the\nreferenced policy before returning to the calling policy\nstatement and resuming evaluation. If the called policy\nresults in an accept-route (either explicit or by default), then\nthe subroutine returns an effective true value to the calling\npolicy. Similarly, a reject-route action returns false. If the\nsubroutine returns true, the calling policy continues to evaluate\nthe remaining conditions (using a modified route if the\nsubroutine performed any changes to the route)." . . . . .