idnits 2.17.1 draft-shaikh-idr-bgp-model-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 522 has weird spacing: '...rouping bgp-g...' -- The document date (October 26, 2014) is 3441 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Shaikh 3 Internet-Draft Google 4 Intended status: Informational K. D'Souza 5 Expires: April 29, 2015 AT&T 6 D. Bansal 7 Microsoft 8 R. Shakir 9 BT 10 October 26, 2014 12 BGP Configuration Model for Service Provider Networks 13 draft-shaikh-idr-bgp-model-00 15 Abstract 17 This document defines a YANG data model for configuring and managing 18 BGP, including protocol, policy, and operational aspects based on 19 carrier and content provider operational requirements. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 29, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 This document describes a YANG [RFC6020] data model for BGP [RFC4271] 56 protocol and policy configuration, as well as defining key 57 operational state data. The model is intended to be vendor-neutral, 58 in order to allow operators to manage BGP configuration in 59 heterogeneous environments with routers supplied by multiple vendors. 60 The model is also intended to be readily mapped to existing 61 implementations, however, to facilitate support from as large a set 62 of routing hardware and software vendors as possible. 64 1.1. Goals and approach 66 This model does not (in the current iteration) aim to be feature 67 complete (i.e., cover all possible features of a BGP implementation). 68 Rather its development is driven by examination of BGP configurations 69 in use across a number of operator network deployments. 71 The focus area of the first version of the model is on base BGP 72 protocol configuration and policy configuration with "hooks" to add 73 support for additional address families, as well as operational data 74 to enable a common model for reading BGP-related state from devices. 76 Configuration items that are deemed to be widely available in 77 existing major BGP implementations are included in the model. Those 78 configuration items that are only available from a single 79 implementation are omitted from the model with the expectation they 80 will be available in companion modules that augment the current 81 model. This allows clarity in identifying data that is part of the 82 vendor-neutral model. 84 Where possible, naming in the model follows conventions used in 85 available standards documents, and otherwise tries to be self- 86 explanatory with sufficient descriptions of the intended behavior. 87 Similarly, configuration data value constraints and default values, 88 where used, are based on recommendations in current standards 89 documentation. Since implementations vary widely in this respect, 90 this version of the model specifies only a limited set of defaults 91 and ranges with the expectation of being more prescriptive in future 92 versions based on actual operator use. 94 2. Model overview 96 The BGP model is defined across several YANG modules but at a high 97 level is organized into three main parts: 99 o protocol configuration -- configuration affecting BGP protocol- 100 related operations, defined at various levels of hierarchy. 102 o policy configuration -- configuration defining the policies that 103 act on routes sent (received) to (from) peers or other routing 104 protocols. 106 o operational state -- variables used for monitoring, management, 107 etc. of BGP operations. 109 These modules also make use of the standard Internet types, such as 110 IP addresses, autonomous system numbers, etc., defined in RFC 6991 111 [RFC6991]. 113 2.1. BGP protocol configuration 115 The BGP protocol configuration model is organized hierarchically, 116 much like the majority of router implementations. That is, 117 configuration items can be specified at multiple levels, as shown 118 below. 120 +--rw bgp 121 +--rw global 122 +--rw afi* [afi-name] 123 +--rw peer-group* [group-name] 124 +--rw neighbor* [neighbor-address] 125 +--rw policy 127 Users may specify configuration at a higher level and have it apply 128 to all lower-level items, or provide overriding configuration at a 129 lower level of the hierarchy. Overriding configuration items are 130 optional. 132 The model makes the simplifying assumption that most of the 133 configuration items are available at all levels of the hierarchy. 134 That is, very little configuration is specific to a particular level 135 in the hierarchy, other than obvious items such as "group- name" only 136 being available for the peer group-level config. A notable exception 137 is for sub-address family configuration where some items are only 138 applicable for a given AFI-SAFI combination. 140 The initial version of the model includes placeholders (i.e., mount 141 points) for configuring different address family or sub address 142 family (AFI/SAFI) combinations in support of BGP multiprotocol 143 extensions [RFC4760]. The focus, however, is on base IPv4 and IPv6 144 configuration, with later versions of the model providing additional 145 configuration for specific AFI/SAFI types. The current scope of AFI/ 146 SAFI combinations is indicated below. Each of the subtrees are 147 containers for configuration specific to the corresponding AFI-SAFI 148 combination. 150 +--rw bgp 151 +--rw afi* [afi-name] 152 +--rw safi* [safi-name] 153 +--rw safi-name identityref 154 +--rw ipv4-ipv6-unicast 155 +--rw ipv4-l3vpn-unicast 156 +--rw ipv6-l3vpn-unicast 157 +--rw ipv4-labeled-unicast 158 +--rw l2vpn 159 +--rw ipv4-multicast-vpn 160 +--rw ipv6-multicast-vpn 161 +--rw prefix-limit 162 +--rw apply-policy 164 2.2. Policy configuration overview 166 The BGP policy configuration model is based on a condition-action 167 model in which policies are expressed as a series of conditions, each 168 with a corresponding action. Conditions include testing for 169 membership in a predefined set (e.g., community attribute matches a 170 predefined set of communities), or testing route attributes for 171 specified values. Actions support setting specific attributes on a 172 route or performing a control flow operation such as accepting or 173 rejecting a route, or going to the next policy. 175 The general structure of policy definitions, policy statements, and 176 condition-action policy rules is shown below. 178 +--rw bgp 179 +--rw policy 180 +--rw policy-definitions! 181 +--rw policy-definition* [name] 182 +--rw name string 183 +--rw statements* [name] 184 +--rw name string 185 +--rw conditions 186 +--rw actions 188 The policy model supports policy subroutines through the use of the 189 condition statement call-policy which applies the conditions from 190 another named policy definition. It also supports policy chaining 191 using the action statements goto-next and goto-policy, which allow 192 policy evaluation to immediately move to the next policy statement in 193 the current policy definition, or move to another named policy 194 definition, respectively. Using multiple policy statements in a 195 policy definition is also a form of policy chaining which will 196 evaluate each policy statement in turn. 198 2.3. Operational data overview 200 The BGP operational data model contains an initial set of state 201 variable definitions that would be required in most service provider 202 deployments for management, monitoring, and fault detection. 204 3. Security Considerations 206 BGP configuration has a significant impact on network operations, and 207 as such any related protocol or model carries potential security 208 risks. 210 YANG data models are generally designed to be used with the NETCONF 211 protocol over an SSH transport. This provides an authenticated and 212 secure channel over which to transfer BGP configuration and 213 operational data. Note that use of alternate transport or data 214 encoding (e.g., JSON over HTTPS) would require similar mechanisms for 215 authenticating and securing access to configuration data. 217 Most of the data elements in the configuration model could be 218 considered sensitive from a security standpoint. Unauthorized access 219 or invalid data could cause major disruption. 221 4. IANA Considerations 223 This YANG data model and the component modules currently use a 224 temporary ad-hoc namespace. If and when it is placed on redirected 225 for the standards track, an appropriate namespace URI will be 226 registered in the IETF XML Registry" [RFC3688]. The BGP YANG modules 227 will be registered in the "YANG Module Names" registry [RFC6020]. 229 5. YANG modules 231 The modules comprising the BGP configuration and operational model 232 are described by the YANG modules in the sections below. The base 233 module imports the other modules to create the overall model. 235 5.1. BGP base model 237 file bgp.yang 238 module bgp { 240 yang-version "1"; 242 // namespace 243 // TODO: change to an ietf or other more generic namespace 244 namespace "http://google.com/yang/google-bgp-protocol-cfg"; 246 prefix "bgp"; 248 // import some basic inet types 249 import ietf-inet-types { prefix inet; } 250 import bgp-multiprotocol { prefix bgp-mp; } 251 import bgp-policy { prefix bgp-pol; } 252 import bgp-operational { prefix bgp-op; } 254 // meta 255 organization 256 "Google, AT&T, BT, Microsoft"; 258 contact 259 "Google, Inc. 260 1600 Amphitheatre Way 261 Mountain View, CA 94043 263 AT&T Labs 264 200 S. Laurel Avenue 265 Middletown, NJ 07748 267 BT 268 pp. C3L, BT Centre 269 81, Newgate Street 270 London EC1A 7AJ 271 UK 273 Microsoft 274 205 108th Ave. NE, Suite 400 275 Bellevue, WA 98004"; 277 description 278 "This module describes a YANG model for BGP protocol 279 configuration.It is a limited subset of all of the configuration 280 parameters available in the variety of vendor implementations, 281 hence it is expected that it would be augmented with vendor- 282 specific configuration data as needed.Additional modules or 283 submodules to handle other aspects of BGP configuration, 284 including policy, VRFs, VPNs, and additional address families 285 are also expected. 287 This model supports the following BGP configuration level 288 hierarchy: 290 BGP 291 | 292 +-> [ global BGP configuration ] 293 +-> AFI / SAFI (address family) 294 +-> [AFI-specific config ] 295 +-> peer group 296 +-> [ peer group config ] 297 +-> AFI / SAFI [ per-AFI overrides ] 298 +-> neighbor 299 +-> [ per-neighbor overrides ] 300 +-> AFI / SAFI [ per-AFI overrides ] 301 +-> neighbor 302 +-> [ neighbor config ] 303 +-> AFI / SAFI [ per-AFI overrides ]"; 305 revision "2014-09-30" { 306 description 307 "Initial revision"; 308 reference "TBD"; 309 } 311 typedef peer-type { 312 type enumeration { 313 enum INTERNAL { 314 description "internal (iBGP) peer"; 315 } 316 enum EXTERNAL { 317 description "external (eBGP) peer"; 318 } 319 } 320 description 321 "labels a peer or peer group as explicitly internal or 322 external"; 323 } 325 typedef remove-private-as-option { 326 type enumeration { 327 enum ALL { 328 description "remove all private ASes in the path"; 329 } 330 enum REPLACE { 331 description "replace private ASes with local AS"; 332 } 333 } 334 description 335 "set of options for configuring how private AS path numbers 336 are removed from advertisements"; 337 } 339 typedef percentage { 340 type uint8 { 341 range "0..100"; 342 } 343 description 344 "Integer indicating a percentage value"; 345 } 347 typedef rr-cluster-id-type { 348 type union { 349 type uint32; 350 type inet:ipv4-address; 351 } 352 description 353 "union type for route reflector cluster ids: 354 option 1: 4-byte number 355 option 2: IP address"; 356 } 358 grouping bgp-common-configuration { 359 description "Common configuration available at all hierarchy 360 levels, global, AFI, groups, neighbors, etc."; 362 leaf description { 363 type string; 364 description 365 "An optional textual description (intended primarily for use 366 with a peer or group"; 367 } 369 container route-selection-options { 370 // TODO: consider moving this container to AFI/SAFI level 371 // config 372 description 373 "Set of configuration options that govern best 374 path selection."; 376 leaf always-compare-med { 377 type boolean; 378 default "false"; 379 description 380 "Compare multi-exit discriminator (MED) value from 381 different ASes when selecting the best route. The 382 default behavior is to only compare MEDs for paths 383 received from the same AS."; 384 } 386 leaf ignore-as-path-length { 387 type boolean; 388 default "false"; 389 description 390 "Ignore the AS path length when selecting the best path. 391 The default is to use the AS path length and prefer paths 392 with shorter length."; 393 } 395 leaf external-compare-router-id { 396 type boolean; 397 default "true"; 398 description 399 "When comparing similar routes received from external 400 BGP peers, use the router-id as a criterion to select 401 the active path."; 402 } 404 leaf advertise-inactive-routes { 405 type boolean; 406 default "false"; 407 description 408 "Advertise inactive routes to external peers. The 409 default is to only advertise active routes."; 410 } 412 leaf enable-aigp { 413 type empty; 414 description 415 "Flag to enable sending / receiving accumulated IGP 416 attribute in routing updates"; 417 } 418 } 420 container use-multiple-paths { 422 presence 423 "Presence of this container indicates that multipath 424 is enabled for both eBGP and iBGP, absence indicates 425 that multi-path is not used"; 427 description 428 "Configuration of BGP multi-path for iBGP and eBGP"; 430 container ebgp { 431 description 432 "Configuration of BGP multipath to enable load sharing 433 across multiple paths to eBGP peers"; 435 leaf allow-multiple-as { 436 type boolean; 437 default "false"; 438 description 439 "Allow multipath to use paths from different neighbouring 440 ASes. The default is to only consider multiple paths from 441 the same neighbouring AS."; 442 } 444 leaf maximum-paths { 445 type uint32; 446 default 1; 447 description 448 "Maximum number of parallel paths to consider when using 449 BGP multipath. The default is use a single path."; 450 } 451 } 453 container ibgp { 454 description 455 "Configuration of BGP multipath to enable load-sharing 456 across multiple paths to iBGP peers"; 458 leaf maximum-paths { 459 type uint32; 460 default 1; 461 description 462 "Maximum number of parallel paths to consider when using 463 iBGP multipath. The default is to use a single path"; 464 } 465 } 467 container eibgp { 468 description 469 "Configuration of BGP multipath to enable load-sharing 470 across multiple paths to external confederation sub-ASes"; 472 leaf maximum-paths { 473 type uint32; 474 default 1; 475 description 476 "Maximum number of parallel paths to consider when using 477 eiBGP multipath. The default is to use a single path"; 478 } 480 } 481 } 483 container graceful-restart { 484 // TODO: most impls seem to require this at the global level 485 // in order to specify at neighbor or other levels 486 presence "Presence of this item indicates that BGP graceful 487 restart is enabled."; 489 description 490 "Configures BGP graceful restart, which is a negotiated 491 option that indicates that a BGP speaker is able to retain 492 forwarding state when a BGP session restarts"; 494 reference "RFC 4724: Graceful Restart Mechanism for BGP"; 496 leaf restart-time { 497 type uint16 { 498 range 0..4096; 499 } 500 description 501 "Estimated time in seconds for the BGP session to be 502 re-established after a restart. This is a 12-bit value 503 advertised by the router to peers. Per RFC 4724, the 504 suggested default value is <= the hold-time value"; 505 } 507 leaf stale-routes-time { 508 type decimal64 { 509 fraction-digits 2; 510 } 511 description 512 "Sets an upper bound on the time in seconds that stale 513 routes will be retained by the router after a session is 514 restarted"; 515 } 516 } 518 uses bgp-pol:apply-policy-group; 520 } 522 grouping bgp-global-configuration { 523 description 524 "Grouping for global level configuration items"; 526 leaf as { 527 type inet:as-number; 528 mandatory "true"; 529 description 530 "Local autonomous system number of the router. Uses 531 the 32-bit as-number type from the model in RFC 6991"; 532 } 533 leaf router-id { 534 type inet:ipv4-address; 535 description 536 "Router id of the router, expressed as an 537 32-bit value, IPv4 address."; 538 } 540 container default-route-distance { 541 description 542 "Administrative distance (or preference) assigned to 543 routes received from different sources 544 (external, internal, and local)."; 545 leaf external-route-distance { 546 type uint8 { 547 range "1..255"; 548 } 549 description 550 "Administrative distance for routes learned from external 551 BGP (eBGP)."; 552 } 553 leaf internal-route-distance { 554 type uint8 { 555 range "1..255"; 556 } 557 description 558 "Administrative distance for routes learned from internal 559 BGP (iBGP)."; 560 } 561 } 563 container confederation { 565 presence "Presence of this node indicates that the local AS 566 is part of a confederation"; 568 description 569 "Configuration for a BGP confederation consisting of a 570 confed id and member sub-AS list"; 572 leaf identifier { 573 type inet:as-number; 574 description 575 "Confederation identifier for the autonomous system"; 576 } 578 leaf-list member-as { 579 type inet:as-number; 580 description 581 "Remote autonomous systems that are to be treated 582 as part of the local confederation."; 583 } 584 } 586 } 588 grouping bgp-group-common-configuration { 589 description "Configuration items that are applied at the peer 590 group level"; 592 // currently a placeholder in case we identify config that is 593 // really only applicable at the group level 594 } 596 grouping bgp-group-neighbor-common-configuration { 597 description "Configuration items that are applied at the peer 598 or peer group levels"; 600 leaf auth-password { 601 type string; 602 description 603 "Configures an MD5 authentication password for use with 604 neighboring devices."; 605 } 607 leaf peer-type { 608 type peer-type; 609 description 610 "Explicitly designate the peer or peer group as internal 611 (iBGP) or external (eBGP)."; 612 } 614 container timers { 615 description "Configuration of various BGP timers"; 616 leaf connect-retry { 617 type decimal64 { 618 fraction-digits 2; 619 } 620 default 30; 621 description 622 "Time interval in seconds between attempts to establish a 623 session with the peer."; 624 } 626 leaf hold-time { 627 type decimal64 { 628 fraction-digits 2; 629 } 630 default 90; 631 description 632 "Time interval in seconds that a BGP session will be 633 considered active in the absence of keepalive or other 634 messages from the peer. The hold-time is typically 635 set to 3x the keepalive-interval."; 636 reference 637 "RFC 4271 - A Border Gateway Protocol 4, Sec. 10"; 638 } 640 leaf keepalive-interval { 641 type decimal64 { 642 fraction-digits 2; 643 } 644 default 30; 645 description 646 "Time interval in seconds between transmission of keepalive 647 messages to the neighbor. Typically set to 1/3 the 648 hold-time."; 649 } 651 leaf minimum-advertisement-interval { 652 type decimal64 { 653 fraction-digits 2; 654 } 655 default 30; 656 description 657 "Mininum time interval in seconds between transmission 658 of BGP updates to neighbors"; 659 reference 660 "RFC 4271 - A Border Gateway Protocol 4, Sec 10"; 661 } 663 leaf send-update-delay { 664 type decimal64 { 665 fraction-digits 2; 666 } 667 description 668 "Time interval between routes changing in the routing 669 table and corresponding updates sent to neighbors -- 670 serves to batch updates"; 671 } 673 } 675 container ebgp-multihop { 676 description 677 "Configure multihop BGP for peers that are not directly 678 connected"; 680 leaf multihop-ttl { 681 type uint8; 682 default 1; 683 description 684 "Time-to-live for multihop BGP sessions. The default 685 value of 1 is for directly connected peers (i.e., 686 multihop disabled"; 688 } 690 } 692 container route-reflector { 693 description 694 "Configure the local router as a route-reflector 695 server"; 697 leaf route-reflector-cluster-id { 698 type rr-cluster-id-type; 699 description 700 "route-reflector cluster id to use when local router is 701 configured as a route reflector. Commonly set at the group 702 level, but allows a different cluster 703 id to be set for each neighbor."; 704 } 706 leaf route-reflector-client { 707 type boolean; 708 default "false"; 709 description 710 "Configure the neighbor as a route reflector client."; 711 } 713 } 715 leaf remove-private-as { 716 // could also make this a container with a flag to enable 717 // remove-private and separate option. here, option implies 718 // remove-private is enabled. 719 type remove-private-as-option; 720 description 721 "Remove private AS numbers from updates sent to peers."; 722 } 724 container bgp-logging-options { 725 description 726 "Configure various tracing/logging options for BGP peers 727 or groups. Expected that additional vendor-specific log 728 options would augment this container."; 730 leaf log-neighbor-state-changes { 731 type boolean; 732 default "true"; 733 description 734 "Configure logging of peer state changes. Default is 735 to enable logging of peer state changes."; 736 } 737 } 739 container transport-options { 740 description 741 "Transport protocol options for BGP sessions"; 743 leaf tcp-mss { 744 type uint16; 745 description 746 "Sets the max segment size for BGP TCP sessions."; 747 } 749 leaf mtu-discovery { 750 type boolean; 751 description 752 "Turns path mtu discovery for BGP TCP sessions on (true) 753 or off (false)"; 754 } 756 leaf passive-mode { 757 type boolean; 758 description 759 "Wait for peers to issue requests to open a BGP session, 760 rather than initiating sessions from the local router."; 762 } 763 } 765 leaf local-address { 766 type inet:ip-address; 767 description 768 "Set the local IP (either IPv4 or IPv6) address to use for 769 the session when sending BGP update messages."; 770 } 772 leaf route-flap-damping { 773 type boolean; 774 description 775 "Enable route flap damping."; 776 } 777 } 779 grouping bgp-neighbor-configuration { 780 description 781 "Neighbor-level configuration items"; 783 list neighbor { 784 key "neighbor-address"; 785 description 786 "List of BGP peers, uniquely identified by neighbor 787 address."; 788 leaf neighbor-address { 789 type inet:ip-address; 790 description 791 "Address of the BGP peer, either IPv4 or IPv6."; 792 } 794 leaf peer-as { 795 type inet:as-number; 796 mandatory "true"; 797 description 798 "AS number of the peer."; 800 } 801 uses bgp-common-configuration; 802 uses bgp-mp:address-family-configuration; 803 uses bgp-group-neighbor-common-configuration; 804 uses bgp-op:bgp-op-neighbor-group; 805 } 806 } 808 container bgp { 809 description "Top-level configuration data for the BGP router"; 811 container global { 812 description 813 "Top-level bgp protocol options applied at the global level 814 in the hierarchy -- these apply across peer-groups, 815 neighbors, and address families"; 817 uses bgp-global-configuration; 819 // attach global level operational data 820 uses bgp-op:bgp-op-global-group; 821 } 823 // top level AF configuration 824 uses bgp-mp:address-family-configuration; 826 list peer-group { 827 key "group-name"; 828 description 829 "List of peer-groups, uniquely identified by the peer group 830 name."; 831 leaf group-name { 832 type string; 833 description "Name of the peer group."; 834 } 835 uses bgp-op:bgp-op-peergroup-group; 836 uses bgp-common-configuration; 837 uses bgp-mp:address-family-configuration; 838 uses bgp-group-neighbor-common-configuration; 840 // list of configurations for neighbors in this peer group 841 uses bgp-neighbor-configuration; 842 } 844 // top level neighbor configuration 845 uses bgp-neighbor-configuration; 847 // hook for top-level policy definitions 848 uses bgp-pol:policy-definition-group; 849 } 850 } 851 853 5.2. BGP policy model 855 file bgp-policy.yang 856 module bgp-policy { 858 yang-version "1"; 860 // namespace 861 // TODO: change to an ietf or other generic namespace 862 namespace "http://google.com/yang/google-bgp-policy-cfg"; 864 prefix "bgp-policy"; 866 // import some basic types 867 import ietf-inet-types { prefix inet; } 869 // meta 870 // TODO: add collaborating organizations 871 organization 872 "Google, AT&T, BT, Microsoft"; 874 contact 875 "Google, Inc. 876 1600 Amphitheatre Way 877 Mountain View, CA 94043 879 AT&T Labs 880 200 S. Laurel Avenue 881 Middletown, NJ 07748 883 BT 884 pp. C3L, BT Centre 885 81, Newgate Street 886 London EC1A 7AJ 887 UK 889 Microsoft 890 205 108th Ave. NE, Suite 400 891 Bellevue, WA 98004"; 893 description 894 "This module describes a YANG model for BGP policy 895 configuration. It is a limited subset of all of the policy 896 configuration parameters available in the variety of vendor 897 implementations, but supports widely used constructs for managing 898 how BGP routes are imported, exported, and modified. This module 899 works with the base BGP protocol configuration model defined in 900 google-bgp. 902 Route policy expression: 904 Policies are expressed as a set of top-level policy definitions, 905 each of which consists of a sequence of policy statements. 906 Policy statements are simple condition-action tuples. Conditions 907 may include mutiple match or comparison operations, and similarly 908 actions may be multitude of changes to route attributes and a 909 final disposition of accepting or> rejecting the route. 911 BGP 912 | 913 +->policy 914 +-> policy definitions 915 +-> policy statements 916 +-> conditions 917 +-> [ match conditions / comparison conditions ] 918 +-> actions 919 +-> [ set attribute actions / control-flow actions ] 921 Route policy evaluation: 923 Evaluation of a policy definition is expected to proceed by 924 evaluating the individual policy statements in the specified 925 order. When a condition statement in a policy statement is 926 satisfied, the corresponding action statement is executed. 927 If the action statement has either accept-route or reject-route 928 actions, policy evaluation stops. If the condition is not 929 satisfied, or if the action statement contains goto-next, then 930 evaluation proceeds to the next policy statement. If none of the 931 policy statement conditions are satisfied, then the default 932 action is applied. 934 Policy 'subroutines' are supported by allowing condition 935 statements to reference another policy definition which first 936 applies conditions from the referenced policy before 937 proceeding."; 939 revision "2014-09-30" { 940 description 941 "Initial revision"; 942 reference "TBD"; 943 } 945 // extension statements 946 // feature statements 948 // identity statements 950 identity bgp-attribute-comparison { 951 description 952 "base type for supported comparison operators on route 953 attributes"; 954 } 956 identity attribute-eq { 957 base bgp-attribute-comparison; 958 description "== comparison"; 959 } 961 identity attribute-ge { 962 base bgp-attribute-comparison; 963 description ">= comparison"; 964 } 966 identity attribute-le { 967 base bgp-attribute-comparison; 968 description "<= comparison"; 969 } 971 // typedef statements 973 typedef match-set-options-type { 974 type enumeration { 975 enum ANY { 976 description "match is true if given value matches any member 977 of the defined set"; 978 } 979 enum ALL { 980 description "match is true if each given value matches a 981 member of the defined set"; 982 } 983 enum INVERT { 984 description "match is true if given value does not match any 985 member of the defined set"; 986 } 987 } 988 default ANY; 989 description 990 "Options that govern the behavior of a match statement. The 991 default behavior is ANY, i.e., the given value matches any 992 of the members of the defined set"; 994 } 996 typedef as-path-prepend-option-repeat { 997 type uint32; 998 description 999 "Option for the as-prepend policy action. Prepends the local 1000 AS number repeated n times"; 1001 } 1003 typedef well-known-community-attr { 1004 type enumeration { 1005 enum INTERNET { 1006 description "entire Internet community (0x00000000)"; 1007 } 1008 enum NO_EXPORT { 1009 // value 0xFFFFFF01; 1010 description "no export"; 1011 } 1012 enum NO_ADVERTISE { 1013 description "no advertise (0xFFFFFF02)"; 1014 } 1015 enum NO_EXPORT_SUBCONFED { 1016 description "no export subconfed, equivalent to 1017 local AS (0xFFFFFF03)"; 1018 } 1019 } 1020 description 1021 "Type definition for well-known IETF community attribute 1022 values"; 1023 reference "RFC 1997 - BGP Communities Attribute"; 1024 } 1026 typedef std-community-attr-type { 1027 // TODO: further refine restrictions and allowed patterns 1028 // 4-octet value: 1029 // 2 octets 1030 // 2 octets 1031 type union { 1032 type uint32 { 1033 // per RFC 1997, 0x00000000 - 0x0000FFFF and 0xFFFF0000 - 1034 // 0xFFFFFFFF are reserved 1035 range "65536..4294901759"; // 0x00010000..0xFFFEFFFF 1036 } 1037 type string { 1038 pattern '([0-9]+:[0-9]+)'; 1039 } 1040 } 1041 description 1042 "Type definition for standard commmunity attributes"; 1043 reference "RFC 1997 - BGP Communities Attribute"; 1044 } 1046 typedef ext-community-attr-type { 1047 // TODO: needs more work to make this more precise given the 1048 // variability of extended community attribute specifications 1049 // 8-octet value: 1050 // 2 octects 1051 // 6 octets 1052 type string { 1053 pattern '([0-9\.]+(:[0-9]+)?:[0-9]+)'; 1054 } 1055 description 1056 "Type definition for extended community attributes"; 1057 reference "RFC 4360 - BGP Extended Communities Attribute"; 1058 } 1060 typedef community-regexp-type { 1061 // TODO: needs more work to decide what format these regexps can 1062 // take. 1063 type string; 1064 description 1065 "Type definition for communities specified as regular 1066 expression patterns"; 1067 } 1069 typedef bgp-origin-attr-type { 1070 type enumeration { 1071 enum IGP { 1072 value 0; 1073 description "Origin of the NLRI is internal"; 1074 } 1075 enum EGP { 1076 value 1; 1077 description "Origin of the NLRI is EGP"; 1078 } 1079 enum INCOMPLETE { 1080 value 2; 1081 description "Origin of the NLRI is neither IGP or EGP"; 1082 } 1083 } 1084 description 1085 "Type definition for standard BGP origin attribute"; 1086 reference "RFC 4271 - A Border Gateway Protocol 4 (BGP-4), 1087 Sec 4.3"; 1088 } 1089 typedef set-community-option-type { 1090 type enumeration { 1091 enum ADD { 1092 description "add the specified communities to the existing 1093 community attribute"; 1094 } 1095 enum REMOVE { 1096 description "remove the specified communities from the 1097 existing community attribute"; 1098 } 1099 enum REPLACE { 1100 description "replace the existing community attribute with 1101 the specified communities"; 1102 } 1103 enum NULL { 1104 description "set the community attribute to empty / NULL"; 1105 } 1106 } 1107 description 1108 "Type definition for options when setting the community 1109 attribute in a policy action"; 1110 } 1112 typedef bgp-next-hop-type { 1113 type union { 1114 type inet:ip-address; 1115 type enumeration { 1116 enum SELF { 1117 description "special designation for local router's own 1118 address"; 1119 } 1120 } 1121 } 1122 description "type definition for specifying next-hop in policy 1123 actions"; 1124 } 1126 // grouping statements 1128 grouping defined-sets-definitions { 1129 description 1130 "Data definitions for pre-defined sets of attributes used in 1131 policy match conditions"; 1133 list prefix-set { 1134 key prefix-set-name; 1135 description 1136 "Definitions for prefix sets"; 1138 leaf prefix-set-name { 1139 type string; 1140 description 1141 "name / label of the prefix set -- this is used to 1142 reference the set in match conditions"; 1143 } 1145 list prefix { 1146 key "address masklength masklength-range"; 1147 description 1148 "list of prefix expressions that are part of the set"; 1150 leaf address { 1151 type inet:ip-address; 1152 mandatory true; 1153 description 1154 "address portion of the prefix"; 1155 } 1157 leaf masklength { 1158 type uint8 { 1159 // simple range covers both ipv4 and ipv6 -- 1160 // could separate this into different types 1161 // for IPv4 and IPv6 prefixes 1162 range 1..128; 1163 } 1164 mandatory true; 1165 description 1166 "masklength for the prefix specification"; 1167 } 1169 leaf masklength-range { 1170 type string { 1171 // pattern modeled after ietf-inet-types 1172 pattern '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' 1173 + '(12[0-8]))\.\.' 1174 + '(([0-9])|([1-9][0-9])|(1[0-1][0-9])|' 1175 + '(12[0-8]))'; 1176 } 1177 description 1178 "Defines an optional range for the masklength. Absence 1179 of the masklength-length implies that the prefix has an 1180 exact masklength given by the masklength parameter. 1181 Example: 10.3.192.0/21 through 10.3.192.0/24 would be 1182 expressed as address: 10.3.192.0, masklength: 21, 1183 masklength-range: 21..24"; 1185 } 1186 } 1187 } 1189 list community-set { 1190 key community-set-name; 1191 description 1192 "Definitions for community sets"; 1194 leaf community-set-name { 1195 type string; 1196 mandatory true; 1197 description 1198 "name / label of the community set -- this is used to 1199 reference the set in match conditions"; 1200 } 1202 leaf-list community-members { 1203 type union { 1204 type std-community-attr-type; 1205 type community-regexp-type; 1206 type well-known-community-attr; 1207 } 1208 description 1209 "members of the community set"; 1210 } 1212 } 1214 list ext-community-set { 1215 key ext-community-set-name; 1216 description 1217 "Definitions for extended community sets"; 1219 leaf ext-community-set-name { 1220 type string; 1221 description 1222 "name / label of the extended community set -- this is used 1223 to reference the set in match conditions"; 1224 } 1226 leaf-list ext-community-members { 1227 type union { 1228 type ext-community-attr-type; 1229 // TODO: is regexp support needed for extended communities? 1230 // TODO: is well-known needed for extended communities? 1231 type community-regexp-type; 1232 } 1233 description 1234 "members of the extended community set"; 1235 } 1236 } 1238 list as-path-set { 1239 key as-path-set-name; 1240 description 1241 "Definitions for AS path sets"; 1243 leaf as-path-set-name { 1244 type string; 1245 description 1246 "name of the AS path set -- this is used to reference the 1247 the set in match conditions"; 1248 } 1250 leaf-list as-path-set-members { 1251 // TODO: need to refine typedef for AS path expressions 1252 type string; 1253 description 1254 "AS path expression -- list of ASes in the set"; 1255 } 1257 } 1258 } 1260 grouping condition-set-matches { 1261 description 1262 "Condition statement definitions for checking membership in a 1263 defined set"; 1265 leaf match-community-set { 1266 type leafref { 1267 path "/policy/defined-sets/community-set/community-set-name"; 1268 require-instance true; 1269 } 1270 description 1271 "References a defined community set"; 1272 } 1274 leaf match-ext-community-set { 1275 type leafref { 1276 path "/policy/defined-sets/ext-community-set" 1277 + "/ext-community-set-name"; 1278 } 1279 description "References a defined extended community set"; 1280 } 1281 leaf match-as-path-set { 1282 type leafref { 1283 path "/policy/defined-sets/as-path-set/as-path-set-name"; 1284 } 1285 description "References a defined AS path set"; 1286 } 1288 leaf match-prefix-set { 1289 type leafref { 1290 path "/policy/defined-sets/prefix-set/prefix-set-name"; 1291 } 1292 description "References a defined prefix set"; 1293 } 1295 leaf match-set-options { 1296 type match-set-options-type; 1297 description 1298 "Optional parameter that governs the behavior of the match 1299 operation"; 1300 } 1301 } 1303 grouping condition-attribute-compare-operators { 1304 description "common definitions for comparison operations in 1305 condition statements"; 1307 leaf operator { 1308 type identityref { 1309 base bgp-attribute-comparison; 1310 } 1311 description 1312 "type of comparison to be performed"; 1313 } 1315 leaf value { 1316 type uint32; 1317 description 1318 "value to compare with the community count"; 1319 } 1320 } 1322 grouping condition-attribute-comparisons { 1323 description 1324 "Condition statement definitions for comparing a route 1325 attribute to a specified value"; 1327 leaf med-eq { 1328 type uint32; 1329 description 1330 "Condition to check if the received MED value is equal to 1331 the specified value"; 1332 } 1334 leaf origin-eq { 1335 type bgp-origin-attr-type; 1336 description 1337 "Condition to check if the route origin is equal to the 1338 specified value"; 1339 } 1341 leaf-list next-hop-in { 1342 type inet:ip-address; 1343 description 1344 "List of next hop addresses to check for in the route 1345 update"; 1346 } 1348 leaf local-pref-eq { 1349 type uint32; 1350 // TODO: add support for other comparisons 1351 description 1352 "Condition to check if the local pref attribute is equal to 1353 the specified value"; 1354 } 1356 container community-count { 1358 presence "node is present in the config data to indicate a 1359 community-count condition"; 1361 description 1362 "Value and comparison operations for conditions based on the 1363 number of communities in the route update"; 1365 uses condition-attribute-compare-operators; 1367 } 1369 container as-path-length { 1371 presence "node is present in the config data to indicate a 1372 as-path-length condition"; 1374 description 1375 "Value and comparison operations for conditions based on the 1376 length of the AS path in the route update"; 1378 uses condition-attribute-compare-operators; 1379 } 1381 leaf route-type { 1382 // TODO: verify extent of vendor support for this comparison 1383 type enumeration { 1384 enum INTERNAL { 1385 description "route type is internal"; 1386 } 1387 enum EXTERNAL { 1388 description "route type is external"; 1389 } 1390 } 1391 description 1392 "Condition to check the route type in the route update"; 1393 } 1394 } 1396 grouping set-attribute-actions { 1397 description 1398 "Definitions for base set of policy action statements that 1399 change various attributes of the route"; 1401 container set-as-path-prepend { 1403 presence "node is present in the config data to use the AS 1404 prepend action"; 1405 description 1406 "action to prepend local AS number to the AS-path a 1407 specified number of times"; 1409 leaf repeat-n { 1410 type uint8; 1411 description "number of times to prepend the local AS number"; 1412 } 1413 } 1415 container set-community { 1417 presence "node is present in the config data when set-community 1418 action is used"; 1419 description 1420 "action to set the community attributes of the route, along 1421 with options to modify how the community is modified"; 1423 leaf-list communities { 1424 type union { 1425 type std-community-attr-type; 1426 type well-known-community-attr; 1427 } 1428 description 1429 "community values for the update"; 1430 } 1432 leaf options { 1433 type set-community-option-type; 1434 description 1435 "options for modifying the community attribute with the 1436 specified values"; 1437 } 1438 } 1440 container set-ext-community { 1442 presence "node is present in the config data when set-community 1443 action is used"; 1444 description 1445 "action to set the extended community attributes of the 1446 route, along with options to modify how the community is 1447 modified"; 1449 leaf-list communities { 1450 type union { 1451 type ext-community-attr-type; 1452 type well-known-community-attr; 1453 } 1454 description 1455 "community values for the update"; 1456 } 1458 leaf options { 1459 type set-community-option-type; 1460 description 1461 "options for modifying the community attribute with the 1462 specified values"; 1463 } 1464 } 1466 leaf set-route-origin { 1467 type bgp-origin-attr-type; 1468 description "set the origin attribute to the specified value"; 1469 } 1471 leaf set-local-pref { 1472 type uint32; 1473 description "set the local pref attribute on the route update"; 1475 } 1477 leaf set-next-hop { 1478 type bgp-next-hop-type; 1479 description "set the next-hop attribute in the route update"; 1480 } 1482 leaf set-med { 1483 type uint32; 1484 description "set the med metric attribute in the route update"; 1485 } 1486 } 1488 grouping control-flow-actions { 1489 description 1490 "Definitions for base set of policy action statements that 1491 manage the disposition or control flow of the policy"; 1493 leaf accept-route { 1494 type empty; 1495 description "accepts the route into the routing table"; 1496 } 1498 leaf reject-route { 1499 type empty; 1500 description "rejects the route"; 1501 } 1503 leaf goto-next { 1504 type empty; 1505 description 1506 "proceed to evaluate the next policy statement in the 1507 policy definition"; 1508 } 1510 leaf goto-policy { 1511 type string; 1512 description 1513 "proceed to the named policy definition and continue 1514 evaluating the policy"; 1515 } 1517 } 1519 grouping conditions { 1520 description 1521 "Condition statement definitions for policy statements"; 1523 leaf call-policy { 1524 type string; 1525 description 1526 "Applies the conditions from the specified policy definition 1527 in the current policy statement."; 1528 } 1530 uses condition-set-matches; 1531 uses condition-attribute-comparisons; 1533 } 1535 grouping actions { 1536 description 1537 "Action statement definitions for policy statements"; 1539 uses set-attribute-actions; 1540 uses control-flow-actions; 1542 } 1544 grouping apply-policy-group { 1545 description 1546 "top level configuration for applying policies at various 1547 points in the configuration hierarchy"; 1549 container apply-policy { 1550 description 1551 "Anchor point for policies in the BGP configuration. Import 1552 and export policies are with respect to the local routing 1553 table, i.e., export (send) and import (receive)."; 1555 leaf-list import-policies { 1556 type leafref { 1557 path "/bgp/policy/policy-definitions/policy-definition" 1558 + "/name"; 1559 require-instance true; 1560 } 1561 description 1562 "list of policy names in sequence to be applied on 1563 receiving a routing update in the current context, e.g., 1564 for the current peer group, neighbor, address family, 1565 etc."; 1566 } 1568 leaf-list export-policies { 1569 type leafref { 1570 path "/bgp/policy/policy-definitions/policy-definition" 1571 + "/name"; 1572 require-instance true; 1573 } 1574 description 1575 "list of policy names in sequence to be applied on 1576 sending a routing update in the current context, e.g., 1577 for the current peer group, neighbor, address family, 1578 etc."; 1579 } 1580 } 1581 } 1583 grouping policy-definition-group { 1584 description 1585 "top level set of policy defined sets and policy definitions"; 1587 container policy { 1588 description 1589 "Top level container for BGP policy-related configuration 1590 items"; 1592 container defined-sets { 1593 presence "Container for sets defined for matching in policy 1594 statements"; 1595 description 1596 "Predefined sets of attributes used in policy match 1597 statements"; 1599 uses defined-sets-definitions; 1600 } 1602 container policy-definitions { 1603 presence "Container for the set of policy definitions"; 1604 description 1605 "Top level container for policy definitions"; 1607 list policy-definition { 1608 key name; 1609 ordered-by user; 1610 description 1611 "List of top-level policy definitions, keyed by a unique 1612 name"; 1614 leaf name { 1615 type string; 1616 description 1617 "Name of the top-level policy definition -- this name 1618 is used in references to the current policy"; 1619 } 1621 list statements { 1622 key name; 1623 // TODO: names of policy statements withing a policy defn 1624 // should be optional, however, YANG requires a unique id 1625 // for lists; not sure that a compound key works either; 1626 // need to investigate further. 1627 ordered-by user; 1628 description 1629 "Name of this policy statement"; 1631 leaf name { 1632 type string; 1633 description "name of the policy statement"; 1634 } 1636 container conditions { 1637 description "Condition statements for this 1638 policy statement"; 1640 uses conditions; 1641 } 1643 container actions { 1644 description "Action statements for this policy 1645 statement"; 1647 uses actions; 1648 } 1649 } 1650 } 1651 } 1652 } 1653 } 1655 // augment statements 1657 // rpc statements 1659 // notification statements 1661 } 1662 1664 5.3. BGP multiprotocol model 1666 file bgp-multiprotocol.yang 1667 module bgp-multiprotocol { 1669 yang-version "1"; 1671 // namespace 1672 // TODO: change to an ietf or other more generic namespace 1673 namespace "http://google.com/yang/google-bgp-multiprotocol-cfg"; 1675 prefix "bgp-mp"; 1677 // import some basic inet types 1678 import ietf-inet-types { prefix inet; } 1679 import bgp-policy { prefix bgp-pol; } 1680 import bgp-operational { prefix bgp-op; } 1682 // meta 1683 organization 1684 "Google, AT&T, BT, Microsoft"; 1686 contact 1687 "Google, Inc. 1688 1600 Amphitheatre Way 1689 Mountain View, CA 94043 1691 AT&T Labs 1692 200 S. Laurel Avenue 1693 Middletown, NJ 07748 1695 BT 1696 pp. C3L, BT Centre 1697 81, Newgate Street 1698 London EC1A 7AJ 1699 UK 1701 Microsoft 1702 205 108th Ave. NE, Suite 400 1703 Bellevue, WA 98004"; 1705 description 1706 "This module is part of a YANG model for BGP protocol 1707 configuration, focusing on configuration of multiprotocol 1708 BGP, in particular various relevant address families (AFI) and 1709 sub-address families (SAFI). 1711 Identities (rather than enumerated types) are used to identify 1712 each AFI / SAFI type to make it easier for users to extend to 1713 pre-standard or custom AFI/SAFI types. This module is only 1714 intended to capture the most"; 1716 revision "2014-10-13" { 1717 description 1718 "Initial revision"; 1719 reference "TBD"; 1720 } 1722 // extension statements 1724 // feature statements 1726 // identity statements 1728 identity afi-type { 1729 description 1730 "base identity type for BGP address family identifiers (AFI)"; 1731 reference "RFC 4760 - Multiprotocol Extensions for BGP-4"; 1732 } 1734 identity safi-type { 1735 description 1736 "base identity type for BGP subsequent address family 1737 identifiers (SAFI)"; 1738 reference "RFC 4760 - Multiprotocol Extensions for BGP-4"; 1739 } 1741 identity ipv4-afi { 1742 base bgp-mp:afi-type; 1743 description 1744 "IPv4 AF identifier (AFI = 1)"; 1745 } 1747 identity ipv6-afi { 1748 base bgp-mp:afi-type; 1749 description 1750 "IPv6 AF identifier (AFI = 2)"; 1751 } 1753 identity unicast-safi { 1754 base bgp-mp:safi-type; 1755 description 1756 "unicast SAFI identifier (SAFI = 1)"; 1757 } 1758 identity l3vpn-unicast-safi { 1759 base safi-type; 1760 description 1761 "L3 / MPLS virtual private networks SAFI (SAFI = 128/129)"; 1762 reference "RFC 4364 - BGP/MPLS IP Virtual Private Networks 1763 (VPNs)"; 1764 } 1766 identity labeled-unicast-safi { 1767 base safi-type; 1768 description 1769 "labeled unicast SAFI identifier (SAFI = 4)"; 1770 reference "RFC 3107 - Carrying Label Information in BGP-4"; 1771 } 1773 identity l2vpn-vpls-afi { 1774 base afi-type; 1775 description 1776 "AFI for BGP L2 VPN / VPLS (AFI = 25)"; 1777 reference "RFC 4761 - Virtual Private LAN Service (VPLS) 1778 Using BGP for Auto-Discovery and Signaling"; 1779 } 1781 identity l2vpn-vpls-safi { 1782 base safi-type; 1783 description 1784 "BGP L2 VPN / VPLS service SAFI (SAFI = 65)"; 1785 } 1787 identity multicast-safi { 1788 base safi-type; 1789 description 1790 "multicast SAFI (SAFI = 2)"; 1791 reference "RFC 4760 - Multiprotocol Extensions for BGP-4"; 1792 } 1794 identity multicast-vpn-safi { 1795 base safi-type; 1796 description 1797 "Multicast VPN SAFI (SAFI = 5)"; 1798 reference "RFC 6514 - BGP Encodings and Procedures for Multicast 1799 in MPLS/BGP IP VPNs"; 1800 } 1802 // typedef statements 1804 // TODO: move this and other commonly types to a common bgp-types 1805 // module 1806 typedef percentage { 1807 type uint8 { 1808 range "0..100"; 1809 } 1810 description 1811 "Integer indicating a percentage value"; 1812 } 1814 // grouping statements 1816 grouping address-family-common { 1817 description 1818 "Configuration that is for the address family level, 1819 but applies across AFI/SAFI"; 1821 container prefix-limit { 1822 description 1823 "Configure the maximum number of prefixes that will be 1824 accepted from a peer."; 1826 leaf max-prefixes { 1827 type uint32; 1828 description 1829 "Maximum number of prefixes that will be accepted from 1830 the neighbor."; 1831 } 1833 leaf shutdown-threshold-pct { 1834 type percentage; 1835 description 1836 "Threshold on number of prefixes that can be received 1837 from a neighbor before generation of warning messages 1838 or log entries. Expressed as a percentage of 1839 max-prefixes."; 1840 } 1842 leaf restart-timer { 1843 type decimal64 { 1844 fraction-digits 2; 1845 } 1846 units "seconds"; 1847 description 1848 "Time interval in seconds after which the BGP session 1849 is reestablished after being torn down due to exceeding 1850 the max-prefixes limit."; 1851 } 1852 } 1853 // policies can be applied at a specific AF level 1854 uses bgp-pol:apply-policy-group; 1856 } 1858 grouping ipv4-ipv6-unicast-common { 1859 description 1860 "common configuration for base ipv4 and ipv6 unicast; may 1861 need to be split into separate containers for each of ipv4 1862 and ipv6"; 1864 container ipv4-ipv6-unicast { 1865 // YANG uses XPath 1.0 expression syntax 1866 when "(../../afi-name = 'ipv4-afi' or " + 1867 "../../afi-name = 'ipv6-afi') " + 1868 "and ../safi-name = 'unicast-safi'" { 1869 description 1870 "Include this container for unicast ipv4 or ipv6 1871 AFI-specific configuration"; 1872 } 1873 description "ipv4 unicast config items"; 1875 leaf send-default-route { 1876 // TODO: consider moving this to policy 1877 type boolean; 1878 default "false"; 1879 description "if set to true, send the default route, i.e., 1880 0.0.0.0/0 to the neighbor(s)"; 1881 } 1882 } 1883 } 1885 grouping ipv4-l3vpn-unicast-group { 1886 description 1887 "configuration group for L3 VPN VRFs for IPv4"; 1889 container ipv4-l3vpn-unicast { 1890 when "../../afi-name = 'bgp-mp:ipv4-afi' and " + 1891 "../safi-name = 'l3vpn-unicast-safi'" { 1892 description 1893 "Include this container when AFI = ipv4 and 1894 SAFI = l3vpn-unicast"; 1895 } 1896 description "ipv4 l3vpn config items"; 1897 list vrfs { 1898 key name; 1899 description "list of configured VRFs"; 1901 leaf name { 1902 type string; 1903 description "name / identifier of the VRF"; 1904 } 1906 leaf route-distinguisher { 1907 // TODO: consider expanding to a union type to make it more 1908 // convenient to express as AS:addr or other common formats 1909 type uint64; 1910 description 1911 "route distinguisher value assigned to this VRF"; 1912 } 1914 uses bgp-pol:apply-policy-group; 1916 /* additional leafs to consider --- should these be in BGP? 1917 interface-name 1918 retain-local-label-size 1919 advertise-best-external 1920 no-synchronization 1921 */ 1923 } 1924 } 1925 } 1927 grouping ipv6-l3vpn-unicast-group { 1928 description 1929 "configuration group for L3 VPN VRFs for IPv6"; 1931 container ipv6-l3vpn-unicast { 1932 when "../../afi-name = 'bgp-mp:ipv6-afi' and " + 1933 "../safi-name = 'l3vpn-unicast-safi'" { 1934 description 1935 "Include this container only when AFI = ipv6 and 1936 SAFI = l3vpn-unicast"; 1937 } 1938 description "ipv6 l3vpn config items"; 1939 } 1940 } 1942 grouping ipv4-labeled-unicast-group { 1943 description 1944 "configuration group for IPv4 labeled unicast"; 1946 container ipv4-labeled-unicast { 1947 when "../../afi-name = 'ipv4-afi' and " + 1948 "../safi-name = 'labeled-unicast-safi'" { 1949 description 1950 "Include this container when AFI = ipv4 and 1951 SAFI = labeled-unicast"; 1952 } 1953 description "ipv4 labeled unicast config items"; 1954 } 1955 } 1957 grouping l2vpn-group { 1958 description 1959 "configuration group for L2 VPN"; 1961 container l2vpn { 1962 // TODO: confirm that both AFI/SAFI values are set 1963 // for L2 VPNs 1964 when "../../afi-name = 'l2vpn-vpls-afi' and " + 1965 "../safi-name = 'l2vpn-vpls-safi'" { 1966 description 1967 "Include this container when AFI = l2vpn-vpls and 1968 SAFI = l2vpn-vpls"; 1969 } 1970 description "l2vpn config items"; 1971 } 1972 } 1974 grouping ipv4-multicast-vpn-group { 1975 description 1976 "configuration group for IPv4 multicast VPNs"; 1978 container ipv4-multicast-vpn { 1979 when "../../afi-name = 'ipv4-afi' and " + 1980 "../safi-name = 'multicast-vpn-safi'" { 1981 description 1982 "Include this container when AFI = ipv4 and 1983 SAFI = multicast-vpn"; 1984 } 1985 description "ipv4 multicast vpn config items"; 1986 } 1987 } 1989 grouping ipv6-multicast-vpn-group { 1990 description 1991 "configuration group for IPv6 multicast VPNs"; 1993 container ipv6-multicast-vpn { 1994 when "../../afi-name = 'ipv6-afi' and " + 1995 "../safi-name = 'multicast-vpn-safi'" { 1996 description 1997 "Include this container when AFI = ipv6 and 1998 SAFI = multicast-vpn"; 1999 } 2000 description "ipv6 multicast vpn config items"; 2001 } 2002 } 2004 grouping address-family-configuration { 2005 description "Configuration options that are applied at the 2006 address family level."; 2008 list afi { 2010 key "afi-name"; 2011 description 2012 "Per address-family configuration, uniquely identified by AF 2013 name."; 2014 leaf afi-name { 2015 type identityref { 2016 base "afi-type"; 2017 } 2018 description 2019 "Address family names are drawn from the afi-type base 2020 identity, which has specific address family types as 2021 derived identities."; 2022 } 2024 list safi { 2025 key "safi-name"; 2026 description 2027 "Per subsequent address family configuration, under a 2028 specific address family."; 2030 leaf safi-name { 2031 type identityref { 2032 base "safi-type"; 2033 } 2034 description 2035 "Within each address family, subsequent address family 2036 names are drawn from the subsequent-address-family base 2037 identity."; 2038 } 2040 // these grouping references conditionally add config nodes 2041 // that are specific to each AFI / SAFI combination 2042 uses ipv4-ipv6-unicast-common; 2043 uses ipv4-l3vpn-unicast-group; 2044 uses ipv6-l3vpn-unicast-group; 2045 uses ipv4-labeled-unicast-group; 2046 uses l2vpn-group; 2047 uses ipv4-multicast-vpn-group; 2048 uses ipv6-multicast-vpn-group; 2050 // this grouping pulls in the config items common across 2051 // AF/SAFI combinations 2052 uses address-family-common; 2054 } 2055 // operational state common acrossr address families 2056 uses bgp-op:bgp-op-af-group; 2057 } 2058 } 2060 // data definition statements 2062 // augment statements 2064 // rpc statements 2066 // notification statements 2068 } 2069 2071 5.4. BGP operational data model 2073 file bgp-operational.yang 2074 module bgp-operational { 2076 yang-version "1"; 2078 // namespace 2079 // TODO: change to an ietf or other more generic namespace 2080 namespace "http://google.com/yang/google-bgp-operational"; 2082 prefix "bgp-op"; 2084 // import some basic inet types 2085 import ietf-inet-types { prefix inet; } 2086 // meta 2088 organization 2089 "Google, AT&T, BT, Microsoft"; 2091 contact 2092 "Google, Inc. 2093 1600 Amphitheatre Way 2094 Mountain View, CA 94043 2096 AT&T Labs 2097 200 S. Laurel Avenue 2098 Middletown, NJ 07748 2100 BT 2101 pp. C3L, BT Centre 2102 81, Newgate Street 2103 London EC1A 7AJ 2104 UK 2106 Microsoft 2107 205 108th Ave. NE, Suite 400 2108 Bellevue, WA 98004"; 2110 description 2111 "This module is part of a YANG model for BGP protocol 2112 configuration, focusing on operational data (i.e., state 2113 variables) related to BGP operations"; 2115 revision "2014-10-13" { 2116 description 2117 "Initial revision"; 2118 reference "TBD"; 2119 } 2121 // extension statements 2123 // feature statements 2125 // identity statements 2127 // typedef statements 2129 // grouping statements 2131 grouping bgp-op-global-group { 2132 description 2133 "top level container for operational state data"; 2135 container bgp-global-state { 2136 config false; 2137 description 2138 "data definitions for operational state variables related 2139 to the global BGP instance"; 2140 } 2141 } 2143 grouping bgp-op-af-group { 2144 description 2145 "top level container for operational state data"; 2147 container bgp-af-common-state { 2148 config false; 2149 description 2150 "data definitions for operational state variables related 2151 to all BGP address families instance"; 2152 } 2153 } 2155 grouping bgp-op-peergroup-group { 2156 description 2157 "top level container for operational state data"; 2159 container bgp-group-common-state { 2160 config false; 2161 description 2162 "data definitions for operational state variables related 2163 to BGP peer groups"; 2164 } 2165 } 2167 grouping bgp-op-neighbor-group { 2168 description 2169 "top level container for operational state data"; 2171 container bgp-neighbor-common-state { 2172 config false; 2173 description 2174 "data definitions for operational state variables related 2175 to BGP neighbor sesions"; 2176 } 2177 } 2179 // data definition statements 2180 // augment statements 2182 // rpc statements 2184 // notification statements 2185 } 2186 2188 6. References 2190 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2191 Network Configuration Protocol (NETCONF)", RFC 6020, 2192 October 2014. 2194 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 2195 Protocol 4 (BGP-4)", RFC 4271, January 2006. 2197 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2198 "Multiprotocol Extensions for BGP-4", RFC 4760, January 2199 2007. 2201 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 2202 July 2013. 2204 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2205 2004. 2207 Appendix A. Acknowledgements 2209 The authors are grateful for valuable contributions to this document 2210 and the associated models from: Chris Chase, Ed Crabbe, Josh George, 2211 Vijay Gill, Ina Minei, Ashok Narayanan, Steve Padgett, Puneet Sood, 2212 and Jim Uttaro. 2214 Authors' Addresses 2216 Anees Shaikh 2217 Google 2218 1600 Amphitheatre Pkwy 2219 Mountain View, CA 94043 2220 US 2222 Email: aashaikh@google.com 2223 Kevin D'Souza 2224 AT&T 2225 200 S. Laurel Ave 2226 Middletown, NJ 2227 US 2229 Email: kd6913@att.com 2231 Deepak Bansal 2232 Microsoft 2233 205 108th Ave. NE, Suite 400 2234 Bellevue, WA 2235 US 2237 Email: dbansal@microsoft.com 2239 Rob Shakir 2240 BT 2241 pp. C3L, BT Centre 2242 81, Newgate Street 2243 London EC1A 7AJ 2244 UK 2246 Email: rob.shakir@bt.com 2247 URI: http://www.bt.com/