Network Working Group A. Shaikh Internet-Draft Google Intended status: Informational K. D'Souza Expires: April 29, 2015 AT&T D. Bansal Microsoft R. Shakir BT October 26, 2014 BGP Configuration Model for Service Provider Networks draft-shaikh-idr-bgp-model-00 Abstract This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects based on carrier and content provider operational requirements. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Shaikh, et al. Expires April 29, 2015 [Page 1] Internet-Draft BGP Configuration Model October 2014 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction This document describes a YANG [RFC6020] data model for BGP [RFC4271] protocol and policy configuration, as well as defining key operational state data. The model is intended to be vendor-neutral, in order to allow operators to manage BGP configuration in heterogeneous environments with routers supplied by multiple vendors. The model is also intended to be readily mapped to existing implementations, however, to facilitate support from as large a set of routing hardware and software vendors as possible. 1.1. Goals and approach This model does not (in the current iteration) aim to be feature complete (i.e., cover all possible features of a BGP implementation). Rather its development is driven by examination of BGP configurations in use across a number of operator network deployments. The focus area of the first version of the model is on base BGP protocol configuration and policy configuration with "hooks" to add support for additional address families, as well as operational data to enable a common model for reading BGP-related state from devices. Configuration items that are deemed to be widely available in existing major BGP implementations are included in the model. Those configuration items that are only available from a single implementation are omitted from the model with the expectation they will be available in companion modules that augment the current model. This allows clarity in identifying data that is part of the vendor-neutral model. Where possible, naming in the model follows conventions used in available standards documents, and otherwise tries to be self- explanatory with sufficient descriptions of the intended behavior. Similarly, configuration data value constraints and default values, where used, are based on recommendations in current standards documentation. Since implementations vary widely in this respect, this version of the model specifies only a limited set of defaults and ranges with the expectation of being more prescriptive in future versions based on actual operator use. Shaikh, et al. Expires April 29, 2015 [Page 2] Internet-Draft BGP Configuration Model October 2014 2. Model overview The BGP model is defined across several YANG modules but at a high level is organized into three main parts: o protocol configuration -- configuration affecting BGP protocol- related operations, defined at various levels of hierarchy. o policy configuration -- configuration defining the policies that act on routes sent (received) to (from) peers or other routing protocols. o operational state -- variables used for monitoring, management, etc. of BGP operations. These modules also make use of the standard Internet types, such as IP addresses, autonomous system numbers, etc., defined in RFC 6991 [RFC6991]. 2.1. BGP protocol configuration The BGP protocol configuration model is organized hierarchically, much like the majority of router implementations. That is, configuration items can be specified at multiple levels, as shown below. +--rw bgp +--rw global +--rw afi* [afi-name] +--rw peer-group* [group-name] +--rw neighbor* [neighbor-address] +--rw policy Users may specify configuration at a higher level and have it apply to all lower-level items, or provide overriding configuration at a lower level of the hierarchy. Overriding configuration items are optional. The model makes the simplifying assumption that most of the configuration items are available at all levels of the hierarchy. That is, very little configuration is specific to a particular level in the hierarchy, other than obvious items such as "group- name" only being available for the peer group-level config. A notable exception is for sub-address family configuration where some items are only applicable for a given AFI-SAFI combination. The initial version of the model includes placeholders (i.e., mount points) for configuring different address family or sub address Shaikh, et al. Expires April 29, 2015 [Page 3] Internet-Draft BGP Configuration Model October 2014 family (AFI/SAFI) combinations in support of BGP multiprotocol extensions [RFC4760]. The focus, however, is on base IPv4 and IPv6 configuration, with later versions of the model providing additional configuration for specific AFI/SAFI types. The current scope of AFI/ SAFI combinations is indicated below. Each of the subtrees are containers for configuration specific to the corresponding AFI-SAFI combination. +--rw bgp +--rw afi* [afi-name] +--rw safi* [safi-name] +--rw safi-name identityref +--rw ipv4-ipv6-unicast +--rw ipv4-l3vpn-unicast +--rw ipv6-l3vpn-unicast +--rw ipv4-labeled-unicast +--rw l2vpn +--rw ipv4-multicast-vpn +--rw ipv6-multicast-vpn +--rw prefix-limit +--rw apply-policy 2.2. Policy configuration overview The BGP policy configuration model is based on a condition-action model in which policies are expressed as a series of conditions, each with a corresponding action. Conditions include testing for membership in a predefined set (e.g., community attribute matches a predefined set of communities), or testing route attributes for specified values. Actions support setting specific attributes on a route or performing a control flow operation such as accepting or rejecting a route, or going to the next policy. The general structure of policy definitions, policy statements, and condition-action policy rules is shown below. +--rw bgp +--rw policy +--rw policy-definitions! +--rw policy-definition* [name] +--rw name string +--rw statements* [name] +--rw name string +--rw conditions +--rw actions The policy model supports policy subroutines through the use of the condition statement call-policy which applies the conditions from Shaikh, et al. Expires April 29, 2015 [Page 4] Internet-Draft BGP Configuration Model October 2014 another named policy definition. It also supports policy chaining using the action statements goto-next and goto-policy, which allow policy evaluation to immediately move to the next policy statement in the current policy definition, or move to another named policy definition, respectively. Using multiple policy statements in a policy definition is also a form of policy chaining which will evaluate each policy statement in turn. 2.3. Operational data overview The BGP operational data model contains an initial set of state variable definitions that would be required in most service provider deployments for management, monitoring, and fault detection. 3. Security Considerations BGP configuration has a significant impact on network operations, and as such any related protocol or model carries potential security risks. YANG data models are generally designed to be used with the NETCONF protocol over an SSH transport. This provides an authenticated and secure channel over which to transfer BGP configuration and operational data. Note that use of alternate transport or data encoding (e.g., JSON over HTTPS) would require similar mechanisms for authenticating and securing access to configuration data. Most of the data elements in the configuration model could be considered sensitive from a security standpoint. Unauthorized access or invalid data could cause major disruption. 4. IANA Considerations This YANG data model and the component modules currently use a temporary ad-hoc namespace. If and when it is placed on redirected for the standards track, an appropriate namespace URI will be registered in the IETF XML Registry" [RFC3688]. The BGP YANG modules will be registered in the "YANG Module Names" registry [RFC6020]. 5. YANG modules The modules comprising the BGP configuration and operational model are described by the YANG modules in the sections below. The base module imports the other modules to create the overall model. Shaikh, et al. Expires April 29, 2015 [Page 5] Internet-Draft BGP Configuration Model October 2014 5.1. BGP base model file bgp.yang module bgp { yang-version "1"; // namespace // TODO: change to an ietf or other more generic namespace namespace "http://google.com/yang/google-bgp-protocol-cfg"; prefix "bgp"; // import some basic inet types import ietf-inet-types { prefix inet; } import bgp-multiprotocol { prefix bgp-mp; } import bgp-policy { prefix bgp-pol; } import bgp-operational { prefix bgp-op; } // meta organization "Google, AT&T, BT, Microsoft"; contact "Google, Inc. 1600 Amphitheatre Way Mountain View, CA 94043 AT&T Labs 200 S. Laurel Avenue Middletown, NJ 07748 BT pp. C3L, BT Centre 81, Newgate Street London EC1A 7AJ UK Microsoft 205 108th Ave. NE, Suite 400 Bellevue, WA 98004"; description "This module describes a YANG model for BGP protocol configuration.It is a limited subset of all of the configuration parameters available in the variety of vendor implementations, hence it is expected that it would be augmented with vendor- Shaikh, et al. Expires April 29, 2015 [Page 6] Internet-Draft BGP Configuration Model October 2014 specific configuration data as needed.Additional modules or submodules to handle other aspects of BGP configuration, including policy, VRFs, VPNs, and additional address families are also expected. This model supports the following BGP configuration level hierarchy: BGP | +-> [ global BGP configuration ] +-> AFI / SAFI (address family) +-> [AFI-specific config ] +-> peer group +-> [ peer group config ] +-> AFI / SAFI [ per-AFI overrides ] +-> neighbor +-> [ per-neighbor overrides ] +-> AFI / SAFI [ per-AFI overrides ] +-> neighbor +-> [ neighbor config ] +-> AFI / SAFI [ per-AFI overrides ]"; revision "2014-09-30" { description "Initial revision"; reference "TBD"; } typedef peer-type { type enumeration { enum INTERNAL { description "internal (iBGP) peer"; } enum EXTERNAL { description "external (eBGP) peer"; } } description "labels a peer or peer group as explicitly internal or external"; } typedef remove-private-as-option { type enumeration { Shaikh, et al. Expires April 29, 2015 [Page 7] Internet-Draft BGP Configuration Model October 2014 enum ALL { description "remove all private ASes in the path"; } enum REPLACE { description "replace private ASes with local AS"; } } description "set of options for configuring how private AS path numbers are removed from advertisements"; } typedef percentage { type uint8 { range "0..100"; } description "Integer indicating a percentage value"; } typedef rr-cluster-id-type { type union { type uint32; type inet:ipv4-address; } description "union type for route reflector cluster ids: option 1: 4-byte number option 2: IP address"; } grouping bgp-common-configuration { description "Common configuration available at all hierarchy levels, global, AFI, groups, neighbors, etc."; leaf description { type string; description "An optional textual description (intended primarily for use with a peer or group"; } container route-selection-options { // TODO: consider moving this container to AFI/SAFI level // config description "Set of configuration options that govern best path selection."; Shaikh, et al. Expires April 29, 2015 [Page 8] Internet-Draft BGP Configuration Model October 2014 leaf always-compare-med { type boolean; default "false"; description "Compare multi-exit discriminator (MED) value from different ASes when selecting the best route. The default behavior is to only compare MEDs for paths received from the same AS."; } leaf ignore-as-path-length { type boolean; default "false"; description "Ignore the AS path length when selecting the best path. The default is to use the AS path length and prefer paths with shorter length."; } leaf external-compare-router-id { type boolean; default "true"; description "When comparing similar routes received from external BGP peers, use the router-id as a criterion to select the active path."; } leaf advertise-inactive-routes { type boolean; default "false"; description "Advertise inactive routes to external peers. The default is to only advertise active routes."; } leaf enable-aigp { type empty; description "Flag to enable sending / receiving accumulated IGP attribute in routing updates"; } } container use-multiple-paths { presence "Presence of this container indicates that multipath Shaikh, et al. Expires April 29, 2015 [Page 9] Internet-Draft BGP Configuration Model October 2014 is enabled for both eBGP and iBGP, absence indicates that multi-path is not used"; description "Configuration of BGP multi-path for iBGP and eBGP"; container ebgp { description "Configuration of BGP multipath to enable load sharing across multiple paths to eBGP peers"; leaf allow-multiple-as { type boolean; default "false"; description "Allow multipath to use paths from different neighbouring ASes. The default is to only consider multiple paths from the same neighbouring AS."; } leaf maximum-paths { type uint32; default 1; description "Maximum number of parallel paths to consider when using BGP multipath. The default is use a single path."; } } container ibgp { description "Configuration of BGP multipath to enable load-sharing across multiple paths to iBGP peers"; leaf maximum-paths { type uint32; default 1; description "Maximum number of parallel paths to consider when using iBGP multipath. The default is to use a single path"; } } container eibgp { description "Configuration of BGP multipath to enable load-sharing across multiple paths to external confederation sub-ASes"; Shaikh, et al. Expires April 29, 2015 [Page 10] Internet-Draft BGP Configuration Model October 2014 leaf maximum-paths { type uint32; default 1; description "Maximum number of parallel paths to consider when using eiBGP multipath. The default is to use a single path"; } } } container graceful-restart { // TODO: most impls seem to require this at the global level // in order to specify at neighbor or other levels presence "Presence of this item indicates that BGP graceful restart is enabled."; description "Configures BGP graceful restart, which is a negotiated option that indicates that a BGP speaker is able to retain forwarding state when a BGP session restarts"; reference "RFC 4724: Graceful Restart Mechanism for BGP"; leaf restart-time { type uint16 { range 0..4096; } description "Estimated time in seconds for the BGP session to be re-established after a restart. This is a 12-bit value advertised by the router to peers. Per RFC 4724, the suggested default value is <= the hold-time value"; } leaf stale-routes-time { type decimal64 { fraction-digits 2; } description "Sets an upper bound on the time in seconds that stale routes will be retained by the router after a session is restarted"; } } uses bgp-pol:apply-policy-group; Shaikh, et al. Expires April 29, 2015 [Page 11] Internet-Draft BGP Configuration Model October 2014 } grouping bgp-global-configuration { description "Grouping for global level configuration items"; leaf as { type inet:as-number; mandatory "true"; description "Local autonomous system number of the router. Uses the 32-bit as-number type from the model in RFC 6991"; } leaf router-id { type inet:ipv4-address; description "Router id of the router, expressed as an 32-bit value, IPv4 address."; } container default-route-distance { description "Administrative distance (or preference) assigned to routes received from different sources (external, internal, and local)."; leaf external-route-distance { type uint8 { range "1..255"; } description "Administrative distance for routes learned from external BGP (eBGP)."; } leaf internal-route-distance { type uint8 { range "1..255"; } description "Administrative distance for routes learned from internal BGP (iBGP)."; } } container confederation { presence "Presence of this node indicates that the local AS is part of a confederation"; Shaikh, et al. Expires April 29, 2015 [Page 12] Internet-Draft BGP Configuration Model October 2014 description "Configuration for a BGP confederation consisting of a confed id and member sub-AS list"; leaf identifier { type inet:as-number; description "Confederation identifier for the autonomous system"; } leaf-list member-as { type inet:as-number; description "Remote autonomous systems that are to be treated as part of the local confederation."; } } } grouping bgp-group-common-configuration { description "Configuration items that are applied at the peer group level"; // currently a placeholder in case we identify config that is // really only applicable at the group level } grouping bgp-group-neighbor-common-configuration { description "Configuration items that are applied at the peer or peer group levels"; leaf auth-password { type string; description "Configures an MD5 authentication password for use with neighboring devices."; } leaf peer-type { type peer-type; description "Explicitly designate the peer or peer group as internal (iBGP) or external (eBGP)."; } container timers { description "Configuration of various BGP timers"; Shaikh, et al. Expires April 29, 2015 [Page 13] Internet-Draft BGP Configuration Model October 2014 leaf connect-retry { type decimal64 { fraction-digits 2; } default 30; description "Time interval in seconds between attempts to establish a session with the peer."; } leaf hold-time { type decimal64 { fraction-digits 2; } default 90; description "Time interval in seconds that a BGP session will be considered active in the absence of keepalive or other messages from the peer. The hold-time is typically set to 3x the keepalive-interval."; reference "RFC 4271 - A Border Gateway Protocol 4, Sec. 10"; } leaf keepalive-interval { type decimal64 { fraction-digits 2; } default 30; description "Time interval in seconds between transmission of keepalive messages to the neighbor. Typically set to 1/3 the hold-time."; } leaf minimum-advertisement-interval { type decimal64 { fraction-digits 2; } default 30; description "Mininum time interval in seconds between transmission of BGP updates to neighbors"; reference "RFC 4271 - A Border Gateway Protocol 4, Sec 10"; } leaf send-update-delay { Shaikh, et al. Expires April 29, 2015 [Page 14] Internet-Draft BGP Configuration Model October 2014 type decimal64 { fraction-digits 2; } description "Time interval between routes changing in the routing table and corresponding updates sent to neighbors -- serves to batch updates"; } } container ebgp-multihop { description "Configure multihop BGP for peers that are not directly connected"; leaf multihop-ttl { type uint8; default 1; description "Time-to-live for multihop BGP sessions. The default value of 1 is for directly connected peers (i.e., multihop disabled"; } } container route-reflector { description "Configure the local router as a route-reflector server"; leaf route-reflector-cluster-id { type rr-cluster-id-type; description "route-reflector cluster id to use when local router is configured as a route reflector. Commonly set at the group level, but allows a different cluster id to be set for each neighbor."; } leaf route-reflector-client { type boolean; default "false"; description "Configure the neighbor as a route reflector client."; } Shaikh, et al. Expires April 29, 2015 [Page 15] Internet-Draft BGP Configuration Model October 2014 } leaf remove-private-as { // could also make this a container with a flag to enable // remove-private and separate option. here, option implies // remove-private is enabled. type remove-private-as-option; description "Remove private AS numbers from updates sent to peers."; } container bgp-logging-options { description "Configure various tracing/logging options for BGP peers or groups. Expected that additional vendor-specific log options would augment this container."; leaf log-neighbor-state-changes { type boolean; default "true"; description "Configure logging of peer state changes. Default is to enable logging of peer state changes."; } } container transport-options { description "Transport protocol options for BGP sessions"; leaf tcp-mss { type uint16; description "Sets the max segment size for BGP TCP sessions."; } leaf mtu-discovery { type boolean; description "Turns path mtu discovery for BGP TCP sessions on (true) or off (false)"; } leaf passive-mode { type boolean; description "Wait for peers to issue requests to open a BGP session, rather than initiating sessions from the local router."; Shaikh, et al. Expires April 29, 2015 [Page 16] Internet-Draft BGP Configuration Model October 2014 } } leaf local-address { type inet:ip-address; description "Set the local IP (either IPv4 or IPv6) address to use for the session when sending BGP update messages."; } leaf route-flap-damping { type boolean; description "Enable route flap damping."; } } grouping bgp-neighbor-configuration { description "Neighbor-level configuration items"; list neighbor { key "neighbor-address"; description "List of BGP peers, uniquely identified by neighbor address."; leaf neighbor-address { type inet:ip-address; description "Address of the BGP peer, either IPv4 or IPv6."; } leaf peer-as { type inet:as-number; mandatory "true"; description "AS number of the peer."; } uses bgp-common-configuration; uses bgp-mp:address-family-configuration; uses bgp-group-neighbor-common-configuration; uses bgp-op:bgp-op-neighbor-group; } } container bgp { Shaikh, et al. Expires April 29, 2015 [Page 17] Internet-Draft BGP Configuration Model October 2014 description "Top-level configuration data for the BGP router"; container global { description "Top-level bgp protocol options applied at the global level in the hierarchy -- these apply across peer-groups, neighbors, and address families"; uses bgp-global-configuration; // attach global level operational data uses bgp-op:bgp-op-global-group; } // top level AF configuration uses bgp-mp:address-family-configuration; list peer-group { key "group-name"; description "List of peer-groups, uniquely identified by the peer group name."; leaf group-name { type string; description "Name of the peer group."; } uses bgp-op:bgp-op-peergroup-group; uses bgp-common-configuration; uses bgp-mp:address-family-configuration; uses bgp-group-neighbor-common-configuration; // list of configurations for neighbors in this peer group uses bgp-neighbor-configuration; } // top level neighbor configuration uses bgp-neighbor-configuration; // hook for top-level policy definitions uses bgp-pol:policy-definition-group; } } Shaikh, et al. Expires April 29, 2015 [Page 18] Internet-Draft BGP Configuration Model October 2014 5.2. BGP policy model file bgp-policy.yang module bgp-policy { yang-version "1"; // namespace // TODO: change to an ietf or other generic namespace namespace "http://google.com/yang/google-bgp-policy-cfg"; prefix "bgp-policy"; // import some basic types import ietf-inet-types { prefix inet; } // meta // TODO: add collaborating organizations organization "Google, AT&T, BT, Microsoft"; contact "Google, Inc. 1600 Amphitheatre Way Mountain View, CA 94043 AT&T Labs 200 S. Laurel Avenue Middletown, NJ 07748 BT pp. C3L, BT Centre 81, Newgate Street London EC1A 7AJ UK Microsoft 205 108th Ave. NE, Suite 400 Bellevue, WA 98004"; description "This module describes a YANG model for BGP policy configuration. It is a limited subset of all of the policy configuration parameters available in the variety of vendor implementations, but supports widely used constructs for managing how BGP routes are imported, exported, and modified. This module works with the base BGP protocol configuration model defined in Shaikh, et al. Expires April 29, 2015 [Page 19] Internet-Draft BGP Configuration Model October 2014 google-bgp. Route policy expression: Policies are expressed as a set of top-level policy definitions, each of which consists of a sequence of policy statements. Policy statements are simple condition-action tuples. Conditions may include mutiple match or comparison operations, and similarly actions may be multitude of changes to route attributes and a final disposition of accepting or> rejecting the route. BGP | +->policy +-> policy definitions +-> policy statements +-> conditions +-> [ match conditions / comparison conditions ] +-> actions +-> [ set attribute actions / control-flow actions ] Route policy evaluation: Evaluation of a policy definition is expected to proceed by evaluating the individual policy statements in the specified order. When a condition statement in a policy statement is satisfied, the corresponding action statement is executed. If the action statement has either accept-route or reject-route actions, policy evaluation stops. If the condition is not satisfied, or if the action statement contains goto-next, then evaluation proceeds to the next policy statement. If none of the policy statement conditions are satisfied, then the default action is applied. Policy 'subroutines' are supported by allowing condition statements to reference another policy definition which first applies conditions from the referenced policy before proceeding."; revision "2014-09-30" { description "Initial revision"; reference "TBD"; } // extension statements Shaikh, et al. Expires April 29, 2015 [Page 20] Internet-Draft BGP Configuration Model October 2014 // feature statements // identity statements identity bgp-attribute-comparison { description "base type for supported comparison operators on route attributes"; } identity attribute-eq { base bgp-attribute-comparison; description "== comparison"; } identity attribute-ge { base bgp-attribute-comparison; description ">= comparison"; } identity attribute-le { base bgp-attribute-comparison; description "<= comparison"; } // typedef statements typedef match-set-options-type { type enumeration { enum ANY { description "match is true if given value matches any member of the defined set"; } enum ALL { description "match is true if each given value matches a member of the defined set"; } enum INVERT { description "match is true if given value does not match any member of the defined set"; } } default ANY; description "Options that govern the behavior of a match statement. The default behavior is ANY, i.e., the given value matches any of the members of the defined set"; Shaikh, et al. Expires April 29, 2015 [Page 21] Internet-Draft BGP Configuration Model October 2014 } typedef as-path-prepend-option-repeat { type uint32; description "Option for the as-prepend policy action. Prepends the local AS number repeated n times"; } typedef well-known-community-attr { type enumeration { enum INTERNET { description "entire Internet community (0x00000000)"; } enum NO_EXPORT { // value 0xFFFFFF01; description "no export"; } enum NO_ADVERTISE { description "no advertise (0xFFFFFF02)"; } enum NO_EXPORT_SUBCONFED { description "no export subconfed, equivalent to local AS (0xFFFFFF03)"; } } description "Type definition for well-known IETF community attribute values"; reference "RFC 1997 - BGP Communities Attribute"; } typedef std-community-attr-type { // TODO: further refine restrictions and allowed patterns // 4-octet value: // 2 octets // 2 octets type union { type uint32 { // per RFC 1997, 0x00000000 - 0x0000FFFF and 0xFFFF0000 - // 0xFFFFFFFF are reserved range "65536..4294901759"; // 0x00010000..0xFFFEFFFF } type string { pattern '([0-9]+:[0-9]+)'; } } Shaikh, et al. Expires April 29, 2015 [Page 22] Internet-Draft BGP Configuration Model October 2014 description "Type definition for standard commmunity attributes"; reference "RFC 1997 - BGP Communities Attribute"; } typedef ext-community-attr-type { // TODO: needs more work to make this more precise given the // variability of extended community attribute specifications // 8-octet value: // 2 octects // 6 octets type string { pattern '([0-9\.]+(:[0-9]+)?:[0-9]+)'; } description "Type definition for extended community attributes"; reference "RFC 4360 - BGP Extended Communities Attribute"; } typedef community-regexp-type { // TODO: needs more work to decide what format these regexps can // take. type string; description "Type definition for communities specified as regular expression patterns"; } typedef bgp-origin-attr-type { type enumeration { enum IGP { value 0; description "Origin of the NLRI is internal"; } enum EGP { value 1; description "Origin of the NLRI is EGP"; } enum INCOMPLETE { value 2; description "Origin of the NLRI is neither IGP or EGP"; } } description "Type definition for standard BGP origin attribute"; reference "RFC 4271 - A Border Gateway Protocol 4 (BGP-4), Sec 4.3"; } Shaikh, et al. Expires April 29, 2015 [Page 23] Internet-Draft BGP Configuration Model October 2014 typedef set-community-option-type { type enumeration { enum ADD { description "add the specified communities to the existing community attribute"; } enum REMOVE { description "remove the specified communities from the existing community attribute"; } enum REPLACE { description "replace the existing community attribute with the specified communities"; } enum NULL { description "set the community attribute to empty / NULL"; } } description "Type definition for options when setting the community attribute in a policy action"; } typedef bgp-next-hop-type { type union { type inet:ip-address; type enumeration { enum SELF { description "special designation for local router's own address"; } } } description "type definition for specifying next-hop in policy actions"; } // grouping statements grouping defined-sets-definitions { description "Data definitions for pre-defined sets of attributes used in policy match conditions"; list prefix-set { key prefix-set-name; description Shaikh, et al. Expires April 29, 2015 [Page 24] Internet-Draft BGP Configuration Model October 2014 "Definitions for prefix sets"; leaf prefix-set-name { type string; description "name / label of the prefix set -- this is used to reference the set in match conditions"; } list prefix { key "address masklength masklength-range"; description "list of prefix expressions that are part of the set"; leaf address { type inet:ip-address; mandatory true; description "address portion of the prefix"; } leaf masklength { type uint8 { // simple range covers both ipv4 and ipv6 -- // could separate this into different types // for IPv4 and IPv6 prefixes range 1..128; } mandatory true; description "masklength for the prefix specification"; } leaf masklength-range { type string { // pattern modeled after ietf-inet-types pattern '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' + '(12[0-8]))\.\.' + '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' + '(12[0-8]))'; } description "Defines an optional range for the masklength. Absence of the masklength-length implies that the prefix has an exact masklength given by the masklength parameter. Example: 10.3.192.0/21 through 10.3.192.0/24 would be expressed as address: 10.3.192.0, masklength: 21, masklength-range: 21..24"; Shaikh, et al. Expires April 29, 2015 [Page 25] Internet-Draft BGP Configuration Model October 2014 } } } list community-set { key community-set-name; description "Definitions for community sets"; leaf community-set-name { type string; mandatory true; description "name / label of the community set -- this is used to reference the set in match conditions"; } leaf-list community-members { type union { type std-community-attr-type; type community-regexp-type; type well-known-community-attr; } description "members of the community set"; } } list ext-community-set { key ext-community-set-name; description "Definitions for extended community sets"; leaf ext-community-set-name { type string; description "name / label of the extended community set -- this is used to reference the set in match conditions"; } leaf-list ext-community-members { type union { type ext-community-attr-type; // TODO: is regexp support needed for extended communities? // TODO: is well-known needed for extended communities? type community-regexp-type; } Shaikh, et al. Expires April 29, 2015 [Page 26] Internet-Draft BGP Configuration Model October 2014 description "members of the extended community set"; } } list as-path-set { key as-path-set-name; description "Definitions for AS path sets"; leaf as-path-set-name { type string; description "name of the AS path set -- this is used to reference the the set in match conditions"; } leaf-list as-path-set-members { // TODO: need to refine typedef for AS path expressions type string; description "AS path expression -- list of ASes in the set"; } } } grouping condition-set-matches { description "Condition statement definitions for checking membership in a defined set"; leaf match-community-set { type leafref { path "/policy/defined-sets/community-set/community-set-name"; require-instance true; } description "References a defined community set"; } leaf match-ext-community-set { type leafref { path "/policy/defined-sets/ext-community-set" + "/ext-community-set-name"; } description "References a defined extended community set"; } Shaikh, et al. Expires April 29, 2015 [Page 27] Internet-Draft BGP Configuration Model October 2014 leaf match-as-path-set { type leafref { path "/policy/defined-sets/as-path-set/as-path-set-name"; } description "References a defined AS path set"; } leaf match-prefix-set { type leafref { path "/policy/defined-sets/prefix-set/prefix-set-name"; } description "References a defined prefix set"; } leaf match-set-options { type match-set-options-type; description "Optional parameter that governs the behavior of the match operation"; } } grouping condition-attribute-compare-operators { description "common definitions for comparison operations in condition statements"; leaf operator { type identityref { base bgp-attribute-comparison; } description "type of comparison to be performed"; } leaf value { type uint32; description "value to compare with the community count"; } } grouping condition-attribute-comparisons { description "Condition statement definitions for comparing a route attribute to a specified value"; leaf med-eq { type uint32; Shaikh, et al. Expires April 29, 2015 [Page 28] Internet-Draft BGP Configuration Model October 2014 description "Condition to check if the received MED value is equal to the specified value"; } leaf origin-eq { type bgp-origin-attr-type; description "Condition to check if the route origin is equal to the specified value"; } leaf-list next-hop-in { type inet:ip-address; description "List of next hop addresses to check for in the route update"; } leaf local-pref-eq { type uint32; // TODO: add support for other comparisons description "Condition to check if the local pref attribute is equal to the specified value"; } container community-count { presence "node is present in the config data to indicate a community-count condition"; description "Value and comparison operations for conditions based on the number of communities in the route update"; uses condition-attribute-compare-operators; } container as-path-length { presence "node is present in the config data to indicate a as-path-length condition"; description "Value and comparison operations for conditions based on the length of the AS path in the route update"; Shaikh, et al. Expires April 29, 2015 [Page 29] Internet-Draft BGP Configuration Model October 2014 uses condition-attribute-compare-operators; } leaf route-type { // TODO: verify extent of vendor support for this comparison type enumeration { enum INTERNAL { description "route type is internal"; } enum EXTERNAL { description "route type is external"; } } description "Condition to check the route type in the route update"; } } grouping set-attribute-actions { description "Definitions for base set of policy action statements that change various attributes of the route"; container set-as-path-prepend { presence "node is present in the config data to use the AS prepend action"; description "action to prepend local AS number to the AS-path a specified number of times"; leaf repeat-n { type uint8; description "number of times to prepend the local AS number"; } } container set-community { presence "node is present in the config data when set-community action is used"; description "action to set the community attributes of the route, along with options to modify how the community is modified"; leaf-list communities { type union { type std-community-attr-type; Shaikh, et al. Expires April 29, 2015 [Page 30] Internet-Draft BGP Configuration Model October 2014 type well-known-community-attr; } description "community values for the update"; } leaf options { type set-community-option-type; description "options for modifying the community attribute with the specified values"; } } container set-ext-community { presence "node is present in the config data when set-community action is used"; description "action to set the extended community attributes of the route, along with options to modify how the community is modified"; leaf-list communities { type union { type ext-community-attr-type; type well-known-community-attr; } description "community values for the update"; } leaf options { type set-community-option-type; description "options for modifying the community attribute with the specified values"; } } leaf set-route-origin { type bgp-origin-attr-type; description "set the origin attribute to the specified value"; } leaf set-local-pref { type uint32; description "set the local pref attribute on the route update"; Shaikh, et al. Expires April 29, 2015 [Page 31] Internet-Draft BGP Configuration Model October 2014 } leaf set-next-hop { type bgp-next-hop-type; description "set the next-hop attribute in the route update"; } leaf set-med { type uint32; description "set the med metric attribute in the route update"; } } grouping control-flow-actions { description "Definitions for base set of policy action statements that manage the disposition or control flow of the policy"; leaf accept-route { type empty; description "accepts the route into the routing table"; } leaf reject-route { type empty; description "rejects the route"; } leaf goto-next { type empty; description "proceed to evaluate the next policy statement in the policy definition"; } leaf goto-policy { type string; description "proceed to the named policy definition and continue evaluating the policy"; } } grouping conditions { description "Condition statement definitions for policy statements"; Shaikh, et al. Expires April 29, 2015 [Page 32] Internet-Draft BGP Configuration Model October 2014 leaf call-policy { type string; description "Applies the conditions from the specified policy definition in the current policy statement."; } uses condition-set-matches; uses condition-attribute-comparisons; } grouping actions { description "Action statement definitions for policy statements"; uses set-attribute-actions; uses control-flow-actions; } grouping apply-policy-group { description "top level configuration for applying policies at various points in the configuration hierarchy"; container apply-policy { description "Anchor point for policies in the BGP configuration. Import and export policies are with respect to the local routing table, i.e., export (send) and import (receive)."; leaf-list import-policies { type leafref { path "/bgp/policy/policy-definitions/policy-definition" + "/name"; require-instance true; } description "list of policy names in sequence to be applied on receiving a routing update in the current context, e.g., for the current peer group, neighbor, address family, etc."; } leaf-list export-policies { type leafref { path "/bgp/policy/policy-definitions/policy-definition" Shaikh, et al. Expires April 29, 2015 [Page 33] Internet-Draft BGP Configuration Model October 2014 + "/name"; require-instance true; } description "list of policy names in sequence to be applied on sending a routing update in the current context, e.g., for the current peer group, neighbor, address family, etc."; } } } grouping policy-definition-group { description "top level set of policy defined sets and policy definitions"; container policy { description "Top level container for BGP policy-related configuration items"; container defined-sets { presence "Container for sets defined for matching in policy statements"; description "Predefined sets of attributes used in policy match statements"; uses defined-sets-definitions; } container policy-definitions { presence "Container for the set of policy definitions"; description "Top level container for policy definitions"; list policy-definition { key name; ordered-by user; description "List of top-level policy definitions, keyed by a unique name"; leaf name { type string; description "Name of the top-level policy definition -- this name Shaikh, et al. Expires April 29, 2015 [Page 34] Internet-Draft BGP Configuration Model October 2014 is used in references to the current policy"; } list statements { key name; // TODO: names of policy statements withing a policy defn // should be optional, however, YANG requires a unique id // for lists; not sure that a compound key works either; // need to investigate further. ordered-by user; description "Name of this policy statement"; leaf name { type string; description "name of the policy statement"; } container conditions { description "Condition statements for this policy statement"; uses conditions; } container actions { description "Action statements for this policy statement"; uses actions; } } } } } } // augment statements // rpc statements // notification statements } Shaikh, et al. Expires April 29, 2015 [Page 35] Internet-Draft BGP Configuration Model October 2014 5.3. BGP multiprotocol model file bgp-multiprotocol.yang module bgp-multiprotocol { yang-version "1"; // namespace // TODO: change to an ietf or other more generic namespace namespace "http://google.com/yang/google-bgp-multiprotocol-cfg"; prefix "bgp-mp"; // import some basic inet types import ietf-inet-types { prefix inet; } import bgp-policy { prefix bgp-pol; } import bgp-operational { prefix bgp-op; } // meta organization "Google, AT&T, BT, Microsoft"; contact "Google, Inc. 1600 Amphitheatre Way Mountain View, CA 94043 AT&T Labs 200 S. Laurel Avenue Middletown, NJ 07748 BT pp. C3L, BT Centre 81, Newgate Street London EC1A 7AJ UK Microsoft 205 108th Ave. NE, Suite 400 Bellevue, WA 98004"; description "This module is part of a YANG model for BGP protocol configuration, focusing on configuration of multiprotocol BGP, in particular various relevant address families (AFI) and sub-address families (SAFI). Shaikh, et al. Expires April 29, 2015 [Page 36] Internet-Draft BGP Configuration Model October 2014 Identities (rather than enumerated types) are used to identify each AFI / SAFI type to make it easier for users to extend to pre-standard or custom AFI/SAFI types. This module is only intended to capture the most"; revision "2014-10-13" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements identity afi-type { description "base identity type for BGP address family identifiers (AFI)"; reference "RFC 4760 - Multiprotocol Extensions for BGP-4"; } identity safi-type { description "base identity type for BGP subsequent address family identifiers (SAFI)"; reference "RFC 4760 - Multiprotocol Extensions for BGP-4"; } identity ipv4-afi { base bgp-mp:afi-type; description "IPv4 AF identifier (AFI = 1)"; } identity ipv6-afi { base bgp-mp:afi-type; description "IPv6 AF identifier (AFI = 2)"; } identity unicast-safi { base bgp-mp:safi-type; description "unicast SAFI identifier (SAFI = 1)"; } Shaikh, et al. Expires April 29, 2015 [Page 37] Internet-Draft BGP Configuration Model October 2014 identity l3vpn-unicast-safi { base safi-type; description "L3 / MPLS virtual private networks SAFI (SAFI = 128/129)"; reference "RFC 4364 - BGP/MPLS IP Virtual Private Networks (VPNs)"; } identity labeled-unicast-safi { base safi-type; description "labeled unicast SAFI identifier (SAFI = 4)"; reference "RFC 3107 - Carrying Label Information in BGP-4"; } identity l2vpn-vpls-afi { base afi-type; description "AFI for BGP L2 VPN / VPLS (AFI = 25)"; reference "RFC 4761 - Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"; } identity l2vpn-vpls-safi { base safi-type; description "BGP L2 VPN / VPLS service SAFI (SAFI = 65)"; } identity multicast-safi { base safi-type; description "multicast SAFI (SAFI = 2)"; reference "RFC 4760 - Multiprotocol Extensions for BGP-4"; } identity multicast-vpn-safi { base safi-type; description "Multicast VPN SAFI (SAFI = 5)"; reference "RFC 6514 - BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs"; } // typedef statements // TODO: move this and other commonly types to a common bgp-types // module Shaikh, et al. Expires April 29, 2015 [Page 38] Internet-Draft BGP Configuration Model October 2014 typedef percentage { type uint8 { range "0..100"; } description "Integer indicating a percentage value"; } // grouping statements grouping address-family-common { description "Configuration that is for the address family level, but applies across AFI/SAFI"; container prefix-limit { description "Configure the maximum number of prefixes that will be accepted from a peer."; leaf max-prefixes { type uint32; description "Maximum number of prefixes that will be accepted from the neighbor."; } leaf shutdown-threshold-pct { type percentage; description "Threshold on number of prefixes that can be received from a neighbor before generation of warning messages or log entries. Expressed as a percentage of max-prefixes."; } leaf restart-timer { type decimal64 { fraction-digits 2; } units "seconds"; description "Time interval in seconds after which the BGP session is reestablished after being torn down due to exceeding the max-prefixes limit."; } } Shaikh, et al. Expires April 29, 2015 [Page 39] Internet-Draft BGP Configuration Model October 2014 // policies can be applied at a specific AF level uses bgp-pol:apply-policy-group; } grouping ipv4-ipv6-unicast-common { description "common configuration for base ipv4 and ipv6 unicast; may need to be split into separate containers for each of ipv4 and ipv6"; container ipv4-ipv6-unicast { // YANG uses XPath 1.0 expression syntax when "(../../afi-name = 'ipv4-afi' or " + "../../afi-name = 'ipv6-afi') " + "and ../safi-name = 'unicast-safi'" { description "Include this container for unicast ipv4 or ipv6 AFI-specific configuration"; } description "ipv4 unicast config items"; leaf send-default-route { // TODO: consider moving this to policy type boolean; default "false"; description "if set to true, send the default route, i.e., 0.0.0.0/0 to the neighbor(s)"; } } } grouping ipv4-l3vpn-unicast-group { description "configuration group for L3 VPN VRFs for IPv4"; container ipv4-l3vpn-unicast { when "../../afi-name = 'bgp-mp:ipv4-afi' and " + "../safi-name = 'l3vpn-unicast-safi'" { description "Include this container when AFI = ipv4 and SAFI = l3vpn-unicast"; } description "ipv4 l3vpn config items"; Shaikh, et al. Expires April 29, 2015 [Page 40] Internet-Draft BGP Configuration Model October 2014 list vrfs { key name; description "list of configured VRFs"; leaf name { type string; description "name / identifier of the VRF"; } leaf route-distinguisher { // TODO: consider expanding to a union type to make it more // convenient to express as AS:addr or other common formats type uint64; description "route distinguisher value assigned to this VRF"; } uses bgp-pol:apply-policy-group; /* additional leafs to consider --- should these be in BGP? interface-name retain-local-label-size advertise-best-external no-synchronization */ } } } grouping ipv6-l3vpn-unicast-group { description "configuration group for L3 VPN VRFs for IPv6"; container ipv6-l3vpn-unicast { when "../../afi-name = 'bgp-mp:ipv6-afi' and " + "../safi-name = 'l3vpn-unicast-safi'" { description "Include this container only when AFI = ipv6 and SAFI = l3vpn-unicast"; } description "ipv6 l3vpn config items"; } } grouping ipv4-labeled-unicast-group { description "configuration group for IPv4 labeled unicast"; Shaikh, et al. Expires April 29, 2015 [Page 41] Internet-Draft BGP Configuration Model October 2014 container ipv4-labeled-unicast { when "../../afi-name = 'ipv4-afi' and " + "../safi-name = 'labeled-unicast-safi'" { description "Include this container when AFI = ipv4 and SAFI = labeled-unicast"; } description "ipv4 labeled unicast config items"; } } grouping l2vpn-group { description "configuration group for L2 VPN"; container l2vpn { // TODO: confirm that both AFI/SAFI values are set // for L2 VPNs when "../../afi-name = 'l2vpn-vpls-afi' and " + "../safi-name = 'l2vpn-vpls-safi'" { description "Include this container when AFI = l2vpn-vpls and SAFI = l2vpn-vpls"; } description "l2vpn config items"; } } grouping ipv4-multicast-vpn-group { description "configuration group for IPv4 multicast VPNs"; container ipv4-multicast-vpn { when "../../afi-name = 'ipv4-afi' and " + "../safi-name = 'multicast-vpn-safi'" { description "Include this container when AFI = ipv4 and SAFI = multicast-vpn"; } description "ipv4 multicast vpn config items"; } } grouping ipv6-multicast-vpn-group { description "configuration group for IPv6 multicast VPNs"; container ipv6-multicast-vpn { Shaikh, et al. Expires April 29, 2015 [Page 42] Internet-Draft BGP Configuration Model October 2014 when "../../afi-name = 'ipv6-afi' and " + "../safi-name = 'multicast-vpn-safi'" { description "Include this container when AFI = ipv6 and SAFI = multicast-vpn"; } description "ipv6 multicast vpn config items"; } } grouping address-family-configuration { description "Configuration options that are applied at the address family level."; list afi { key "afi-name"; description "Per address-family configuration, uniquely identified by AF name."; leaf afi-name { type identityref { base "afi-type"; } description "Address family names are drawn from the afi-type base identity, which has specific address family types as derived identities."; } list safi { key "safi-name"; description "Per subsequent address family configuration, under a specific address family."; leaf safi-name { type identityref { base "safi-type"; } description "Within each address family, subsequent address family names are drawn from the subsequent-address-family base identity."; } // these grouping references conditionally add config nodes Shaikh, et al. Expires April 29, 2015 [Page 43] Internet-Draft BGP Configuration Model October 2014 // that are specific to each AFI / SAFI combination uses ipv4-ipv6-unicast-common; uses ipv4-l3vpn-unicast-group; uses ipv6-l3vpn-unicast-group; uses ipv4-labeled-unicast-group; uses l2vpn-group; uses ipv4-multicast-vpn-group; uses ipv6-multicast-vpn-group; // this grouping pulls in the config items common across // AF/SAFI combinations uses address-family-common; } // operational state common acrossr address families uses bgp-op:bgp-op-af-group; } } // data definition statements // augment statements // rpc statements // notification statements } 5.4. BGP operational data model file bgp-operational.yang module bgp-operational { yang-version "1"; // namespace // TODO: change to an ietf or other more generic namespace namespace "http://google.com/yang/google-bgp-operational"; prefix "bgp-op"; // import some basic inet types import ietf-inet-types { prefix inet; } Shaikh, et al. Expires April 29, 2015 [Page 44] Internet-Draft BGP Configuration Model October 2014 // meta organization "Google, AT&T, BT, Microsoft"; contact "Google, Inc. 1600 Amphitheatre Way Mountain View, CA 94043 AT&T Labs 200 S. Laurel Avenue Middletown, NJ 07748 BT pp. C3L, BT Centre 81, Newgate Street London EC1A 7AJ UK Microsoft 205 108th Ave. NE, Suite 400 Bellevue, WA 98004"; description "This module is part of a YANG model for BGP protocol configuration, focusing on operational data (i.e., state variables) related to BGP operations"; revision "2014-10-13" { description "Initial revision"; reference "TBD"; } // extension statements // feature statements // identity statements // typedef statements // grouping statements grouping bgp-op-global-group { description Shaikh, et al. Expires April 29, 2015 [Page 45] Internet-Draft BGP Configuration Model October 2014 "top level container for operational state data"; container bgp-global-state { config false; description "data definitions for operational state variables related to the global BGP instance"; } } grouping bgp-op-af-group { description "top level container for operational state data"; container bgp-af-common-state { config false; description "data definitions for operational state variables related to all BGP address families instance"; } } grouping bgp-op-peergroup-group { description "top level container for operational state data"; container bgp-group-common-state { config false; description "data definitions for operational state variables related to BGP peer groups"; } } grouping bgp-op-neighbor-group { description "top level container for operational state data"; container bgp-neighbor-common-state { config false; description "data definitions for operational state variables related to BGP neighbor sesions"; } } // data definition statements Shaikh, et al. Expires April 29, 2015 [Page 46] Internet-Draft BGP Configuration Model October 2014 // augment statements // rpc statements // notification statements } 6. References [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2014. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, July 2013. [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. Appendix A. Acknowledgements The authors are grateful for valuable contributions to this document and the associated models from: Chris Chase, Ed Crabbe, Josh George, Vijay Gill, Ina Minei, Ashok Narayanan, Steve Padgett, Puneet Sood, and Jim Uttaro. Authors' Addresses Anees Shaikh Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 US Email: aashaikh@google.com Shaikh, et al. Expires April 29, 2015 [Page 47] Internet-Draft BGP Configuration Model October 2014 Kevin D'Souza AT&T 200 S. Laurel Ave Middletown, NJ US Email: kd6913@att.com Deepak Bansal Microsoft 205 108th Ave. NE, Suite 400 Bellevue, WA US Email: dbansal@microsoft.com Rob Shakir BT pp. C3L, BT Centre 81, Newgate Street London EC1A 7AJ UK Email: rob.shakir@bt.com URI: http://www.bt.com/ Shaikh, et al. Expires April 29, 2015 [Page 48]