idnits 2.17.1 draft-ietf-netmod-routing-cfg-01.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance 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 -- The document date (September 23, 2011) is 4598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFN' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-02 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-ip-cfg-00 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD L. Lhotka 3 Internet-Draft CESNET 4 Intended status: Standards Track September 23, 2011 5 Expires: March 26, 2012 7 A YANG Data Model for Routing Configuration 8 draft-ietf-netmod-routing-cfg-01 10 Abstract 12 This document contains a specification of three YANG modules that 13 together provide a data model for essential configuration of a 14 routing subsystem. It is expected that this module will serve as a 15 basis for further development of data models for individual routing 16 protocols and other related functions. The present data model 17 defines the common building blocks for such configurations - router 18 instances, routes, routing tables, routing protocols and route 19 filters. 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 March 26, 2012. 38 Copyright Notice 40 Copyright (c) 2011 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 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 57 2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 4 58 2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5 59 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. The Design of the Core Routing Data Model . . . . . . . . . . 7 61 4.1. Router . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 11 64 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 12 65 4.4.1. Defining New Routing Protocols . . . . . . . . . . . . 13 66 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 15 67 4.6. RPC Operation . . . . . . . . . . . . . . . . . . . . . . 16 68 5. IANA AFN and SAFI YANG Module . . . . . . . . . . . . . . . . 17 69 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 25 70 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 34 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 75 11.1. Normative References . . . . . . . . . . . . . . . . . . . 42 76 11.2. Informative References . . . . . . . . . . . . . . . . . . 42 77 Appendix A. Example - Adding a New Routing Protocol . . . . . . . 43 78 A.1. Example YANG Module for Routing Information 79 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 43 80 A.2. Sample Reply to the NETCONF Message . . . . . . . . 45 81 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50 82 B.1. Changes Between Versions -00 and -01 . . . . . . . . . . . 50 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 51 85 1. Introduction 87 This document contains an initial specification of three YANG 88 modules: 90 o Module "ietf-routing" provides generic components of a routing 91 data model. 93 o Module "ietf-ipv4-unicast-routing" augments the "ietf-routing" 94 module with additional data specific to IPv4 unicast. 96 o Module "iana-afn-safi" contains two type definitions translating 97 IANA registries "Address Family Numbers" [IANA-AFN] and 98 "Subsequent Address Family Identifiers" [IANA-SAFI] to YANG 99 enumerations. 101 ED. QUESTION: Would it be possible/useful to publish the "iana-afn- 102 safi" module as a separate I-D, perhaps together with "iana-if-type"? 104 The first two modules together define the so-called core routing data 105 model. This data model will serve as a basis for the development of 106 data models for more sophisticated routing configurations. While 107 these two modules can be directly used for simple IPv4-only devices 108 with static routing, their main purpose is to provide essential 109 building blocks for more complicated setups involving other address 110 families such as IPv6, multicast routing, multiple routing protocols, 111 and advanced functions such as route filtering or policy routing. To 112 this end, it is expected that this module will be augmented by 113 numerous modules developed by other IETF working groups. 115 2. Terminology and Notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 The following terms are defined in [RFC6241]: 123 o client 125 o message 127 o operation 129 o server 131 The following terms are defined in [RFC6020]: 133 o augment 135 o configuration data 137 o container 139 o data model 141 o data node 143 o data type 145 o identity 147 o mandatory node 149 o module 151 o operational state data 153 o prefix 155 o RPC operation 157 2.1. Glossary of New Terms 158 active route: a route which is actually used for packet forwarding. 159 If there are multiple candidate routes with a matching destination 160 prefix, then it is up to the routing algorithm to select the 161 active route. 163 core routing data model: YANG data model resulting from the 164 combination of "ietf-routing" and "ietf-ipv4-unicast-routing-cfg" 165 modules. 167 2.2. Prefixes in Data Node Names 169 In this document, names of data nodes are used mostly without a 170 prefix, as long as it is clear from the context in which YANG module 171 each name is defined. Otherwise, names are prefixed with their 172 standard prefix associated with the corresponding YANG module, as 173 shown in Table 1. 175 +--------+---------------------------+------------+ 176 | Prefix | YANG module | Reference | 177 +--------+---------------------------+------------+ 178 | eth | ex-ethernet | [YANG-IF] | 179 | | | | 180 | if | ietf-interfaces | [YANG-IF] | 181 | | | | 182 | inet | ietf-inet-types | [RFC6021] | 183 | | | | 184 | ip | ietf-ip | [YANG-IP] | 185 | | | | 186 | rip | example-rip | Appendix A | 187 | | | | 188 | rt | ietf-routing | Section 6 | 189 | | | | 190 | v4ur | ietf-ipv4-unicast-routing | Section 7 | 191 | | | | 192 | yang | ietf-yang-types | [RFC6021] | 193 +--------+---------------------------+------------+ 195 Table 1: Prefixes and corresponding YANG modules 197 3. Objectives 199 The initial design of the core routing data model was driven by the 200 following objectives: 202 o The data model should be suitable for the common address families, 203 in particular IPv4 and IPv6, and for unicast and multicast 204 routing, as well as Multiprotocol Label Switching (MPLS). 206 o Simple routing setups, such as static routing, should be 207 configurable in a simple way, ideally without any need to develop 208 additional YANG modules. 210 o On the other hand, the core routing framework must allow for 211 complicated setups involving multiple routing tables and multiple 212 routing protocols, as well as controlled redistributions of 213 routing information. 215 o Device vendors will want to map the data models built on this 216 generic framework to their proprietary data models and 217 configuration interfaces. Therefore, the framework should be 218 flexible enough to facilitate such a mapping and accommodate data 219 models with different logic. 221 4. The Design of the Core Routing Data Model 223 The core routing data model consists of two YANG modules. The first 224 module, "ietf-routing", defines the generic components of a routing 225 system. The second module, "ietf-ipv4-unicast-routing", augments the 226 "ietf-routing" module with new data nodes that are needed for IPv4 227 unicast routing. 229 The combined data hierarchy defined by both YANG modules is shown in 230 Figure 1. 232 +--rw routing 233 +--rw router [name] 234 +--rw name 235 +--rw description? 236 +--rw enabled? 237 +--rw routing-protocols 238 | +--rw routing-protocol [name] 239 | +--rw name 240 | +--rw description? 241 | +--rw type 242 | +--rw connected-routing-tables 243 | | +--rw connected-routing-table [name] 244 | | +--rw name 245 | | +--rw import-filter? 246 | | +--rw export-filter? 247 | +--rw v4ur:ipv4-unicast-static-routes 248 | +--rw v4ur:static-route [id] 249 | +--rw v4ur:id 250 | +--rw v4ur:description? 251 | +--rw v4ur:destination-prefix? 252 | +--rw v4ur:next-hop? 253 | +--rw v4ur:outgoing-interface? 254 +--rw route-filters 255 | +--rw route-filter [name] 256 | +--rw name 257 | +--rw description? 258 | +--rw type? 259 +--rw routing-tables 260 +--rw routing-table [name] 261 +--rw name 262 +--rw address-family? 263 +--rw safi? 264 +--rw description? 265 +--ro routes 266 | +--ro route 267 | +--ro source-protocol? 268 | +--ro last-modified? 269 | +--ro v4ur:destination-prefix? 270 | +--ro v4ur:next-hop? 271 | +--ro v4ur:outgoing-interface? 272 +--rw recipient-routing-tables [recipient-name] 273 +--rw recipient-name 274 +--rw filter? 276 Figure 1: Data hierarchy of "ietf-routing" and "ietf-ipv4-unicast- 277 routing" modules. 279 As can be see from Figure 1, the core routing data model introduces 280 several generic components of a routing framework: routers, routing 281 tables containing routes, routing protocols, route filters and RPC 282 operations. The following subsections provide further details about 283 these components. 285 By combining the components in various ways, and possibly augmenting 286 them with appropriate contents defined in other modules, various 287 routing setups can be realized. 289 +------------+ 290 | FIB | 291 +------------+ 292 ^ 293 | 294 +---+ 295 | F | 296 +---+ 297 ^ 298 +--------+ | 299 | direct | +---+ +--------------+ +---+ +--------------+ 300 | routes |--->| F |--->| |<---| F |<---| | 301 +--------+ +---+ | main | +---+ | additional | 302 | routing | | routing | 303 +--------+ +---+ | table | +---+ | table | 304 | static |--->| F |--->| |--->| F |--->| | 305 | routes | +---+ +--------------+ +---+ +--------------+ 306 +--------+ ^ | ^ | 307 | v | v 308 +---+ +---+ +---+ +---+ 309 | F | | F | | F | | F | 310 +---+ +---+ +---+ +---+ 311 ^ | ^ | 312 | v | v 313 +----------+ +----------+ 314 | routing | | routing | 315 | protocol | | protocol | 316 +----------+ +----------+ 318 Figure 2: Example setup of the routing subsystem 320 Figure 2 shows an example of a more complicated setup. Several of 321 its features are worth mentioning: 323 o Along with the main routing table, which must always be present, 324 an additional routing table is configured. 326 o Each routing protocol instance, including the "static" and 327 "direct" pseudo-protocols, is connected to exactly one routing 328 table with which it can exchange routes (in both directions, 329 except for the "static" and "direct" pseudo-protocols). 331 o Routing tables may also be connected to each other and exchange 332 routes in one or both directions. 334 o The forwarding information base (FIB) is a special routing table 335 which must always be present. Typically, the FIB receives the 336 active routes from the main routing table and the operating system 337 kernel uses this information for packet forwarding. 339 o Route exchanges along all connections may be controlled by means 340 of route filters, denoted by "F" in Figure 2. 342 4.1. Router 344 Each router instance in the core routing data model represents a 345 (virtual) router whose configuration and operation is independent of 346 other router instances. Although it it not enforced by the data 347 model, different router instances normally do not internally share 348 any data. They may, however, communicate with each other via routing 349 protocols. 351 4.2. Route 353 Routes are basic units of information in a routing system. The core 354 routing data model defines only the following minimal set of route 355 attributes: 357 o destination-prefix - IP prefix specifying the set of destination 358 addresses for which the route may be used. This attribute is 359 mandatory. 361 o next-hop - IP address of the adjacent router or host to which 362 packets with destination addresses belonging to destination-prefix 363 should be sent. 365 o outgoing-interface - network interface that should be used for 366 sending packets with destination addresses belonging to 367 destination-prefix. 369 The above list of route attributes is sufficient for a simple static 370 routing configuration. It is expected that future modules defining 371 routing protocols will add other route attributes such as metrics or 372 preferences. 374 Routes and their attributes are used in both configuration data, for 375 example as manually configured static routes, and in operational 376 state data, for example as entries in routing tables. 378 4.3. Routing Tables 380 Routing tables are lists of routes complemented with administrative 381 data, namely: 383 o source-protocol - name of the routing protocol from which the 384 route was originally obtained. 386 o last-modified - date and time of last modification, or 387 installation, of the route. 389 In the core routing data model, the contents of routing tables (list 390 of routes) are defined as operational state data. Routing protocol 391 operations result in route additions, removals and modifications. 392 This also includes manipulations via the "static" pseudo-protocol. 394 At least the following two routing tables MUST be configured for each 395 router instance: 397 1. Forwarding information base (FIB) contains active routes that are 398 used by the operating system kernel for forwarding datagrams. 400 2. Main routing table to which all routing protocol instances are 401 connected by default. 403 The main routing table SHOULD serve as the source of active routes 404 for the FIB. 406 One or more additional routing tables MAY be configured by creating 407 new entries in the "routing-table" list, either being a part of 408 factory-default configuration or configured by the client. 410 The naming scheme for routing tables, as well as restrictions on the 411 number and configurability of routing tables are implementation- 412 specific. 414 Every routing table can serve as a source of routes for other routing 415 tables. To achieve this, one or more recipient routing tables may be 416 specified in the configuration of the source routing table. In 417 addition, a route filter may be configured for each recipient routing 418 table, which selects and/or manipulates the routes that are passed on 419 between the source and recipient routing table. 421 4.4. Routing Protocols 423 The core routing data model provides an open-ended framework for 424 defining multiple routing protocol instances. Each of them is 425 identified by a name, which MUST be unique within a router instance, 426 and MUST be assigned a type from a selection which includes all 427 routing protocol types supported by the server, such as static, RIP, 428 OSPF or BGP. 430 Each routing protocol instance is connected to exactly one routing 431 table. By default, every routing protocol instance is connected to 432 the main routing table, but any routing protocol instance can be 433 configured to use a different routing table, provided such an extra 434 table exists. 436 Routes learned from the network by a routing protocol are passed to 437 the connected routing table and vice versa - routes appearing in a 438 routing table are passed to all routing protocols connected to the 439 table (except "direct" and "static" pseudo-protocols) and advertised 440 by that protocol to the network. 442 Two independent route filters (see Section 4.5) may be defined for a 443 routing protocol instance to control the exchange of routes in both 444 directions between the routing protocol instance and the connected 445 routing table: 447 o import filter controls which routes are passed from a routing 448 protocol instance to the routing table, 450 o export filter controls which routes the routing protocol instance 451 may receive from the connected routing table. 453 Note that, for historical reasons, the terms import and export are 454 used from the viewpoint of a routing table. 456 The "ietf-routing" module defines two special routing protocols - 457 "direct" and "static". Both are in fact pseudo-protocols, which 458 means that they are confined to the local device and do not exchange 459 any routing information with neighboring routers. Routes from both 460 "direct" and "static" protocol instances are passed to the connected 461 routing table (subject to route filters, if any), but an exchange in 462 the opposite direction is not allowed. 464 Every router instance MUST contain exactly one instance of the 465 "direct" pseudo-protocol. It is the source of routes to directly 466 connected networks (so-called direct routes). Such routes are 467 supplied by the operating system kernel, based on the detected and 468 configured network interfaces, and they usually appear in the main 469 routing table. However, using the framework defined in this 470 document, the target routing table for direct routes can be changed 471 by connecting the "direct" protocol instance to a non-default routing 472 table, and the direct routes can also be filtered before they appear 473 in the routing table. 475 The "static" routing pseudo-protocol allows for specifying routes 476 manually. It MAY be configured in zero or multiple instances, 477 although a typical implementation will have exactly one instance. 479 4.4.1. Defining New Routing Protocols 481 It is expected that future YANG modules will create data models for 482 additional routing protocol types. In order to do so, the new module 483 has to define the protocol-specific information and fit it to the 484 core routing framework in the following way: 486 o A new identity MUST be defined for the routing protocol and its 487 base identity MUST be set to "rt:routing-protocol", or to an 488 identity derived from "rt:routing-protocol". 490 o Additional route attributes MAY be defined. Their definitions 491 then have to be inserted as operational state data by augmenting 492 the definition of "rt:route" inside "rt:routing-table", and 493 possibly to other places in configuration data and RPC input or 494 output. 496 o The recommended way of defining configuration data specific to a 497 new protocol is to augment the "routing-protocol" list entry with 498 a container that encapsulates the configuration hierarchy of the 499 new protocol. The "augment" statement SHOULD be made conditional 500 by using a "when" substatement requiring that the new nodes be 501 used only if the "type" leaf node is equal to the new protocol's 502 identity. 504 The above steps are implemented by the example YANG module for the 505 RIP routing protocol in Appendix A. First, the module defines a new 506 identity for the RIP protocol: 508 identity rip { 509 base rt:routing-protocol; 510 description "Identity for the RIP routing protocol."; 511 } 513 Second, new route attributes specific for the RIP protocol ("metric" 514 and "tag") are defined in a grouping and then added to route 515 definitions appearing in "routing-table" and in the output part of 516 "get-route" RPC method: 518 grouping route-content { 519 description 520 "RIP-specific route content."; 521 leaf metric { 522 type rip-metric; 523 } 524 leaf tag { 525 type uint16; 526 default "0"; 527 description 528 "This leaf may be used to carry additional info, e.g. AS 529 number."; 530 } 531 } 533 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 534 + "rt:routes/rt:route" { 535 when "../../../../rt:routing-protocols/" 536 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 537 + "rt:type='rip:rip'" { 538 description 539 "This augment is only valid if the source protocol from which 540 the route originated is RIP."; 541 } 542 description 543 "RIP-specific route components."; 544 uses route-content; 545 } 547 augment "/rt:get-route/rt:output/rt:route" { 548 description 549 "Add RIP-specific route content."; 550 uses route-content; 551 } 553 The "when" substatement in the first "augment" guarantees that the 554 new route attributes are only valid when the source protocol is RIP. 556 Finally, RIP-specific configuration data are integrated into the "rt: 557 routing-protocol" node by using the following "augment" statement, 558 which applies only to routing protocol instances whose type is "rip: 559 rip": 561 augment "/rt:routing/rt:router/rt:routing-protocols/" 562 + "rt:routing-protocol" { 563 when "rt:type = 'rip:rip'"; 564 container rip-configuration { 565 container rip-interfaces { 566 list rip-interface { 567 key "name"; 568 leaf name { 569 type if:interface-ref; 570 } 571 leaf enabled { 572 type boolean; 573 default "true"; 574 } 575 leaf metric { 576 type rip-metric; 577 default "1"; 578 } 579 } 580 } 581 leaf update-interval { 582 type uint8 { 583 range "10..60"; 584 } 585 units "seconds"; 586 default "30"; 587 description 588 "Time interval between periodic updates."; 589 } 590 } 591 } 593 4.5. Route Filters 595 The core routing data model provides a skeleton for defining route 596 filters that can be used to restrict the set of routes being 597 exchanged between a routing protocol instance and a routing table, or 598 between a source and a recipient routing table. Route filters may 599 also manipulate routes, i.e., add, delete, or modify their 600 properties. 602 By itself, the route filtering framework defined in this document 603 allows to establish only the two extreme routing policies in which 604 either all routes are allowed or all routes are rejected. It is 605 expected that real route filtering framework(s) will be developed 606 separately. 608 Each route filter is identified by a name which MUST be unique within 609 a router instance. Its type MUST be specified by the "type" identity 610 reference - this opens the space for multiple route filtering 611 framework implementations. The default value for route filter type 612 is the identity "deny-all-route-filter" defined in the "ietf-routing" 613 module, which represents a route filtering policy in which all routes 614 are rejected. 616 4.6. RPC Operation 618 The "ietf-routing" module defines the "get-route" RPC operation. It 619 is used for querying the forwarding information base of a router 620 instance. The first input parameter is the name of the router 621 instance whose FIB is to be queried, and the second parameter is a 622 destination address. Modules for particular address families are 623 expected to augment the "destination-address" container with the 624 "address" leaf, as it is done in the "ietf-ipv4-unicast-routing" 625 module. 627 The server replies with an active route which is used for forwarding 628 datagrams to the destination address within the selected router 629 instance. Again, modules for particular address families are 630 expected to augment the definition of output parameters with AFN/ 631 SAFI-specific contents. 633 5. IANA AFN and SAFI YANG Module 635 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 636 actual RFC number and all occurrences of the revision date below with 637 the date of RFC publication (and remove this note). 639 file "iana-afn-safi@2011-09-23.yang" 641 module iana-afn-safi { 643 namespace "urn:ietf:params:xml:ns:yang:iana-afn-safi"; 645 prefix "ianaaf"; 647 organization 648 "IANA"; 650 contact 651 "Internet Assigned Numbers Authority 653 Postal: 654 ICANN 655 4676 Admiralty Way, Suite 330 656 Marina del Rey, CA 90292 657 U. S. A. 659 Tel: +1 310 823 9358 660 E-Mail: iana&iana.org 661 "; 663 description 664 "This YANG module provides two typedefs containing YANG 665 definitions for the following IANA-registered enumerations: 667 - Address Family Numbers (AFN) 669 - Subsequent Address Family Identifiers (SAFI) 671 The latest revision of this YANG module can be obtained from the 672 IANA web site. 674 Copyright (c) 2011 IETF Trust and the persons identified as 675 authors of the code. All rights reserved. 677 Redistribution and use in source and binary forms, with or 678 without modification, is permitted pursuant to, and subject to 679 the license terms contained in, the Simplified BSD License set 680 forth in Section 4.c of the IETF Trust's Legal Provisions 681 Relating to IETF Documents 682 (http://trustee.ietf.org/license-info). 684 This version of this YANG module is part of RFC XXXX; see the 685 RFC itself for full legal notices. 686 "; 688 revision 2011-09-23 { 689 description 690 "Initial revision."; 691 reference 692 "RFC XXXX: A YANG Data Model for Routing Configuration"; 693 } 695 typedef address-family { 696 type enumeration { 697 enum other { 698 value "0"; 699 description 700 "none of the following"; 701 } 702 enum ipV4 { 703 value "1"; 704 description 705 "IP Version 4"; 706 } 707 enum ipV6 { 708 value "2"; 709 description 710 "IP Version 6"; 711 } 712 enum nsap { 713 value "3"; 714 description 715 "NSAP"; 716 } 717 enum hdlc { 718 value "4"; 719 description 720 "(8-bit multidrop)"; 721 } 722 enum bbn1822 { 723 value "5"; 724 description 725 "BBN Report 1822"; 726 } 727 enum all802 { 728 value "6"; 729 description 730 "(includes all 802 media plus Ethernet 'canonical 731 format')"; 732 } 733 enum e163 { 734 value "7"; 735 description 736 "E.163"; 737 } 738 enum e164 { 739 value "8"; 740 description 741 "(SMDS, FrameRelay, ATM)"; 742 } 743 enum f69 { 744 value "9"; 745 description 746 "(Telex)"; 747 } 748 enum x121 { 749 value "10"; 750 description 751 "(X.25, Frame Relay)"; 752 } 753 enum ipx { 754 value "11"; 755 description 756 "IPX (Internet Protocol Exchange)"; 757 } 758 enum appleTalk { 759 value "12"; 760 description 761 "Apple Talk"; 762 } 763 enum decnetIV { 764 value "13"; 765 description 766 "DEC Net Phase IV"; 767 } 768 enum banyanVines { 769 value "14"; 770 description 771 "Banyan Vines"; 772 } 773 enum e164withNsap { 774 value "15"; 775 description 776 "(E.164 with NSAP format subaddress)"; 777 } 778 enum dns { 779 value "16"; 780 description 781 "(Domain Name System)"; 782 } 783 enum distinguishedName { 784 value "17"; 785 description 786 "(Distinguished Name, per X.500)"; 787 } 788 enum asNumber { 789 value "18"; 790 description 791 "(16-bit quantity, per the AS number space)"; 792 } 793 enum xtpOverIPv4 { 794 value "19"; 795 description 796 "XTP over IP version 4"; 797 } 798 enum xtpOverIpv6 { 799 value "20"; 800 description 801 "XTP over IP version 6"; 802 } 803 enum xtpNativeModeXTP { 804 value "21"; 805 description 806 "XTP native mode XTP"; 807 } 808 enum fibreChannelWWPN { 809 value "22"; 810 description 811 "Fibre Channel World-Wide Port Name"; 812 } 813 enum fibreChannelWWNN { 814 value "23"; 815 description 816 "Fibre Channel World-Wide Node Name"; 817 } 818 enum gwid { 819 value "24"; 820 description 821 "Gateway Identifier"; 822 } 823 enum afi { 824 value "25"; 825 description 826 "AFI for L2VPN"; 827 } 828 } 829 description 830 "This typedef is a YANG enumeration of IANA-registered address 831 family numbers (AFN)."; 832 reference 833 "Address Family Numbers. IANA, 2011-01-20. 834 837 IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS 838 839 "; 840 } 842 typedef subsequent-address-family { 843 type enumeration { 844 enum nlri-unicast { 845 value "1"; 846 description 847 "Network Layer Reachability Information used for unicast 848 forwarding"; 849 reference 850 "RFC4760"; 851 } 852 enum nlri-multicast { 853 value "2"; 854 description 855 "Network Layer Reachability Information used for multicast 856 forwarding"; 857 reference 858 "RFC4760"; 859 } 860 enum nlri-mpls { 861 value "4"; 862 description 863 "Network Layer Reachability Information (NLRI) with MPLS 864 Labels"; 865 reference 866 "RFC3107"; 867 } 868 enum mcast-vpn { 869 value "5"; 870 description 871 "MCAST-VPN"; 873 reference 874 "draft-ietf-l3vpn-2547bis-mcast-bgp-08"; 875 } 876 enum nlri-dynamic-ms-pw { 877 value "6"; 878 status "obsolete"; 879 description 880 "Network Layer Reachability Information used for Dynamic 881 Placement of Multi-Segment Pseudowires (TEMPORARY - 882 Expires 2008-08-23)"; 883 reference 884 "draft-ietf-pwe3-dynamic-ms-pw-13"; 885 } 886 enum tunnel-safi { 887 value "64"; 888 description 889 "Tunnel SAFI"; 890 reference 891 "draft-nalawade-kapoor-tunnel-safi-05"; 892 } 893 enum vpls { 894 value "65"; 895 description 896 "Virtual Private LAN Service (VPLS)"; 897 reference 898 "RFC4761, RFC6074"; 899 } 900 enum bgp-mdt { 901 value "66"; 902 description 903 "BGP MDT SAFI"; 904 reference 905 "RFC6037"; 906 } 907 enum bgp-4over6 { 908 value "67"; 909 description 910 "BGP 4over6 SAFI"; 911 reference 912 "RFC5747"; 913 } 914 enum bgp-6over4 { 915 value "68"; 916 description 917 "BGP 6over4 SAFI"; 918 reference 919 "mailto:cuiyong&tsinghua.edu.cn"; 920 } 921 enum l1vpn-auto-discovery { 922 value "69"; 923 description 924 "Layer-1 VPN auto-discovery information"; 925 reference 926 "draft-ietf-l1vpn-bgp-auto-discovery-05"; 927 } 928 enum mpls-vpn { 929 value "128"; 930 description 931 "MPLS-labeled VPN address"; 932 reference 933 "RFC4364"; 934 } 935 enum multicast-bgp-mpls-vpn { 936 value "129"; 937 description 938 "Multicast for BGP/MPLS IP Virtual Private Networks 939 (VPNs)"; 940 reference 941 "draft-ietf-l3vpn-2547bis-mcast-10, 942 draft-ietf-l3vpn-2547bis-mcast-10"; 943 } 944 enum route-target-constraints { 945 value "132"; 946 description 947 "Route Target constraints"; 948 reference 949 "RFC4684"; 950 } 951 enum ipv4-diss-flow { 952 value "133"; 953 description 954 "IPv4 dissemination of flow specification rules"; 955 reference 956 "RFC5575"; 957 } 958 enum vpnv4-diss-flow { 959 value "134"; 960 description 961 "IPv4 dissemination of flow specification rules"; 962 reference 963 "RFC5575"; 964 } 965 enum vpn-auto-discovery { 966 value "140"; 967 description 968 "VPN auto-discovery"; 970 reference 971 "draft-ietf-l3vpn-bgpvpn-auto-09"; 972 } 973 } 974 description 975 "This typedef is a YANG enumeration of IANA-registered 976 subsequent address family identifiers (SAFI)."; 977 reference 978 "Subsequent Address Family Identifiers (SAFI) Parameters. IANA, 979 2011-03-04. 981 "; 982 } 983 } 985 987 6. Routing YANG Module 989 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 990 actual RFC number and all occurrences of the revision date below with 991 the date of RFC publication (and remove this note). 993 file "ietf-routing@2011-09-23.yang" 995 module ietf-routing { 997 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 999 prefix "rt"; 1001 import ietf-yang-types { 1002 prefix "yang"; 1003 } 1005 import iana-afn-safi { 1006 prefix "ianaaf"; 1007 } 1009 organization 1010 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1012 contact 1013 "WG Web: 1014 WG List: 1016 WG Chair: David Kessens 1017 1019 WG Chair: Juergen Schoenwaelder 1020 1022 Editor: Ladislav Lhotka 1023 1024 "; 1026 description 1027 "This module contains YANG definitions of essential components 1028 that may be used for configuring a routing subsystem. 1030 Copyright (c) 2011 IETF Trust and the persons identified as 1031 authors of the code. All rights reserved. 1033 Redistribution and use in source and binary forms, with or 1034 without modification, is permitted pursuant to, and subject to 1035 the license terms contained in, the Simplified BSD License set 1036 forth in Section 4.c of the IETF Trust's Legal Provisions 1037 Relating to IETF Documents 1038 (http://trustee.ietf.org/license-info). 1040 This version of this YANG module is part of RFC XXXX; see the 1041 RFC itself for full legal notices. 1042 "; 1044 revision 2011-09-23 { 1045 description 1046 "Initial revision."; 1047 reference 1048 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1049 } 1051 /* Identities */ 1053 identity routing-protocol { 1054 description 1055 "Base identity from which routing protocol identities are 1056 derived."; 1057 } 1059 identity direct { 1060 base routing-protocol; 1061 description 1062 "Routing pseudo-protocol which provides routes to directly 1063 connected networks."; 1064 } 1066 identity static { 1067 base routing-protocol; 1068 description 1069 "Static routing pseudo-protocol."; 1070 } 1072 identity route-filter { 1073 description 1074 "Base identity from which all route filters are derived."; 1075 } 1077 identity deny-all-route-filter { 1078 base route-filter; 1079 description 1080 "Route filter that blocks all routes."; 1081 } 1082 /* Type Definitions */ 1084 typedef router-ref { 1085 type leafref { 1086 path "/rt:routing/rt:router/rt:name"; 1087 } 1088 description 1089 "This type is used for leafs that reference a router 1090 instance."; 1091 } 1093 /* Groupings */ 1095 grouping afn-safi { 1096 leaf address-family { 1097 type ianaaf:address-family; 1098 default "ipV4"; 1099 description 1100 "Address family of routes in the routing table."; 1101 } 1102 leaf safi { 1103 type ianaaf:subsequent-address-family; 1104 default "nlri-unicast"; 1105 description 1106 "Subsequent address family identifier of routes in the 1107 routing table."; 1108 } 1109 description 1110 "This grouping provides two parameters specifying address 1111 family and subsequent address family."; 1112 } 1114 grouping route-content { 1115 description 1116 "Generic parameters of routes."; 1117 leaf source-protocol { 1118 type string; 1119 description 1120 "The name of the routing protocol instance from which the 1121 route comes. This routing protocol must be configured 1122 (automatically or manually) in the device."; 1123 } 1124 leaf last-modified { 1125 type yang:date-and-time; 1126 description 1127 "Time stamp of the last modification of the route. If the 1128 route was never modified, it is the time when the route was 1129 inserted to the routing table."; 1131 } 1132 } 1134 /* RPC Methods */ 1136 rpc get-route { 1137 description 1138 "Query the forwarding information base of a router instance 1139 whose name is given as the first parameter 'router-name'. The 1140 second parameter 'destination-address' should be augmented in 1141 order to support destination addresses of all supported 1142 address families. The server returns the route which is 1143 currently used for forwarding datagrams to that destination 1144 address, or an error message, if no such route exists."; 1145 input { 1146 leaf router-name { 1147 type router-ref; 1148 mandatory "true"; 1149 description 1150 "First parameter: name of the router instance whose 1151 forwarding information base is queried."; 1152 } 1153 container destination-address { 1154 uses afn-safi; 1155 description 1156 "Second parameter: destination address. 1158 AFN/SAFI-specific modules must augment this container with 1159 a leaf named 'address'. 1160 "; 1161 } 1162 } 1163 output { 1164 container route { 1165 uses afn-safi; 1166 description 1167 "Contents of the reply specific for each address family 1168 should be defined through augmenting."; 1169 uses route-content; 1170 } 1171 } 1172 } 1174 /* Data Nodes */ 1176 container routing { 1177 description 1178 "Routing parameters."; 1180 list router { 1181 key "name"; 1182 description 1183 "Each list entry is a container for configuration and 1184 operational state data of a single (logical) router."; 1185 leaf name { 1186 type string; 1187 description 1188 "The unique router name."; 1189 } 1190 leaf description { 1191 type string; 1192 description 1193 "Textual description of the router."; 1194 } 1195 leaf enabled { 1196 type boolean; 1197 default "true"; 1198 description 1199 "Enable or disable the router. The default value is 'true', 1200 which means that the router is enabled."; 1201 } 1202 container routing-protocols { 1203 description 1204 "Container for the list of configured routing protocol 1205 instances."; 1206 list routing-protocol { 1207 key "name"; 1208 description 1209 "An instance of a routing protocol."; 1210 leaf name { 1211 type string; 1212 description 1213 "The name of the routing protocol instance."; 1214 } 1215 leaf description { 1216 type string; 1217 description 1218 "Textual description of the routing protocol 1219 instance."; 1220 } 1221 leaf type { 1222 type identityref { 1223 base routing-protocol; 1224 } 1225 mandatory "true"; 1226 description 1227 "Type of the routing protocol - an identity derived 1228 from the 'routing-protocol' base identity."; 1229 } 1230 container connected-routing-tables { 1231 description 1232 "Container for connected routing tables."; 1233 list connected-routing-table { 1234 key "name"; 1235 description 1236 "List of routing tables to which the routing protocol 1237 instance is connected. No more than one routing 1238 table may be configured for each AFN/SAFI pair. 1240 Implementation may provide default routing tables 1241 for some AFN/SAFI pairs, which are used if the 1242 corresponding entry is not configured. 1243 "; 1244 leaf name { 1245 type leafref { 1246 path "../../../../../routing-tables/routing-table/" 1247 + "name"; 1248 } 1249 description 1250 "This must be the name of an existing routing 1251 table."; 1252 } 1253 leaf import-filter { 1254 type leafref { 1255 path "../../../../../route-filters/route-filter/" 1256 + "name"; 1257 } 1258 description 1259 "Reference to a route filter that is used for 1260 filtering routes passed from this routing protocol 1261 instance to the routing table specified by the 1262 'name' sibling node. If this leaf is not present, 1263 the behavior is protocol-specific, but typically 1264 it means that all routes are accepted."; 1265 } 1266 leaf export-filter { 1267 type leafref { 1268 path "../../../../../route-filters/route-filter/" 1269 + "name"; 1270 } 1271 description 1272 "Reference to a route filter that is used for 1273 filtering routes passed from the routing table 1274 specified by the 'name' sibling node to this 1275 routing protocol instance. If this leaf is not 1276 present, the behavior is protocol-specific - 1277 typically it means that all routes are accepted, 1278 except for the 'direct' and 'static' 1279 pseudo-protocols which accept no routes from any 1280 routing table."; 1281 } 1282 } 1283 } 1284 } 1285 } 1286 container route-filters { 1287 description 1288 "Container for configured route filters."; 1289 list route-filter { 1290 key "name"; 1291 description 1292 "Route filters are used for filtering and/or manipulating 1293 routes that are passed between a routing protocol and a 1294 routing table or vice versa, or between two routing 1295 tables. It is expected that other modules augment this 1296 list with contents specific for a particular route 1297 filter type."; 1298 leaf name { 1299 type string; 1300 description 1301 "The name of the route filter."; 1302 } 1303 leaf description { 1304 type string; 1305 description 1306 "Textual description of the route filter."; 1307 } 1308 leaf type { 1309 type identityref { 1310 base route-filter; 1311 } 1312 default "deny-all-route-filter"; 1313 description 1314 "Type of the route-filter - an identity derived from 1315 the 'route-filter' base identity. The default value 1316 represents an all-blocking filter."; 1317 } 1318 } 1319 } 1320 container routing-tables { 1321 description 1322 "Container for configured routing tables."; 1323 list routing-table { 1324 key "name"; 1325 description 1326 "Each entry represents a routing table identified by the 1327 'name' key. All routes in a routing table must have the 1328 same AFN and SAFI."; 1329 leaf name { 1330 type string; 1331 description 1332 "The name of the routing table."; 1333 } 1334 uses afn-safi; 1335 leaf description { 1336 type string; 1337 description 1338 "Textual description of the routing table."; 1339 } 1340 container routes { 1341 config "false"; 1342 description 1343 "Current contents of the routing table (operational 1344 state data)."; 1345 list route { 1346 description 1347 "A routing table entry. It is expected that this data 1348 node will be augmented with information specific for 1349 routes of each address family."; 1350 uses route-content; 1351 } 1352 } 1353 list recipient-routing-tables { 1354 key "recipient-name"; 1355 description 1356 "A list of routing tables that receive routes from this 1357 routing table."; 1358 leaf recipient-name { 1359 type leafref { 1360 path "../../../routing-table/name"; 1361 } 1362 description 1363 "The name of the recipient routing table."; 1364 } 1365 leaf filter { 1366 type leafref { 1367 path "../../../../route-filters/route-filter/name"; 1368 } 1369 description 1370 "A route filter which is applied to the routes passed 1371 on to the recipient routing table."; 1373 } 1374 } 1375 } 1376 } 1377 } 1378 } 1379 } 1381 1383 7. IPv4 Unicast Routing YANG Module 1385 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1386 actual RFC number and all occurrences of the revision date below with 1387 the date of RFC publication (and remove this note). 1389 file "ietf-ipv4-unicast-routing@2011-09-23.yang" 1391 module ietf-ipv4-unicast-routing { 1393 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1395 prefix "v4ur"; 1397 import ietf-routing { 1398 prefix "rt"; 1399 } 1401 import ietf-inet-types { 1402 prefix "inet"; 1403 } 1405 import ietf-interfaces { 1406 prefix "if"; 1407 } 1409 organization 1410 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1412 contact 1413 "WG Web: 1414 WG List: 1416 WG Chair: David Kessens 1417 1419 WG Chair: Juergen Schoenwaelder 1420 1422 Editor: Ladislav Lhotka 1423 1424 "; 1426 description 1427 "This module augments the 'ietf-routing' module with YANG 1428 definitions for basic configuration of IPv4 unicast routing. 1430 Copyright (c) 2011 IETF Trust and the persons identified as 1431 authors of the code. All rights reserved. 1433 Redistribution and use in source and binary forms, with or 1434 without modification, is permitted pursuant to, and subject to 1435 the license terms contained in, the Simplified BSD License set 1436 forth in Section 4.c of the IETF Trust's Legal Provisions 1437 Relating to IETF Documents 1438 (http://trustee.ietf.org/license-info). 1440 This version of this YANG module is part of RFC XXXX; see the 1441 RFC itself for full legal notices. 1442 "; 1444 revision 2011-09-23 { 1445 description 1446 "Initial revision."; 1447 reference 1448 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1449 } 1451 /* Groupings */ 1453 grouping route-content { 1454 description 1455 "Specific parameters of IPv4 unicast routes."; 1456 leaf destination-prefix { 1457 type inet:ipv4-prefix; 1458 description 1459 "IPv4 destination prefix."; 1460 } 1461 leaf next-hop { 1462 type inet:ipv4-address; 1463 description 1464 "IPv4 address of the next hop."; 1465 } 1466 leaf outgoing-interface { 1467 type if:interface-ref; 1468 description 1469 "Outgoing interface."; 1470 } 1471 } 1473 /* RPC Methods */ 1475 augment "/rt:get-route/rt:input/rt:destination-address" { 1476 when "address-family='ipV4' and safi='nlri-unicast'" { 1477 description 1478 "This augment is valid only for IPv4 unicast."; 1480 } 1481 description 1482 "The 'address' leaf augments the 'rt:destination-address' 1483 parameter of the 'rt:get-route' operation."; 1484 leaf address { 1485 type inet:ipv4-address; 1486 description 1487 "IPv4 destination address."; 1488 } 1489 } 1491 augment "/rt:get-route/rt:output/rt:route" { 1492 when "address-family='ipV4' and safi='nlri-unicast'" { 1493 description 1494 "This augment is valid only for IPv4 unicast."; 1495 } 1496 description 1497 "Contents of the reply to 'rt:get-route' operation."; 1498 uses route-content; 1499 } 1501 /* Data nodes */ 1503 augment "/rt:routing/rt:router/rt:routing-protocols/" 1504 + "rt:routing-protocol" { 1505 when "rt:type='rt:static'" { 1506 description 1507 "The augment is only valid for the 'static' 1508 pseudo-protocol."; 1509 } 1510 description 1511 "This augment defines the configuration of the static 1512 pseudo-protocol with data specific for IPv4 unicast."; 1513 container ipv4-unicast-static-routes { 1514 description 1515 "Configuration of a 'static' pseudo-protocol instance 1516 consists of a list of routes."; 1517 list static-route { 1518 key "id"; 1519 ordered-by "user"; 1520 description 1521 "A user-ordered list of static routes."; 1522 leaf id { 1523 type string; 1524 description 1525 "An identification string for the route."; 1526 } 1527 leaf description { 1528 type string; 1529 description 1530 "Textual description of the route."; 1531 } 1532 uses route-content; 1533 } 1534 } 1535 } 1537 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 1538 + "rt:routes/rt:route" { 1539 when "../../rt:address-family='ipV4' and " 1540 + "../../rt:safi='nlri-unicast'" { 1541 description 1542 "This augment is valid only for IPv4 unicast."; 1543 } 1544 description 1545 "This augment defines the content of IPv4 unicast routes."; 1546 uses route-content; 1547 } 1548 } 1550 1552 8. IANA Considerations 1554 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1555 actual RFC number (and remove this note). 1557 This document registers the following namespace URIs in the IETF XML 1558 registry [RFC3688]: 1560 ---------------------------------------------------------- 1561 URI: urn:ietf:params:xml:ns:yang:ietf-routing 1563 Registrant Contact: The IESG. 1565 XML: N/A, the requested URI is an XML namespace. 1566 ---------------------------------------------------------- 1568 ---------------------------------------------------------- 1569 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 1571 Registrant Contact: The IESG. 1573 XML: N/A, the requested URI is an XML namespace. 1574 ---------------------------------------------------------- 1576 ---------------------------------------------------------- 1577 URI: urn:ietf:params:xml:ns:yang:iana-afn-safi 1579 Registrant Contact: IANA. 1581 XML: N/A, the requested URI is an XML namespace. 1582 ---------------------------------------------------------- 1584 This document registers the following YANG modules in the YANG Module 1585 Names registry [RFC6020]: 1587 ------------------------------------------------------------------- 1588 name: ietf-routing 1589 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 1590 prefix: rt 1591 reference: RFC XXXX 1592 ------------------------------------------------------------------- 1594 ------------------------------------------------------------------- 1595 name: ietf-ipv4-unicast-routing 1596 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 1597 prefix: v4ur 1598 reference: RFC XXXX 1599 ------------------------------------------------------------------- 1601 ------------------------------------------------------------------- 1602 name: iana-afn-safi 1603 namespace: urn:ietf:params:xml:ns:yang:iana-afn-safi 1604 prefix: ianaaf 1605 reference: RFC XXXX 1606 ------------------------------------------------------------------- 1608 9. Security Considerations 1610 The YANG modules defined in this document are designed to be accessed 1611 via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 1612 secure transport layer and the mandatory-to-implement secure 1613 transport is SSH [RFC6242]. 1615 A number of data nodes defined in the YANG modules are writable/ 1616 creatable/deletable (i.e., "config true" in YANG terms, which is the 1617 default). These data nodes may be considered sensitive or vulnerable 1618 in some network environments. Write operations to these data nodes, 1619 such as "edit-config", can have negative effects on the network if 1620 the operations are not properly protected. 1622 The vulnerable "config true" subtrees and data nodes are the 1623 following: 1625 /rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This 1626 list specifies the routing protocols configured on a device. 1628 /rt:routing/rt:router/rt:route-filters/rt:route-filter This list 1629 specifies the configured route filters which represent the 1630 administrative policies for redistributing and modifying routing 1631 information. 1633 Unauthorized access to any of these lists can adversely affect the 1634 routing subsystem of both the local device and the network. This may 1635 lead to network malfunctions, delivery of packets to inappropriate 1636 destinations and other problems. 1638 10. Acknowledgments 1640 The author wishes to thank Martin Bjorklund, Joel Halpern, Tom Petch 1641 and Juergen Schoenwaelder for their helpful comments and suggestions. 1643 11. References 1645 11.1. Normative References 1647 [IANA-AFN] 1648 IANA, "Address Family Numbers.", January 2011. 1650 [IANA-SAFI] 1651 IANA, "Subsequent Address Family Identifiers (SAFI) 1652 Parameters.", March 2011. 1654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1655 Requirement Levels", BCP 14, RFC 2119, March 1997. 1657 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1658 January 2004. 1660 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1661 Network Configuration Protocol (NETCONF)", RFC 6020, 1662 September 2010. 1664 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 1665 RFC 6021, September 2010. 1667 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 1668 Bierman, "NETCONF Configuration Protocol", RFC 6241, 1669 June 2011. 1671 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 1672 Configuration", draft-ietf-netmod-interfaces-cfg-02 (work 1673 in progress), September 2011. 1675 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 1676 draft-ietf-netmod-ip-cfg-00 (work in progress), 1677 September 2011. 1679 11.2. Informative References 1681 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 1682 Data Model Documents", RFC 6087, January 2011. 1684 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1685 Shell (SSH)", RFC 6242, June 2011. 1687 Appendix A. Example - Adding a New Routing Protocol 1689 This appendix demonstrates how the core routing data model can be 1690 extended to support a new routing protocol. Appendix A.1 contains 1691 the YANG module which is used for this purpose. It is intended only 1692 as an illustration and not as a real definition of a data model for 1693 the RIP routing protocol. Also, for the sake of brevity, we do not 1694 follow all the guidelines specified in [RFC6087]. 1696 Appendix A.2 then contains a complete instance XML document - a reply 1697 to the NETCONF message from a server that uses the RIP protocol 1698 as well as static routing. 1700 A.1. Example YANG Module for Routing Information 1701 Protocol 1703 file "example-rip@2011-09-23.yang" 1705 module example-rip { 1707 namespace "http://example.com/rip"; 1709 prefix "rip"; 1711 import ietf-routing { 1712 prefix "rt"; 1713 } 1715 import ietf-interfaces { 1716 prefix "if"; 1717 } 1719 identity rip { 1720 base rt:routing-protocol; 1721 description 1722 "Identity for the RIP routing protocol."; 1723 } 1725 typedef rip-metric { 1726 type uint8 { 1727 range "0..16"; 1728 } 1729 } 1731 grouping route-content { 1732 description 1733 "RIP-specific route content."; 1734 leaf metric { 1735 type rip-metric; 1736 } 1737 leaf tag { 1738 type uint16; 1739 default "0"; 1740 description 1741 "This leaf may be used to carry additional info, e.g. AS 1742 number."; 1743 } 1744 } 1746 augment "/rt:get-route/rt:output/rt:route" { 1747 description 1748 "Add RIP-specific route content."; 1749 uses route-content; 1750 } 1752 augment "/rt:routing/rt:router/rt:routing-protocols/" 1753 + "rt:routing-protocol" { 1754 when "rt:type = 'rip:rip'"; 1755 container rip-configuration { 1756 container rip-interfaces { 1757 list rip-interface { 1758 key "name"; 1759 leaf name { 1760 type if:interface-ref; 1761 } 1762 leaf enabled { 1763 type boolean; 1764 default "true"; 1765 } 1766 leaf metric { 1767 type rip-metric; 1768 default "1"; 1769 } 1770 } 1771 } 1772 leaf update-interval { 1773 type uint8 { 1774 range "10..60"; 1775 } 1776 units "seconds"; 1777 default "30"; 1778 description 1779 "Time interval between periodic updates."; 1780 } 1781 } 1782 } 1783 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 1784 + "rt:routes/rt:route" { 1785 when "../../../../rt:routing-protocols/" 1786 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 1787 + "rt:type='rip:rip'" { 1788 description 1789 "This augment is only valid if the source protocol from which 1790 the route originated is RIP."; 1791 } 1792 description 1793 "RIP-specific route components."; 1794 uses route-content; 1795 } 1796 } 1798 1800 A.2. Sample Reply to the NETCONF Message 1802 This section contains a sample reply to the NETCONF message, 1803 which could be sent by a server supporting (and advertising in the 1804 NETCONF message) the following YANG modules: 1806 o ietf-interfaces [YANG-IF], 1808 o ex-ethernet [YANG-IF], 1810 o ietf-ip [YANG-IP], 1812 o ietf-routing (Section 6), 1814 o ietf-ipv4-unicast-routing (Section 7), 1816 o example-rip (Appendix A.1). 1818 We assume a simple network setup as shown in Figure 3: routers "ISP" 1819 and "A" use RIP for exchanging routing information whereas static 1820 routing is used in the private network. In order to avoid the 1821 redistribution of the routes to the private subnetworks 1822 192.168.1.0/24 and 192.168.2.0/24 in RIP, an export filter is used in 1823 the RIP protocol configuration preventing the routes from the main 1824 routing table from appearing in RIP updates. 1826 +-----------------+ 1827 | | 1828 | Router ISP | 1829 | | 1830 +--------+--------+ 1831 |192.0.2.2 1832 | 1833 | 1834 eth0|192.0.2.1 1835 +--------+--------+ 1836 | | 1837 | Router A | 1838 | | 1839 +--------+--------+ 1840 eth1|192.168.1.1 1841 | 1842 | 1843 |192.168.1.254 1844 +--------+--------+ 1845 | | 1846 | Router B | 1847 | | 1848 +--------+--------+ 1849 |192.168.2.1 1850 | 1852 Figure 3: Example network configuration 1854 Router "A" then could send the following XML document as its reply to 1855 the NETCONF message: 1857 1859 1868 1869 1870 1871 eth0 1872 ethernetCsmacd 1873 05:00.0 1874 1875 1876 192.0.2.1 1877 24 1878 1879 1880 1881 1882 eth1 1883 ethernetCsmacd 1884 05:00.1 1885 1886 1887 192.168.1.1 1888 24 1889 1890 1891 1892 1893 1894 1895 inet-0 1896 1897 1898 direct 1899 rt:direct 1900 1901 1902 st0 1903 1904 Static routing is used for the internal network. 1905 1906 rt:static 1907 1908 1909 id-6378 1910 192.168.2.0/24 1911 192.168.1.254 1912 1913 1914 1915 1916 rip0 1917 1918 RIP is used on the uplink. Static routes to the 1919 internal networks are not advertized in RIP. 1920 1921 rip:rip 1922 1923 1924 ipv4-unicast-main 1925 deny-all 1926 1927 1928 1929 1930 1931 eth0 1932 1933 1934 1935 1936 1937 1938 1939 deny-all 1940 1941 1942 1943 1944 ipv4-unicast-fib 1945 1946 1947 192.0.2.1/24 1948 direct 1949 eth0 1950 2011-09-23T17:11:27+01:00 1951 1952 1953 192.168.1.0/24 1954 direct 1955 eth1 1956 2011-09-23T17:11:27+01:00 1957 1958 1959 192.168.2.0/24 1960 st0 1961 192.168.1.254 1962 2011-09-23T17:11:32+01:00 1963 1964 1965 0.0.0.0/0 1966 rip0 1967 192.0.2.2 1968 2 1969 64500 1970 2011-09-23T18:02:45+01:00 1971 1972 1973 1974 1975 ipv4-unicast-main 1976 1977 ipv4-unicast-fib 1978 1979 1980 1981 192.0.2.1/24 1982 direct 1983 eth0 1984 2011-09-23T17:11:27+01:00 1985 1986 1987 192.168.1.0/24 1988 direct 1989 eth1 1990 2011-09-23T17:11:27+01:00 1991 1992 1993 192.168.2.0/24 1994 st0 1995 192.168.1.254 1996 2011-09-23T17:11:32+01:00 1997 1998 1999 0.0.0.0/0 2000 rip0 2001 192.0.2.2 2002 2 2003 64500 2004 2011-09-23T18:02:45+01:00 2005 2006 2007 2008 2009 2010 2011 2012 2014 Appendix B. Change Log 2016 RFC Editor: remove this section upon publication as an RFC. 2018 B.1. Changes Between Versions -00 and -01 2020 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2022 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2023 safi" module. 2025 o Names of some data nodes were changed, in particular "routing- 2026 process" is now "router". 2028 o The restriction of a single AFN/SAFI per router was lifted. 2030 o RPC operation "delete-route" was removed. 2032 o Illegal XPath references from "get-route" to the datastore were 2033 fixed. 2035 o Section "Security Considerations" was written. 2037 Author's Address 2039 Ladislav Lhotka 2040 CESNET 2042 Email: lhotka@cesnet.cz