idnits 2.17.1 draft-ietf-netmod-routing-cfg-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2012) is 4449 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-03 == Outdated reference: A later version (-14) exists of draft-ietf-netmod-ip-cfg-02 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD L. Lhotka 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track February 20, 2012 5 Expires: August 23, 2012 7 A YANG Data Model for Routing Configuration 8 draft-ietf-netmod-routing-cfg-02 10 Abstract 12 This document contains a specification of four YANG modules. 13 Together they form the core routing data model which serves as a 14 basis for configuring a routing subsystem. It is therefore expected 15 that this module will be augmented by additional YANG modules 16 defining data models for individual routing protocols and other 17 related functions. The core routing data model provides common 18 building blocks for such configurations - router instances, routes, 19 routing tables, routing protocols and route 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 August 23, 2012. 38 Copyright Notice 40 Copyright (c) 2012 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.1.1. Configuration of IPv6 Router Interfaces . . . . . . . 10 63 4.2. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.3. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 12 65 4.4. Routing Protocols . . . . . . . . . . . . . . . . . . . . 13 66 4.4.1. Defining New Routing Protocols . . . . . . . . . . . . 14 67 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 17 68 4.6. RPC Operation . . . . . . . . . . . . . . . . . . . . . . 18 69 5. IANA AFN and SAFI YANG Module . . . . . . . . . . . . . . . . 19 70 6. Routing YANG Module . . . . . . . . . . . . . . . . . . . . . 27 71 7. IPv4 Unicast Routing YANG Module . . . . . . . . . . . . . . . 37 72 8. IPv6 Unicast Routing YANG Module . . . . . . . . . . . . . . . 41 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 77 12.1. Normative References . . . . . . . . . . . . . . . . . . . 53 78 12.2. Informative References . . . . . . . . . . . . . . . . . . 53 79 Appendix A. Example: Adding a New Routing Protocol . . . . . . . 54 80 Appendix B. Example: Reply to the NETCONF Message . . . . . 57 81 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 63 82 C.1. Changes Between Versions -01 and -02 . . . . . . . . . . . 63 83 C.2. Changes Between Versions -00 and -01 . . . . . . . . . . . 63 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64 86 1. Introduction 88 This document contains a specification of four YANG 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 "ietf-ipv6-unicast-routing" augments the "ietf-routing" 97 module with additional data specific to IPv6 unicast, including 98 the configuration variables required by [RFC4861]. 100 o Module "iana-afn-safi" contains two type definitions translating 101 IANA registries "Address Family Numbers" [IANA-AFN] and 102 "Subsequent Address Family Identifiers" [IANA-SAFI] to YANG 103 enumerations. 105 The first three modules together define the so-called core routing 106 data model. This data model will serve as a basis for the 107 development of data models for more sophisticated routing 108 configurations. While these three modules can be directly used for 109 simple IP devices with static routing, their main purpose is to 110 provide essential building blocks for more complicated setups 111 involving multiple routing protocols, multicast routing, additional 112 address families, advanced functions such as route filtering or 113 policy routing etc. To this end, it is expected that the core 114 routing data model will be augmented by numerous modules developed by 115 other IETF working groups. 117 2. Terminology and Notation 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 The following terms are defined in [RFC6241]: 125 o client 127 o message 129 o operation 131 o server 133 The following terms are defined in [RFC6020]: 135 o augment 137 o configuration data 139 o container 141 o data model 143 o data node 145 o data type 147 o identity 149 o mandatory node 151 o module 153 o operational state data 155 o prefix 157 o RPC operation 159 2.1. Glossary of New Terms 160 active route: a route which is actually used for packet forwarding. 161 If there are multiple candidate routes with a matching destination 162 prefix, then it is up to the routing algorithm to select the 163 active route. 165 core routing data model: YANG data model resulting from the 166 combination of "ietf-routing", "ietf-ipv4-unicast-routing-cfg" and 167 "ietf-ipv6-unicast-routing-cfg" modules. 169 direct route: a route to a directly connected network. 171 2.2. Prefixes in Data Node Names 173 In this document, names of data nodes are used mostly without a 174 prefix, as long as it is clear from the context in which YANG module 175 each name is defined. Otherwise, names are prefixed with their 176 standard prefix associated with the corresponding YANG module, as 177 shown in Table 1. 179 +--------+---------------------------+------------+ 180 | Prefix | YANG module | Reference | 181 +--------+---------------------------+------------+ 182 | eth | ex-ethernet | [YANG-IF] | 183 | | | | 184 | if | ietf-interfaces | [YANG-IF] | 185 | | | | 186 | ip | ietf-ip | [YANG-IP] | 187 | | | | 188 | rip | example-rip | Appendix A | 189 | | | | 190 | rt | ietf-routing | Section 6 | 191 | | | | 192 | v4ur | ietf-ipv4-unicast-routing | Section 7 | 193 | | | | 194 | v6ur | ietf-ipv6-unicast-routing | Section 8 | 195 | | | | 196 | yang | ietf-yang-types | [RFC6021] | 197 | | | | 198 | inet | ietf-inet-types | [RFC6021] | 199 +--------+---------------------------+------------+ 201 Table 1: Prefixes and corresponding YANG modules 203 3. Objectives 205 The initial design of the core routing data model was driven by the 206 following objectives: 208 o The data model should be suitable for the common address families, 209 in particular IPv4 and IPv6, and for unicast and multicast 210 routing, as well as Multiprotocol Label Switching (MPLS). 212 o Simple routing setups, such as static routing, should be 213 configurable in a simple way, ideally without any need to develop 214 additional YANG modules. 216 o On the other hand, the core routing framework must allow for 217 complicated setups involving multiple routing tables and multiple 218 routing protocols, as well as controlled redistributions of 219 routing information. 221 o Device vendors will want to map the data models built on this 222 generic framework to their proprietary data models and 223 configuration interfaces. Therefore, the framework should be 224 flexible enough to facilitate such a mapping and accommodate data 225 models with different logic. 227 4. The Design of the Core Routing Data Model 229 The core routing data model consists of three YANG modules. The 230 first module, "ietf-routing", defines the generic components of a 231 routing system. The other two modules, "ietf-ipv4-unicast-routing" 232 and "ietf-ipv6-unicast-routing", augment the "ietf-routing" module 233 with additional data nodes that are needed for IPv4 and IPv6 unicast 234 routing, respectively. The combined data hierarchy is shown in 235 Figure 1, where brackets contain list keys and question marks 236 indicate optional data nodes. Nodes that represent configuration are 237 labeled with "rw" while operational state data have the "ro" label. 239 +--rw routing 240 +--rw router [name] 241 +--rw name 242 +--rw description? 243 +--rw enabled? 244 +--rw interfaces 245 | +--rw interface [name] 246 | +--rw name 247 | +--rw v6ur:ipv6-router-advertisements 248 | +--rw v6ur:send-advertisements? 249 | +--rw v6ur:max-rtr-adv-interval? 250 | +--rw v6ur:min-rtr-adv-interval? 251 | +--rw v6ur:managed-flag? 252 | +--rw v6ur:other-config-flag? 253 | +--rw v6ur:link-mtu? 254 | +--rw v6ur:reachable-time? 255 | +--rw v6ur:retrans-timer? 256 | +--rw v6ur:cur-hop-limit? 257 | +--rw v6ur:default-lifetime? 258 | +--rw v6ur:prefix-list 259 | +--rw v6ur:prefix [seqno] 260 | +--rw v6ur:seqno 261 | +--rw v6ur:prefix-spec? 262 | +--rw v6ur:valid-lifetime? 263 | +--rw v6ur:on-link-flag? 264 | +--rw v6ur:preferred-lifetime? 265 | +--rw v6ur:autonomous-flag? 266 +--rw routing-protocols 267 | +--rw routing-protocol [name] 268 | +--rw name 269 | +--rw description? 270 | +--rw type 271 | +--rw connected-routing-tables 272 | | +--rw routing-table [name] 273 | | +--rw name 274 | | +--rw import-filter? 275 | | +--rw export-filter? 276 | +--rw static-routes 277 | +--rw v4ur:ipv4 278 | | +--rw v4ur:route [seqno] 279 | | +--rw v4ur:seqno 280 | | +--rw v4ur:description? 281 | | +--rw v4ur:outgoing-interface? 282 | | +--rw v4ur:dest-prefix? 283 | | +--rw v4ur:next-hop? 284 | +--rw v6ur:ipv6 285 | +--rw v6ur:route [seqno] 286 | +--rw v6ur:seqno 287 | +--rw v6ur:description? 288 | +--rw v6ur:outgoing-interface? 289 | +--rw v6ur:dest-prefix? 290 | +--rw v6ur:next-hop? 291 +--rw route-filters 292 | +--rw route-filter [name] 293 | +--rw name 294 | +--rw description? 295 | +--rw type? 296 +--rw routing-tables 297 +--rw routing-table [name] 298 +--rw name 299 +--rw address-family? 300 +--rw safi? 301 +--rw description? 302 +--ro routes 303 | +--ro route 304 | +--ro source-protocol? 305 | +--ro last-modified? 306 | +--ro v4ur:outgoing-interface? 307 | +--ro v4ur:dest-prefix? 308 | +--ro v4ur:next-hop? 309 | +--ro v6ur:outgoing-interface? 310 | +--ro v6ur:dest-prefix? 311 | +--ro v6ur:next-hop? 312 +--rw recipient-routing-tables [recipient-name] 313 +--rw recipient-name 314 +--rw filter? 316 Figure 1: Data hierarchy of the core routing data model. 318 As can be seen from Figure 1, the core routing data model introduces 319 several generic components of a routing framework: routers, routing 320 tables containing routes, routing protocols, route filters and RPC 321 operations. The following subsections describe these components in 322 more detail. 324 By combining the components in various ways, and possibly augmenting 325 them with appropriate contents defined in other modules, various 326 routing setups can be realized. 328 +--------+ +------------+ 329 | direct | +---+ | | 330 | routes |--->| F |--->| FIB | 331 +--------+ +---+ | | 332 +------------+ 333 ^ 334 | 335 +---+ 336 | F | 337 +---+ 338 ^ 339 | 340 +--------------+ +---+ +--------------+ 341 +--------+ | |<---| F |<---| | 342 | static | +---+ | main | +---+ | additional | 343 | routes |--->| F |--->| routing | | routing | 344 +--------+ +---+ | table | +---+ | table | 345 | |--->| F |--->| | 346 +--------------+ +---+ +--------------+ 347 ^ | ^ | 348 | v | v 349 +---+ +---+ +---+ +---+ 350 | F | | F | | F | | F | 351 +---+ +---+ +---+ +---+ 352 ^ | ^ | 353 | v | v 354 +----------+ +----------+ 355 | routing | | routing | 356 | protocol | | protocol | 357 +----------+ +----------+ 359 Figure 2: Example setup of the routing subsystem 361 The example in Figure 2 shows a typical (though certainly not the 362 only possible) organization of a more complex routing subsystem. 363 Several of its features are worth mentioning: 365 o Along with the main routing table, which must always be present, 366 an additional routing table is configured. 368 o Each routing protocol instance, including the "static" and 369 "direct" pseudo-protocols, is connected to exactly one routing 370 table with which it can exchange routes (in both directions, 371 except for the "static" and "direct" pseudo-protocols). 373 o Routing tables may also be connected to each other and exchange 374 routes in either direction (or both). 376 o The forwarding information base (FIB) is a special routing table 377 which must always be present. Typically, the FIB contains the 378 "direct" routes for all configured interfaces and also receives 379 the active routes from the main routing table. The operating 380 system kernel uses this information for packet forwarding. 382 o Route exchanges along all connections may be controlled by means 383 of route filters, denoted by "F" in Figure 2. 385 4.1. Router 387 Each router instance in the core routing data model represents a 388 (logical) router whose configuration and operation is independent of 389 other router instances. Although it it not enforced by the data 390 model, different router instances normally do not internally share 391 any data. They may, however, communicate with each other via routing 392 protocols. 394 Logical network interfaces must be assigned to a router instance in 395 order to be able to participate in packet forwarding, routing 396 protocols and other operations of that router instance. The 397 assignment is accomplished by creating a corresponding entry in the 398 list of router interfaces ("/router/interfaces/interface"). The key 399 of the list entry MUST be the name of a configured logical interface. 400 A logical interface MUST NOT be assigned to more than one router 401 instance. 403 Apart from the key, each entry of the "/router/interfaces/interface" 404 list MAY contain other configuration or operational state data 405 related to the corresponding logical interface. 407 4.1.1. Configuration of IPv6 Router Interfaces 409 The module "ietf-ipv6-unicast-routing" augments the definition of the 410 data node "/router/interfaces/interface" with definitions of the 411 following configuration variables as required by [RFC4861], sec. 412 6.2.1: 414 o send-advertisements, 416 o max-rtr-adv-interval, 417 o min-rtr-adv-interval, 419 o managed-flag, 421 o other-config-flag, 423 o link-mtu, 425 o reachable-time, 427 o retrans-timer, 429 o cur-hop-limit, 431 o default-lifetime, 433 o prefix-list: a list of prefixes to be advertised. The following 434 parameters are associated with each prefix in the list: 436 * valid-lifetime, 438 * on-link-flag, 440 * preferred-lifetime, 442 * autonomous-flag. 444 The definitions and descriptions of the above parameters can be found 445 in the text of the module "ietf-ipv6-unicast-routing" (Section 8). 447 NOTE: The "IsRouter" flag, which is also required by [RFC4861], was 448 omitted. Is is expected that this variable will be implemented in 449 another module, either "ietf-interfaces" or "ietf-ip". 451 4.2. Route 453 Routes are basic units of information in a routing system. The core 454 routing data model defines only the following minimal set of route 455 attributes: 457 o destination-prefix - IP prefix specifying the set of destination 458 addresses for which the route may be used. This attribute is 459 mandatory. 461 o next-hop - IP address of the adjacent router or host to which 462 packets with destination addresses belonging to destination-prefix 463 should be sent. 465 o outgoing-interface - network interface that should be used for 466 sending packets with destination addresses belonging to 467 destination-prefix. 469 The above list of route attributes is sufficient for a simple static 470 routing configuration. It is expected that future modules defining 471 routing protocols will add other route attributes such as metrics or 472 preferences. 474 Routes and their attributes are used in both configuration data, for 475 example as manually configured static routes, and in operational 476 state data, for example as entries in routing tables. 478 4.3. Routing Tables 480 Routing tables are lists of routes complemented with administrative 481 data, namely: 483 o source-protocol - name of the routing protocol from which the 484 route was originally obtained. 486 o last-modified - date and time of last modification, or 487 installation, of the route. 489 Each routing table may only contain routes of the same address family 490 (AFN and SAFI). 492 In the core routing data model, the "routing-table" node represents 493 configuration while the descendant list of routes is defined as 494 operational state data. The contents of such lists are controlled by 495 routing protocol operations which may result in route additions, 496 removals and modifications. This also includes manipulations via the 497 "static" pseudo-protocol. 499 At least the following two routing tables MUST be configured for each 500 router instance and each supported AFN/SAFI pair: 502 1. Forwarding information base (FIB) contains active routes that are 503 used by the operating system kernel for forwarding datagrams. 505 2. Main routing table to which all routing protocol instances are 506 connected by default, with the exception of the "direct" pseudo- 507 protocol (Section 4.4): direct routes only appear in the FIB 508 table by default. 510 The main routing table SHOULD serve as the default source of active 511 routes for the FIB. 513 One or more additional routing tables MAY be configured by creating 514 new entries in the "routing-table" list, either being a part of 515 factory-default configuration or configured by the client. 517 The naming scheme for routing tables, as well as restrictions on the 518 number and configurability of routing tables are implementation- 519 specific. 521 Every routing table can serve as a source of routes for other routing 522 tables. To achieve this, one or more recipient routing tables may be 523 specified in the configuration of the source routing table. In 524 addition, a route filter may be configured for each recipient routing 525 table, which selects and/or manipulates the routes that are passed on 526 between the source and recipient routing table. 528 4.4. Routing Protocols 530 The core routing data model provides an open-ended framework for 531 defining multiple routing protocol instances. Each of them is 532 identified by a name, which MUST be unique within a router instance. 533 Each protocol MUST be assigned a type, which MUST be an identity 534 derived from the "rt:routing-protocol" base identity. The core 535 routing data model defines two identities for the "direct" and 536 "static" pseudo-protocols. 538 Each routing protocol instance is connected to exactly one routing 539 table. By default, every routing protocol instance SHOULD be 540 connected to the main routing table. An implementation MAY allow any 541 or all routing protocol instances to be configured to use a different 542 routing table. 544 Routes learned from the network by a routing protocol are passed to 545 the connected routing table and vice versa - routes appearing in a 546 routing table are passed to all routing protocols connected to the 547 table (except "direct" and "static" pseudo-protocols) and advertised 548 by that protocol to the network. 550 Two independent route filters (see Section 4.5) may be defined for a 551 routing protocol instance to control the exchange of routes in both 552 directions between the routing protocol instance and the connected 553 routing table: 555 o import filter controls which routes are passed from a routing 556 protocol instance to the routing table, 558 o export filter controls which routes the routing protocol instance 559 may receive from the connected routing table. 561 Note that, for historical reasons, the terms import and export are 562 used from the viewpoint of a routing table. 564 The core routing data model defines two special routing protocols - 565 "direct" and "static". Both are in fact pseudo-protocols, which 566 means that they are confined to the local device and do not exchange 567 any routing information with neighboring routers. Routes from both 568 "direct" and "static" protocol instances are passed to the connected 569 routing table (subject to route filters, if any), but an exchange in 570 the opposite direction is not allowed. 572 Every router instance MUST contain exactly one instance of the 573 "direct" pseudo-protocol. It is the source of direct routes which 574 are normally supplied by the operating system kernel, based on the 575 detected and configured network interfaces, and they SHOULD by 576 default appear in the FIB routing table. However, using the 577 framework defined in this document, the target routing table for 578 direct routes MAY be changed by connecting the "direct" protocol 579 instance to a non-default routing table. Direct routes can also be 580 filtered before they appear in the routing table. 582 The "static" routing pseudo-protocol allows for specifying routes 583 manually. It MAY be configured in zero or multiple instances, 584 although a typical implementation will have exactly one instance per 585 router. 587 4.4.1. Defining New Routing Protocols 589 It is expected that future YANG modules will create data models for 590 additional routing protocol types. In order to do so, the new module 591 has to define the protocol-specific information and fit it into the 592 core routing framework in the following way : 594 o A new identity MUST be defined for the routing protocol and its 595 base identity MUST be set to "rt:routing-protocol", or to an 596 identity derived from "rt:routing-protocol". 598 o Additional route attributes MAY be defined. Their definitions 599 then have to be inserted as operational state data by augmenting 600 the definition of "rt:route" inside "rt:routing-table", and 601 possibly to other places in the configuration, operational state 602 data and RPC input or output. 604 o Per-interface configuration parameters can be added by augmenting 605 the data node "rt:interface" (the list of router interfaces). 607 o Other configuration parameters can be defined by augmenting the 608 "routing-protocol" data node. By using the "when" statement, this 609 augment SHOULD be made conditional and valid only if the value of 610 the "rt:type" child leaf equals to the new protocol's identity. 612 It is recommended that both per-interface and other configuration 613 data specific to the new protocol be encapsulated in an appropriately 614 named container. 616 The above steps are implemented by the example YANG module for the 617 RIP routing protocol in Appendix A. First, the module defines a new 618 identity for the RIP protocol: 620 identity rip { 621 base rt:routing-protocol; 622 description "Identity for the RIP routing protocol."; 623 } 625 New route attributes specific to the RIP protocol ("metric" and 626 "tag") are defined in a grouping and then added to the route 627 definitions appearing in "routing-table" and in the output part of 628 the "get-route" RPC method: 630 grouping route-content { 631 description 632 "RIP-specific route content."; 633 leaf metric { 634 type rip-metric; 635 } 636 leaf tag { 637 type uint16; 638 default "0"; 639 description 640 "This leaf may be used to carry additional info, e.g. AS 641 number."; 642 } 643 } 645 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 646 + "rt:routes/rt:route" { 647 when "../../../../rt:routing-protocols/" 648 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 649 + "rt:type='rip:rip'" { 650 description 651 "This augment is only valid if the source protocol from which 652 the route originated is RIP."; 653 } 654 description 655 "RIP-specific route components."; 656 uses route-content; 657 } 659 augment "/rt:get-route/rt:output/rt:route" { 660 description 661 "Add RIP-specific route content."; 662 uses route-content; 663 } 665 Per-interface configuration data are defined by the following 666 "augment" statement: 668 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 669 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 670 + "'rip:rip'"; 671 container rip { 672 description 673 "Per-interface RIP configuration."; 674 leaf enabled { 675 type boolean; 676 default "true"; 677 } 678 leaf metric { 679 type rip-metric; 680 default "1"; 681 } 682 } 683 } 685 Finally, global RIP configuration data are integrated into the "rt: 686 routing-protocol" node by using the following "augment" statement, 687 which is valid only for routing protocol instances whose type is 688 "rip:rip": 690 augment "/rt:routing/rt:router/rt:routing-protocols/" 691 + "rt:routing-protocol" { 692 when "rt:type = 'rip:rip'"; 693 container rip { 694 leaf update-interval { 695 type uint8 { 696 range "10..60"; 697 } 698 units "seconds"; 699 default "30"; 700 description 701 "Time interval between periodic updates."; 702 } 703 } 704 } 706 4.5. Route Filters 708 The core routing data model provides a skeleton for defining route 709 filters that can be used to restrict the set of routes being 710 exchanged between a routing protocol instance and a connected routing 711 table, or between a source and a recipient routing table. Route 712 filters may also manipulate routes, i.e., add, delete, or modify 713 their properties. 715 By itself, the route filtering framework defined in this document 716 allows to establish only the two extreme routing policies in which 717 either all routes are allowed or all routes are rejected. It is 718 expected that real route filtering frameworks will be developed 719 separately. 721 Each route filter is identified by a name which MUST be unique within 722 a router instance. Its type MUST be specified by the "type" identity 723 reference - this opens the space for multiple route filtering 724 framework implementations. The default value for route filter type 725 is the identity "deny-all-route-filter" defined in the "ietf-routing" 726 module, which represents a route filtering policy in which all routes 727 are rejected. 729 4.6. RPC Operation 731 The "ietf-routing" module defines the "get-route" RPC operation. It 732 is used for querying the forwarding information base of a router 733 instance. The first input parameter is the name of the router 734 instance whose FIB is to be queried, and the second parameter is a 735 destination address. Modules for particular address families are 736 expected to augment the "destination-address" container with the 737 "address" leaf, as it is done in the "ietf-ipv4-unicast-routing" and 738 "ietf-ipv6-unicast-routing" modules. 740 The server replies with an active route which is used for forwarding 741 datagrams to the destination address within the selected router 742 instance. Again, modules for particular address families are 743 expected to augment the definition of output parameters with AFN/ 744 SAFI-specific contents. 746 5. IANA AFN and SAFI YANG Module 748 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 749 actual RFC number and all occurrences of the revision date below with 750 the date of RFC publication (and remove this note). 752 file "iana-afn-safi@2012-02-20.yang" 754 module iana-afn-safi { 756 namespace "urn:ietf:params:xml:ns:yang:iana-afn-safi"; 758 prefix "ianaaf"; 760 organization 761 "IANA"; 763 contact 764 "Internet Assigned Numbers Authority 766 Postal: 767 ICANN 768 4676 Admiralty Way, Suite 330 769 Marina del Rey, CA 90292 770 U. S. A. 772 Tel: +1 310 823 9358 773 E-Mail: iana&iana.org 774 "; 776 description 777 "This YANG module provides two typedefs containing YANG 778 definitions for the following IANA-registered enumerations: 780 - Address Family Numbers (AFN) 782 - Subsequent Address Family Identifiers (SAFI) 784 The latest revision of this YANG module can be obtained from the 785 IANA web site. 787 Copyright (c) 2012 IETF Trust and the persons identified as 788 authors of the code. All rights reserved. 790 Redistribution and use in source and binary forms, with or 791 without modification, is permitted pursuant to, and subject to 792 the license terms contained in, the Simplified BSD License set 793 forth in Section 4.c of the IETF Trust's Legal Provisions 794 Relating to IETF Documents 795 (http://trustee.ietf.org/license-info). 797 This version of this YANG module is part of RFC XXXX; see the 798 RFC itself for full legal notices. 799 "; 801 revision 2012-02-20 { 802 description 803 "Initial revision."; 804 reference 805 "RFC XXXX: A YANG Data Model for Routing Configuration"; 806 } 808 typedef address-family { 809 type enumeration { 810 enum other { 811 value "0"; 812 description 813 "none of the following"; 814 } 815 enum ipV4 { 816 value "1"; 817 description 818 "IP Version 4"; 819 } 820 enum ipV6 { 821 value "2"; 822 description 823 "IP Version 6"; 824 } 825 enum nsap { 826 value "3"; 827 description 828 "NSAP"; 829 } 830 enum hdlc { 831 value "4"; 832 description 833 "(8-bit multidrop)"; 834 } 835 enum bbn1822 { 836 value "5"; 837 description 838 "BBN Report 1822"; 839 } 840 enum all802 { 841 value "6"; 842 description 843 "(includes all 802 media plus Ethernet 'canonical 844 format')"; 845 } 846 enum e163 { 847 value "7"; 848 description 849 "E.163"; 850 } 851 enum e164 { 852 value "8"; 853 description 854 "(SMDS, FrameRelay, ATM)"; 855 } 856 enum f69 { 857 value "9"; 858 description 859 "(Telex)"; 860 } 861 enum x121 { 862 value "10"; 863 description 864 "(X.25, Frame Relay)"; 865 } 866 enum ipx { 867 value "11"; 868 description 869 "IPX (Internet Protocol Exchange)"; 870 } 871 enum appleTalk { 872 value "12"; 873 description 874 "Apple Talk"; 875 } 876 enum decnetIV { 877 value "13"; 878 description 879 "DEC Net Phase IV"; 880 } 881 enum banyanVines { 882 value "14"; 883 description 884 "Banyan Vines"; 885 } 886 enum e164withNsap { 887 value "15"; 888 description 889 "(E.164 with NSAP format subaddress)"; 890 } 891 enum dns { 892 value "16"; 893 description 894 "(Domain Name System)"; 895 } 896 enum distinguishedName { 897 value "17"; 898 description 899 "(Distinguished Name, per X.500)"; 900 } 901 enum asNumber { 902 value "18"; 903 description 904 "(16-bit quantity, per the AS number space)"; 905 } 906 enum xtpOverIPv4 { 907 value "19"; 908 description 909 "XTP over IP version 4"; 910 } 911 enum xtpOverIpv6 { 912 value "20"; 913 description 914 "XTP over IP version 6"; 915 } 916 enum xtpNativeModeXTP { 917 value "21"; 918 description 919 "XTP native mode XTP"; 920 } 921 enum fibreChannelWWPN { 922 value "22"; 923 description 924 "Fibre Channel World-Wide Port Name"; 925 } 926 enum fibreChannelWWNN { 927 value "23"; 928 description 929 "Fibre Channel World-Wide Node Name"; 930 } 931 enum gwid { 932 value "24"; 933 description 934 "Gateway Identifier"; 935 } 936 enum afi { 937 value "25"; 938 description 939 "AFI for L2VPN"; 940 } 941 } 942 description 943 "This typedef is a YANG enumeration of IANA-registered address 944 family numbers (AFN)."; 945 reference 946 "Address Family Numbers. IANA, 2011-01-20. 947 950 IANA-ADDRESS-FAMILY-NUMBERS-MIB DEFINITIONS 951 952 "; 953 } 955 typedef subsequent-address-family { 956 type enumeration { 957 enum nlri-unicast { 958 value "1"; 959 description 960 "Network Layer Reachability Information used for unicast 961 forwarding"; 962 reference 963 "RFC4760"; 964 } 965 enum nlri-multicast { 966 value "2"; 967 description 968 "Network Layer Reachability Information used for multicast 969 forwarding"; 970 reference 971 "RFC4760"; 972 } 973 enum nlri-mpls { 974 value "4"; 975 description 976 "Network Layer Reachability Information (NLRI) with MPLS 977 Labels"; 978 reference 979 "RFC3107"; 980 } 981 enum mcast-vpn { 982 value "5"; 983 description 984 "MCAST-VPN"; 986 reference 987 "draft-ietf-l3vpn-2547bis-mcast-bgp-08"; 988 } 989 enum nlri-dynamic-ms-pw { 990 value "6"; 991 status "obsolete"; 992 description 993 "Network Layer Reachability Information used for Dynamic 994 Placement of Multi-Segment Pseudowires (TEMPORARY - 995 Expires 2008-08-23)"; 996 reference 997 "draft-ietf-pwe3-dynamic-ms-pw-13"; 998 } 999 enum tunnel-safi { 1000 value "64"; 1001 description 1002 "Tunnel SAFI"; 1003 reference 1004 "draft-nalawade-kapoor-tunnel-safi-05"; 1005 } 1006 enum vpls { 1007 value "65"; 1008 description 1009 "Virtual Private LAN Service (VPLS)"; 1010 reference 1011 "RFC4761, RFC6074"; 1012 } 1013 enum bgp-mdt { 1014 value "66"; 1015 description 1016 "BGP MDT SAFI"; 1017 reference 1018 "RFC6037"; 1019 } 1020 enum bgp-4over6 { 1021 value "67"; 1022 description 1023 "BGP 4over6 SAFI"; 1024 reference 1025 "RFC5747"; 1026 } 1027 enum bgp-6over4 { 1028 value "68"; 1029 description 1030 "BGP 6over4 SAFI"; 1031 reference 1032 "mailto:cuiyong&tsinghua.edu.cn"; 1033 } 1034 enum l1vpn-auto-discovery { 1035 value "69"; 1036 description 1037 "Layer-1 VPN auto-discovery information"; 1038 reference 1039 "draft-ietf-l1vpn-bgp-auto-discovery-05"; 1040 } 1041 enum mpls-vpn { 1042 value "128"; 1043 description 1044 "MPLS-labeled VPN address"; 1045 reference 1046 "RFC4364"; 1047 } 1048 enum multicast-bgp-mpls-vpn { 1049 value "129"; 1050 description 1051 "Multicast for BGP/MPLS IP Virtual Private Networks 1052 (VPNs)"; 1053 reference 1054 "draft-ietf-l3vpn-2547bis-mcast-10, 1055 draft-ietf-l3vpn-2547bis-mcast-10"; 1056 } 1057 enum route-target-constraints { 1058 value "132"; 1059 description 1060 "Route Target constraints"; 1061 reference 1062 "RFC4684"; 1063 } 1064 enum ipv4-diss-flow { 1065 value "133"; 1066 description 1067 "IPv4 dissemination of flow specification rules"; 1068 reference 1069 "RFC5575"; 1070 } 1071 enum vpnv4-diss-flow { 1072 value "134"; 1073 description 1074 "IPv4 dissemination of flow specification rules"; 1075 reference 1076 "RFC5575"; 1077 } 1078 enum vpn-auto-discovery { 1079 value "140"; 1080 description 1081 "VPN auto-discovery"; 1083 reference 1084 "draft-ietf-l3vpn-bgpvpn-auto-09"; 1085 } 1086 } 1087 description 1088 "This typedef is a YANG enumeration of IANA-registered 1089 subsequent address family identifiers (SAFI)."; 1090 reference 1091 "Subsequent Address Family Identifiers (SAFI) Parameters. IANA, 1092 2011-03-04. 1094 "; 1095 } 1096 } 1098 1100 6. Routing YANG Module 1102 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1103 actual RFC number and all occurrences of the revision date below with 1104 the date of RFC publication (and remove this note). 1106 file "ietf-routing@2012-02-20.yang" 1108 module ietf-routing { 1110 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 1112 prefix "rt"; 1114 import ietf-yang-types { 1115 prefix "yang"; 1116 } 1118 import ietf-interfaces { 1119 prefix "if"; 1120 } 1122 import iana-afn-safi { 1123 prefix "ianaaf"; 1124 } 1126 organization 1127 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1129 contact 1130 "WG Web: 1131 WG List: 1133 WG Chair: David Kessens 1134 1136 WG Chair: Juergen Schoenwaelder 1137 1139 Editor: Ladislav Lhotka 1140 1141 "; 1143 description 1144 "This module contains YANG definitions of essential components 1145 that may be used for configuring a routing subsystem. 1147 Copyright (c) 2012 IETF Trust and the persons identified as 1148 authors of the code. All rights reserved. 1150 Redistribution and use in source and binary forms, with or 1151 without modification, is permitted pursuant to, and subject to 1152 the license terms contained in, the Simplified BSD License set 1153 forth in Section 4.c of the IETF Trust's Legal Provisions 1154 Relating to IETF Documents 1155 (http://trustee.ietf.org/license-info). 1157 This version of this YANG module is part of RFC XXXX; see the 1158 RFC itself for full legal notices. 1159 "; 1161 revision 2012-02-20 { 1162 description 1163 "Initial revision."; 1164 reference 1165 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1166 } 1168 /* Identities */ 1170 identity routing-protocol { 1171 description 1172 "Base identity from which routing protocol identities are 1173 derived."; 1174 } 1176 identity direct { 1177 base routing-protocol; 1178 description 1179 "Routing pseudo-protocol which provides routes to directly 1180 connected networks."; 1181 } 1183 identity static { 1184 base routing-protocol; 1185 description 1186 "Static routing pseudo-protocol."; 1187 } 1189 identity route-filter { 1190 description 1191 "Base identity from which all route filters are derived."; 1192 } 1194 identity deny-all-route-filter { 1195 base route-filter; 1196 description 1197 "Route filter that blocks all routes."; 1198 } 1200 /* Type Definitions */ 1202 typedef router-ref { 1203 type leafref { 1204 path "/rt:routing/rt:router/rt:name"; 1205 } 1206 description 1207 "This type is used for leafs that reference a router 1208 instance."; 1209 } 1211 /* Groupings */ 1213 grouping afn-safi { 1214 leaf address-family { 1215 type ianaaf:address-family; 1216 default "ipV4"; 1217 description 1218 "Address family of routes in the routing table."; 1219 } 1220 leaf safi { 1221 type ianaaf:subsequent-address-family; 1222 default "nlri-unicast"; 1223 description 1224 "Subsequent address family identifier of routes in the 1225 routing table."; 1226 } 1227 description 1228 "This grouping provides two parameters specifying address 1229 family and subsequent address family."; 1230 } 1232 grouping route-content { 1233 description 1234 "Generic parameters of routes. 1236 A module for an address family should define a specific 1237 version of this grouping containing 'uses rt:route-content'. 1238 "; 1239 leaf outgoing-interface { 1240 type if:interface-ref; 1241 description 1242 "Outgoing interface."; 1243 } 1245 } 1247 /* RPC Methods */ 1249 rpc get-route { 1250 description 1251 "Query the forwarding information base of a router instance 1252 whose name is given as the first parameter 'router-name'. The 1253 second parameter 'destination-address' should be augmented in 1254 order to support destination addresses of all supported 1255 address families. The server returns the route which is 1256 currently used for forwarding datagrams to that destination 1257 address, or an error message, if no such route exists."; 1258 input { 1259 leaf router-name { 1260 type router-ref; 1261 mandatory "true"; 1262 description 1263 "First parameter: name of the router instance whose 1264 forwarding information base is queried."; 1265 } 1266 container destination-address { 1267 uses afn-safi; 1268 description 1269 "Second parameter: destination address. 1271 AFN/SAFI-specific modules must augment this container with 1272 a leaf named 'address'. 1273 "; 1274 } 1275 } 1276 output { 1277 container route { 1278 uses afn-safi; 1279 description 1280 "Contents of the reply specific for each address family 1281 should be defined through augmenting."; 1282 } 1283 } 1284 } 1286 /* Data Nodes */ 1288 container routing { 1289 description 1290 "Routing parameters."; 1291 list router { 1292 key "name"; 1293 unique "interfaces/interface/name"; 1294 description 1295 "Each list entry is a container for configuration and 1296 operational state data of a single (logical) router."; 1297 leaf name { 1298 type string; 1299 description 1300 "The unique router name."; 1301 } 1302 leaf description { 1303 type string; 1304 description 1305 "Textual description of the router."; 1306 } 1307 leaf enabled { 1308 type boolean; 1309 default "true"; 1310 description 1311 "Enable or disable the router. The default value is 'true', 1312 which means that the router is enabled."; 1313 } 1314 container interfaces { 1315 description 1316 "Router interface parameters."; 1317 list interface { 1318 key "name"; 1319 description 1320 "List of logical interfaces assigned to the router 1321 instance. Any logical interface can only be assigned to 1322 one router instance."; 1323 leaf name { 1324 type if:interface-ref; 1325 description 1326 "A reference to the name of a configured logical 1327 interface."; 1328 } 1329 } 1330 } 1331 container routing-protocols { 1332 description 1333 "Container for the list of configured routing protocol 1334 instances."; 1335 list routing-protocol { 1336 key "name"; 1337 description 1338 "An instance of a routing protocol."; 1339 leaf name { 1340 type string; 1341 description 1342 "The name of the routing protocol instance."; 1343 } 1344 leaf description { 1345 type string; 1346 description 1347 "Textual description of the routing protocol 1348 instance."; 1349 } 1350 leaf type { 1351 type identityref { 1352 base routing-protocol; 1353 } 1354 mandatory "true"; 1355 description 1356 "Type of the routing protocol - an identity derived 1357 from the 'routing-protocol' base identity."; 1358 } 1359 container connected-routing-tables { 1360 description 1361 "Container for connected routing tables."; 1362 list routing-table { 1363 must "not(../../../../routing-tables/" 1364 + "routing-table[current()/" 1365 + "preceding-sibling::routing-table/name]/" 1366 + "address-family=../../../../routing-tables/" 1367 + "routing-table[current()/name]/" 1368 + "address-family and ../../../../routing-tables/" 1369 + "routing-table[current()/" 1370 + "preceding-sibling::routing-table/name]/safi=../" 1371 + "../../../routing-tables/routing-table[current()/" 1372 + "name]/safi)" { 1373 error-message 1374 "Each routing protocol may have no more than one 1375 connected routing table for each AFN and SAFI."; 1376 description 1377 "For each AFN/SAFI pair there may be at most one 1378 connected routing table."; 1379 } 1380 key "name"; 1381 description 1382 "List of routing tables to which the routing protocol 1383 instance is connected. 1385 Implementation may provide default routing tables 1386 for some AFN/SAFI pairs, which are used if the 1387 corresponding entry is not configured. 1388 "; 1390 leaf name { 1391 type leafref { 1392 path "../../../../../routing-tables/routing-table/" 1393 + "name"; 1394 } 1395 description 1396 "Reference to an existing routing table."; 1397 } 1398 leaf import-filter { 1399 type leafref { 1400 path "../../../../../route-filters/route-filter/" 1401 + "name"; 1402 } 1403 description 1404 "Reference to a route filter that is used for 1405 filtering routes passed from this routing protocol 1406 instance to the routing table specified by the 1407 'name' sibling node. If this leaf is not present, 1408 the behavior is protocol-specific, but typically 1409 it means that all routes are accepted."; 1410 } 1411 leaf export-filter { 1412 type leafref { 1413 path "../../../../../route-filters/route-filter/" 1414 + "name"; 1415 } 1416 description 1417 "Reference to a route filter that is used for 1418 filtering routes passed from the routing table 1419 specified by the 'name' sibling node to this 1420 routing protocol instance. If this leaf is not 1421 present, the behavior is protocol-specific - 1422 typically it means that all routes are accepted, 1423 except for the 'direct' and 'static' 1424 pseudo-protocols which accept no routes from any 1425 routing table."; 1426 } 1427 } 1428 } 1429 container static-routes { 1430 must "../type='static'" { 1431 error-message 1432 "Static routes may be configured only for 'static' 1433 routing protocol."; 1434 description 1435 "This container is only valid for the 'static' 1436 routing protocol."; 1437 } 1438 description 1439 "Configuration of 'static' pseudo-protocol."; 1440 } 1441 } 1442 } 1443 container route-filters { 1444 description 1445 "Container for configured route filters."; 1446 list route-filter { 1447 key "name"; 1448 description 1449 "Route filters are used for filtering and/or manipulating 1450 routes that are passed between a routing protocol and a 1451 routing table or vice versa, or between two routing 1452 tables. It is expected that other modules augment this 1453 list with contents specific for a particular route 1454 filter type."; 1455 leaf name { 1456 type string; 1457 description 1458 "The name of the route filter."; 1459 } 1460 leaf description { 1461 type string; 1462 description 1463 "Textual description of the route filter."; 1464 } 1465 leaf type { 1466 type identityref { 1467 base route-filter; 1468 } 1469 default "deny-all-route-filter"; 1470 description 1471 "Type of the route-filter - an identity derived from 1472 the 'route-filter' base identity. The default value 1473 represents an all-blocking filter."; 1474 } 1475 } 1476 } 1477 container routing-tables { 1478 description 1479 "Container for configured routing tables."; 1480 list routing-table { 1481 key "name"; 1482 description 1483 "Each entry represents a routing table identified by the 1484 'name' key. All routes in a routing table must have the 1485 same AFN and SAFI."; 1487 leaf name { 1488 type string; 1489 description 1490 "The name of the routing table."; 1491 } 1492 uses afn-safi; 1493 leaf description { 1494 type string; 1495 description 1496 "Textual description of the routing table."; 1497 } 1498 container routes { 1499 config "false"; 1500 description 1501 "Current contents of the routing table (operational 1502 state data)."; 1503 list route { 1504 description 1505 "A routing table entry. This data node must augmented 1506 with information specific for routes of each address 1507 family."; 1508 leaf source-protocol { 1509 type leafref { 1510 path "../../../../../routing-protocols/" 1511 + "routing-protocol/name"; 1512 } 1513 description 1514 "The name of the routing protocol instance from 1515 which the route comes. This routing protocol must 1516 be configured (automatically or manually) in the 1517 device."; 1518 } 1519 leaf last-modified { 1520 type yang:date-and-time; 1521 description 1522 "Time stamp of the last modification of the route. 1523 If the route was never modified, it is the time 1524 when the route was inserted to the routing 1525 table."; 1526 } 1527 } 1528 } 1529 list recipient-routing-tables { 1530 key "recipient-name"; 1531 description 1532 "A list of routing tables that receive routes from this 1533 routing table."; 1534 leaf recipient-name { 1535 type leafref { 1536 path "../../../routing-table/name"; 1537 } 1538 description 1539 "The name of the recipient routing table."; 1540 } 1541 leaf filter { 1542 type leafref { 1543 path "../../../../route-filters/route-filter/name"; 1544 } 1545 description 1546 "A route filter which is applied to the routes passed 1547 on to the recipient routing table."; 1548 } 1549 } 1550 } 1551 } 1552 } 1553 } 1554 } 1556 1558 7. IPv4 Unicast Routing YANG Module 1560 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1561 actual RFC number and all occurrences of the revision date below with 1562 the date of RFC publication (and remove this note). 1564 file "ietf-ipv4-unicast-routing@2012-02-20.yang" 1566 module ietf-ipv4-unicast-routing { 1568 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing"; 1570 prefix "v4ur"; 1572 import ietf-routing { 1573 prefix "rt"; 1574 } 1576 import ietf-inet-types { 1577 prefix "inet"; 1578 } 1580 organization 1581 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1583 contact 1584 "WG Web: 1585 WG List: 1587 WG Chair: David Kessens 1588 1590 WG Chair: Juergen Schoenwaelder 1591 1593 Editor: Ladislav Lhotka 1594 1595 "; 1597 description 1598 "This module augments the 'ietf-routing' module with YANG 1599 definitions for basic configuration of IPv4 unicast routing. 1601 Copyright (c) 2012 IETF Trust and the persons identified as 1602 authors of the code. All rights reserved. 1604 Redistribution and use in source and binary forms, with or 1605 without modification, is permitted pursuant to, and subject to 1606 the license terms contained in, the Simplified BSD License set 1607 forth in Section 4.c of the IETF Trust's Legal Provisions 1608 Relating to IETF Documents 1609 (http://trustee.ietf.org/license-info). 1611 This version of this YANG module is part of RFC XXXX; see the 1612 RFC itself for full legal notices. 1613 "; 1615 revision 2012-02-20 { 1616 description 1617 "Initial revision."; 1618 reference 1619 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1620 } 1622 /* Groupings */ 1624 grouping route-content { 1625 description 1626 "Parameters of IPv4 unicast routes."; 1627 uses rt:route-content; 1628 leaf dest-prefix { 1629 type inet:ipv4-prefix; 1630 description 1631 "IPv4 destination prefix."; 1632 } 1633 leaf next-hop { 1634 type inet:ipv4-address; 1635 description 1636 "IPv4 address of the next hop."; 1637 } 1638 } 1640 /* RPC Methods */ 1642 augment "/rt:get-route/rt:input/rt:destination-address" { 1643 when "address-family='ipV4' and safi='nlri-unicast'" { 1644 description 1645 "This augment is valid only for IPv4 unicast."; 1646 } 1647 description 1648 "The 'address' leaf augments the 'rt:destination-address' 1649 parameter of the 'rt:get-route' operation."; 1650 leaf address { 1651 type inet:ipv4-address; 1652 description 1653 "IPv4 destination address."; 1655 } 1656 } 1658 augment "/rt:get-route/rt:output/rt:route" { 1659 when "address-family='ipV4' and safi='nlri-unicast'" { 1660 description 1661 "This augment is valid only for IPv4 unicast."; 1662 } 1663 description 1664 "Contents of the reply to 'rt:get-route' operation."; 1665 uses route-content; 1666 } 1668 /* Data nodes */ 1670 augment "/rt:routing/rt:router/rt:routing-protocols/" 1671 + "rt:routing-protocol/rt:static-routes" { 1672 description 1673 "This augment defines the configuration of the 'static' 1674 pseudo-protocol with data specific for IPv4 unicast."; 1675 container ipv4 { 1676 description 1677 "Configuration of a 'static' pseudo-protocol instance 1678 consists of a list of routes."; 1679 list route { 1680 key "seqno"; 1681 ordered-by "user"; 1682 description 1683 "A user-ordered list of static routes."; 1684 leaf seqno { 1685 type uint16; 1686 description 1687 "Sequential number of the route."; 1688 } 1689 leaf description { 1690 type string; 1691 description 1692 "Textual description of the route."; 1693 } 1694 uses route-content; 1695 } 1696 } 1697 } 1699 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 1700 + "rt:routes/rt:route" { 1701 when "../../rt:address-family='ipV4' and " 1702 + "../../rt:safi='nlri-unicast'" { 1704 description 1705 "This augment is valid only for IPv4 unicast."; 1706 } 1707 description 1708 "This augment defines the content of IPv4 unicast routes."; 1709 uses route-content; 1710 } 1711 } 1713 1715 8. IPv6 Unicast Routing YANG Module 1717 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 1718 actual RFC number and all occurrences of the revision date below with 1719 the date of RFC publication (and remove this note). 1721 file "ietf-ipv6-unicast-routing@2012-02-20.yang" 1723 module ietf-ipv6-unicast-routing { 1725 namespace "urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing"; 1727 prefix "v6ur"; 1729 import ietf-routing { 1730 prefix "rt"; 1731 } 1733 import ietf-inet-types { 1734 prefix "inet"; 1735 } 1737 import ietf-interfaces { 1738 prefix "if"; 1739 } 1741 import ietf-ip { 1742 prefix "ip"; 1743 } 1745 organization 1746 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 1748 contact 1749 "WG Web: 1750 WG List: 1752 WG Chair: David Kessens 1753 1755 WG Chair: Juergen Schoenwaelder 1756 1758 Editor: Ladislav Lhotka 1759 1760 "; 1762 description 1763 "This module augments the 'ietf-routing' module with YANG 1764 definitions for basic configuration of IPv6 unicast routing. 1766 Copyright (c) 2012 IETF Trust and the persons identified as 1767 authors of the code. All rights reserved. 1769 Redistribution and use in source and binary forms, with or 1770 without modification, is permitted pursuant to, and subject to 1771 the license terms contained in, the Simplified BSD License set 1772 forth in Section 4.c of the IETF Trust's Legal Provisions 1773 Relating to IETF Documents 1774 (http://trustee.ietf.org/license-info). 1776 This version of this YANG module is part of RFC XXXX; see the 1777 RFC itself for full legal notices. 1778 "; 1780 revision 2012-02-20 { 1781 description 1782 "Initial revision."; 1783 reference 1784 "RFC XXXX: A YANG Data Model for Routing Configuration"; 1785 } 1787 /* Groupings */ 1789 grouping route-content { 1790 description 1791 "Specific parameters of IPv6 unicast routes."; 1792 uses rt:route-content; 1793 leaf dest-prefix { 1794 type inet:ipv6-prefix; 1795 description 1796 "IPv6 destination prefix."; 1797 } 1798 leaf next-hop { 1799 type inet:ipv6-address; 1800 description 1801 "IPv6 address of the next hop."; 1802 } 1803 } 1805 /* RPC Methods */ 1807 augment "/rt:get-route/rt:input/rt:destination-address" { 1808 when "address-family='ipV6' and safi='nlri-unicast'" { 1809 description 1810 "This augment is valid only for IPv6 unicast."; 1812 } 1813 description 1814 "The 'address' leaf augments the 'rt:destination-address' 1815 parameter of the 'rt:get-route' operation."; 1816 leaf address { 1817 type inet:ipv6-address; 1818 description 1819 "IPv6 destination address."; 1820 } 1821 } 1823 augment "/rt:get-route/rt:output/rt:route" { 1824 when "address-family='ipV6' and safi='nlri-unicast'" { 1825 description 1826 "This augment is valid only for IPv6 unicast."; 1827 } 1828 description 1829 "Contents of the reply to 'rt:get-route' operation."; 1830 uses route-content; 1831 } 1833 /* Data nodes */ 1835 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 1836 when "/if:interfaces/if:interface[name=current()/name] " 1837 + "/ip:ipv6/ip:enabled='true'" { 1838 description 1839 "This augment is only valid for router interfaces with 1840 enabled IPv6. 1842 NOTE: Parameter 'is-router' is not included, it is expected 1843 that it will be implemented by the 'ietf-ip' module. 1844 "; 1845 } 1846 description 1847 "IPv6-specific parameters of router interfaces."; 1848 container ipv6-router-advertisements { 1849 description 1850 "Parameters of IPv6 Router Advertisements."; 1851 reference 1852 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6). 1854 RFC 4862: IPv6 Stateless Address Autoconfiguration. 1855 "; 1856 leaf send-advertisements { 1857 type boolean; 1858 default "false"; 1859 description 1860 "A flag indicating whether or not the router sends periodic 1861 Router Advertisements and responds to Router 1862 Solicitations."; 1863 } 1864 leaf max-rtr-adv-interval { 1865 type uint16 { 1866 range "4..1800"; 1867 } 1868 units "seconds"; 1869 default "600"; 1870 description 1871 "The maximum time allowed between sending unsolicited 1872 multicast Router Advertisements from the interface."; 1873 } 1874 leaf min-rtr-adv-interval { 1875 type uint16 { 1876 range "3..1350"; 1877 } 1878 units "seconds"; 1879 description 1880 "The minimum time allowed between sending unsolicited 1881 multicast Router Advertisements from the interface. 1883 Must be no greater than 0.75 * max-rtr-adv-interval. 1885 Its default value is dynamic: 1887 - if max-rtr-adv-interval >= 9 seconds, the default value 1888 is 0.33 * max-rtr-adv-interval; 1890 - otherwise it is max-rtr-adv-interval. 1891 "; 1892 } 1893 leaf managed-flag { 1894 type boolean; 1895 default "false"; 1896 description 1897 "The boolean value to be placed in the 'Managed address 1898 configuration' flag field in the Router Advertisement."; 1899 } 1900 leaf other-config-flag { 1901 type boolean; 1902 default "false"; 1903 description 1904 "The boolean value to be placed in the 'Other 1905 configuration' flag field in the Router Advertisement."; 1906 } 1907 leaf link-mtu { 1908 type uint32; 1909 default "0"; 1910 description 1911 "The value to be placed in MTU options sent by the router. 1912 A value of zero indicates that no MTU options are sent."; 1913 } 1914 leaf reachable-time { 1915 type uint32 { 1916 range "0..3600000"; 1917 } 1918 units "milliseconds"; 1919 default "0"; 1920 description 1921 "The value to be placed in the Reachable Time field in the 1922 Router Advertisement messages sent by the router. The 1923 value zero means unspecified (by this router)."; 1924 } 1925 leaf retrans-timer { 1926 type uint32; 1927 units "milliseconds"; 1928 default "0"; 1929 description 1930 "The value to be placed in the Retrans Timer field in the 1931 Router Advertisement messages sent by the router. The 1932 value zero means unspecified (by this router)."; 1933 } 1934 leaf cur-hop-limit { 1935 type uint8; 1936 default "64"; 1937 description 1938 "The default value to be placed in the Cur Hop Limit field 1939 in the Router Advertisement messages sent by the router. 1940 The value should be set to the current diameter of the 1941 Internet. The value zero means unspecified (by this 1942 router). 1944 The default should be set to the value specified in IANA 1945 Assigned Numbers that was in effect at the time of 1946 implementation. 1947 "; 1948 reference 1949 "IANA: IP Parameters, 1950 http://www.iana.org/assignments/ip-parameters"; 1951 } 1952 leaf default-lifetime { 1953 type uint16 { 1954 range "0..9000"; 1955 } 1956 units "seconds"; 1957 description 1958 "The value to be placed in the Router Lifetime field of 1959 Router Advertisements sent from the interface, in seconds. 1960 MUST be either zero or between MaxRtrAdvInterval and 9000 1961 seconds. A value of zero indicates that the router is not 1962 to be used as a default router. These limits may be 1963 overridden by specific documents that describe how IPv6 1964 operates over different link layers. 1966 The default value is dynamic and should be set to 3 * 1967 max-rtr-adv-interval. 1968 "; 1969 } 1970 container prefix-list { 1971 description 1972 "A list of prefixes to be placed in Prefix Information 1973 options in Router Advertisement messages sent from the 1974 interface. 1976 Default: all prefixes that the router advertises via 1977 routing protocols as being on-link for the interface from 1978 which the advertisement is sent. The link-local prefix 1979 should not be included in the list of advertised prefixes. 1980 "; 1981 list prefix { 1982 key "seqno"; 1983 unique "prefix-spec"; 1984 description 1985 "Advertised prefix entry."; 1986 leaf seqno { 1987 type uint8; 1988 description 1989 "Sequential number of the entry."; 1990 } 1991 leaf prefix-spec { 1992 type inet:ipv6-prefix; 1993 description 1994 "IPv6 address prefix."; 1995 } 1996 leaf valid-lifetime { 1997 type uint32; 1998 units "seconds"; 1999 default "2592000"; 2000 description 2001 "The value to be placed in the Valid Lifetime in the 2002 Prefix Information option, in seconds. The designated 2003 value of all 1's (0xffffffff) represents infinity. 2005 Implementations may allow valid-lifetime to be 2006 specified in two ways: 2008 1. a time that decrements in real time, that is, one 2009 that will result in a Lifetime of zero at the 2010 specified time in the future, 2012 2. a fixed time that stays the same in consecutive 2013 advertisements. 2014 "; 2015 } 2016 leaf on-link-flag { 2017 type boolean; 2018 default "true"; 2019 description 2020 "The value to be placed in the on-link flag ('L-bit') 2021 field in the Prefix Information option."; 2022 } 2023 leaf preferred-lifetime { 2024 type uint32; 2025 units "seconds"; 2026 default "604800"; 2027 description 2028 "The value to be placed in the Preferred Lifetime in 2029 the Prefix Information option, in seconds. The 2030 designated value of all 1's (0xffffffff) represents 2031 infinity. 2033 Implementations MAY allow AdvPreferredLifetime to be 2034 specified in two ways: 2036 1. a time that decrements in real time, that is, one 2037 that will result in a Lifetime of zero at a 2038 specified time in the future, 2040 2. a fixed time that stays the same in consecutive 2041 advertisements. 2042 "; 2043 } 2044 leaf autonomous-flag { 2045 type boolean; 2046 default "true"; 2047 description 2048 "The value to be placed in the Autonomous Flag field in 2049 the Prefix Information option."; 2050 } 2051 } 2052 } 2054 } 2055 } 2057 augment "/rt:routing/rt:router/rt:routing-protocols/" 2058 + "rt:routing-protocol/rt:static-routes" { 2059 description 2060 "This augment defines the configuration of the 'static' 2061 pseudo-protocol with data specific for IPv6 unicast."; 2062 container ipv6 { 2063 description 2064 "Configuration of a 'static' pseudo-protocol instance 2065 consists of a list of routes."; 2066 list route { 2067 key "seqno"; 2068 ordered-by "user"; 2069 description 2070 "A user-ordered list of static routes."; 2071 leaf seqno { 2072 type uint16; 2073 description 2074 "Sequential number of the route."; 2075 } 2076 leaf description { 2077 type string; 2078 description 2079 "Textual description of the route."; 2080 } 2081 uses route-content; 2082 } 2083 } 2084 } 2086 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 2087 + "rt:routes/rt:route" { 2088 when "../../rt:address-family='ipV6' and " 2089 + "../../rt:safi='nlri-unicast'" { 2090 description 2091 "This augment is valid only for IPv6 unicast."; 2092 } 2093 description 2094 "This augment defines the content of IPv6 unicast routes."; 2095 uses route-content; 2096 } 2097 } 2099 2101 9. IANA Considerations 2103 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 2104 actual RFC number (and remove this note). 2106 This document registers the following namespace URIs in the IETF XML 2107 registry [RFC3688]: 2109 ---------------------------------------------------------- 2110 URI: urn:ietf:params:xml:ns:yang:ietf-routing 2112 Registrant Contact: The IESG. 2114 XML: N/A, the requested URI is an XML namespace. 2115 ---------------------------------------------------------- 2117 ---------------------------------------------------------- 2118 URI: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2120 Registrant Contact: The IESG. 2122 XML: N/A, the requested URI is an XML namespace. 2123 ---------------------------------------------------------- 2125 ---------------------------------------------------------- 2126 URI: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2128 Registrant Contact: The IESG. 2130 XML: N/A, the requested URI is an XML namespace. 2131 ---------------------------------------------------------- 2133 ---------------------------------------------------------- 2134 URI: urn:ietf:params:xml:ns:yang:iana-afn-safi 2136 Registrant Contact: IANA. 2138 XML: N/A, the requested URI is an XML namespace. 2139 ---------------------------------------------------------- 2141 This document registers the following YANG modules in the YANG Module 2142 Names registry [RFC6020]: 2144 ------------------------------------------------------------------- 2145 name: ietf-routing 2146 namespace: urn:ietf:params:xml:ns:yang:ietf-routing 2147 prefix: rt 2148 reference: RFC XXXX 2149 ------------------------------------------------------------------- 2151 ------------------------------------------------------------------- 2152 name: ietf-ipv4-unicast-routing 2153 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing 2154 prefix: v4ur 2155 reference: RFC XXXX 2156 ------------------------------------------------------------------- 2158 ------------------------------------------------------------------- 2159 name: ietf-ipv6-unicast-routing 2160 namespace: urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing 2161 prefix: v6ur 2162 reference: RFC XXXX 2163 ------------------------------------------------------------------- 2165 ------------------------------------------------------------------- 2166 name: iana-afn-safi 2167 namespace: urn:ietf:params:xml:ns:yang:iana-afn-safi 2168 prefix: ianaaf 2169 reference: RFC XXXX 2170 ------------------------------------------------------------------- 2172 10. Security Considerations 2174 The YANG modules defined in this document are designed to be accessed 2175 via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 2176 secure transport layer and the mandatory-to-implement secure 2177 transport is SSH [RFC6242]. 2179 A number of data nodes defined in the YANG modules are writable/ 2180 creatable/deletable (i.e., "config true" in YANG terms, which is the 2181 default). These data nodes may be considered sensitive or vulnerable 2182 in some network environments. Write operations to these data nodes, 2183 such as "edit-config", can have negative effects on the network if 2184 the operations are not properly protected. 2186 The vulnerable "config true" subtrees and data nodes are the 2187 following: 2189 /rt:routing/rt:router/rt:interfaces/rt:interface This list assigns a 2190 logical interface to a router instance and may also specify 2191 interface parameters related to routing. 2193 /rt:routing/rt:router/rt:routing-protocols/rt:routing-protocol This 2194 list specifies the routing protocols configured on a device. 2196 /rt:routing/rt:router/rt:route-filters/rt:route-filter This list 2197 specifies the configured route filters which represent the 2198 administrative policies for redistributing and modifying routing 2199 information. 2201 Unauthorized access to any of these lists can adversely affect the 2202 routing subsystem of both the local device and the network. This may 2203 lead to network malfunctions, delivery of packets to inappropriate 2204 destinations and other problems. 2206 11. Acknowledgments 2208 The author wishes to thank Martin Bjorklund, Joel Halpern, Tom Petch 2209 and Juergen Schoenwaelder for their helpful comments and suggestions. 2211 12. References 2213 12.1. Normative References 2215 [IANA-AFN] 2216 IANA, "Address Family Numbers.", January 2011. 2218 [IANA-SAFI] 2219 IANA, "Subsequent Address Family Identifiers (SAFI) 2220 Parameters.", March 2011. 2222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2223 Requirement Levels", BCP 14, RFC 2119, March 1997. 2225 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2226 January 2004. 2228 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2229 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2230 September 2007. 2232 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 2233 Network Configuration Protocol (NETCONF)", RFC 6020, 2234 September 2010. 2236 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 2237 RFC 6021, September 2010. 2239 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 2240 Bierman, "NETCONF Configuration Protocol", RFC 6241, 2241 June 2011. 2243 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 2244 Configuration", draft-ietf-netmod-interfaces-cfg-03 (work 2245 in progress), February 2012. 2247 [YANG-IP] Bjorklund, M., "A YANG Data Model for IP Configuration", 2248 draft-ietf-netmod-ip-cfg-02 (work in progress), 2249 February 2012. 2251 12.2. Informative References 2253 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 2254 Data Model Documents", RFC 6087, January 2011. 2256 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 2257 Shell (SSH)", RFC 6242, June 2011. 2259 Appendix A. Example: Adding a New Routing Protocol 2261 This appendix demonstrates how the core routing data model can be 2262 extended to support a new routing protocol. The YANG module 2263 "example-rip" shown below is intended only as an illustration rather 2264 than a real definition of a data model for the RIP routing protocol. 2265 For the sake of brevity, we do not follow all the guidelines 2266 specified in [RFC6087]. See also Section 4.4.1. 2268 file "example-rip@2012-02-20.yang" 2270 module example-rip { 2272 namespace "http://example.com/rip"; 2274 prefix "rip"; 2276 import ietf-routing { 2277 prefix "rt"; 2278 } 2280 identity rip { 2281 base rt:routing-protocol; 2282 description 2283 "Identity for the RIP routing protocol."; 2284 } 2286 typedef rip-metric { 2287 type uint8 { 2288 range "0..16"; 2289 } 2290 } 2292 grouping route-content { 2293 description 2294 "RIP-specific route content."; 2295 leaf metric { 2296 type rip-metric; 2297 } 2298 leaf tag { 2299 type uint16; 2300 default "0"; 2301 description 2302 "This leaf may be used to carry additional info, e.g. AS 2303 number."; 2304 } 2305 } 2306 augment "/rt:routing/rt:router/rt:routing-tables/rt:routing-table/" 2307 + "rt:routes/rt:route" { 2308 when "../../../../rt:routing-protocols/" 2309 + "rt:routing-protocol[rt:name=current()/rt:source-protocol]/" 2310 + "rt:type='rip:rip'" { 2311 description 2312 "This augment is only valid if the source protocol from which 2313 the route originated is RIP."; 2314 } 2315 description 2316 "RIP-specific route components."; 2317 uses route-content; 2318 } 2320 augment "/rt:get-route/rt:output/rt:route" { 2321 description 2322 "Add RIP-specific route content."; 2323 uses route-content; 2324 } 2326 augment "/rt:routing/rt:router/rt:interfaces/rt:interface" { 2327 when "../../rt:routing-protocols/rt:routing-protocol/rt:type = " 2328 + "'rip:rip'"; 2329 container rip { 2330 description 2331 "Per-interface RIP configuration."; 2332 leaf enabled { 2333 type boolean; 2334 default "true"; 2335 } 2336 leaf metric { 2337 type rip-metric; 2338 default "1"; 2339 } 2340 } 2341 } 2343 augment "/rt:routing/rt:router/rt:routing-protocols/" 2344 + "rt:routing-protocol" { 2345 when "rt:type = 'rip:rip'"; 2346 container rip { 2347 leaf update-interval { 2348 type uint8 { 2349 range "10..60"; 2350 } 2351 units "seconds"; 2352 default "30"; 2353 description 2354 "Time interval between periodic updates."; 2355 } 2356 } 2357 } 2358 } 2360 2362 Appendix B. Example: Reply to the NETCONF Message 2364 This section contains a sample reply to the NETCONF message, 2365 which could be sent by a server supporting (i.e., advertising them in 2366 the NETCONF message) the following YANG modules: 2368 o ietf-interfaces [YANG-IF], 2370 o ex-ethernet [YANG-IF], 2372 o ietf-ip [YANG-IP], 2374 o ietf-routing (Section 6), 2376 o ietf-ipv4-unicast-routing (Section 7), 2378 o ietf-ipv6-unicast-routing (Section 8). 2380 We assume a simple network setup as shown in Figure 3: router "A" 2381 uses static default routes with the "ISP" router as the next hop. 2382 IPv6 router advertisements are configured only on the "eth1" 2383 interface and disabled on the upstream "eth0" interface. 2385 +-----------------+ 2386 | | 2387 | Router ISP | 2388 | | 2389 +--------+--------+ 2390 |2001:db8:0:1::2 2391 |192.0.2.2 2392 | 2393 | 2394 |2001:db8:0:1::1 2395 eth0|192.0.2.1 2396 +--------+--------+ 2397 | | 2398 | Router A | 2399 | | 2400 +--------+--------+ 2401 eth1|198.51.100.1 2402 |2001:db8:0:2::1 2403 | 2405 Figure 3: Example network configuration 2407 Router "A" then could send the following XML document as its reply to 2408 the NETCONF message: 2410 2411 2420 2421 2422 2423 eth0 2424 ethernetCsmacd 2425 05:00.0 2426 2427 2428 192.0.2.1 2429 24 2430 2431 2432 2433 2434 2001:0db8:0:1::1 2435 64 2436 2437 2438 false 2439 2440 2441 2442 2443 eth1 2444 ethernetCsmacd 2445 05:00.1 2446 2447 2448 198.51.100.1 2449 24 2450 2451 2452 2453 2454 2001:0db8:0:2::1 2455 64 2456 2457 2458 false 2459 2460 2461 2462 2463 2464 2465 rtr0 2466 2467 2468 eth0 2469 2470 2471 eth1 2472 2473 true 2474 2475 2476 1 2477 2001:db8:0:2::/64 2478 2479 2480 2481 2482 2483 2484 2485 direct 2486 rt:direct 2487 2488 2489 st0 2490 2491 Static routing is used for the internal network. 2492 2493 rt:static 2494 2495 2496 2497 1 2498 0.0.0.0/0 2499 192.0.2.2 2500 2501 2502 2503 2504 1 2505 ::/0 2506 2001:db8:0:1::2 2507 2508 2509 2510 2511 2512 ipv4-unicast-main 2513 2514 2515 ipv6-unicast-main 2516 2517 2518 2519 2520 2521 2522 ipv4-unicast-fib 2523 2524 2525 192.0.2.1/24 2526 eth0 2527 direct 2528 2012-02-20T17:11:27+01:00 2529 2530 2531 198.51.100.0/24 2532 eth1 2533 direct 2534 2012-02-20T17:11:27+01:00 2535 2536 2537 0.0.0.0/0 2538 192.0.2.2 2539 st0 2540 2012-02-20T18:02:45+01:00 2541 2542 2543 2544 2545 ipv6-unicast-fib 2546 ipV6 2547 nlri-unicast 2548 2549 2550 2001:db8:0:1::/64 2551 eth0 2552 direct 2553 2012-02-20T17:11:27+01:00 2555 2556 2557 2001:db8:0:2::/64 2558 eth1 2559 direct 2560 2012-02-20T17:11:27+01:00 2561 2562 2563 ::/0 2564 2001:db8:0:1::2 2565 st0 2566 2012-02-20T18:02:45+01:00 2567 2568 2569 2570 2571 ipv4-unicast-main 2572 2573 ipv4-unicast-fib 2574 2575 2576 2577 0.0.0.0/0 2578 st0 2579 192.0.2.2 2580 2012-02-20T18:02:45+01:00 2581 2582 2583 2584 2585 ipv6-unicast-main 2586 ipV6 2587 nlri-unicast 2588 2589 ipv6-unicast-fib 2590 2591 2592 2593 ::/0 2594 2001:db8:0:1::2 2595 st0 2596 2012-02-20T18:02:45+01:00 2597 2598 2599 2600 2601 2602 2604 2605 2607 Appendix C. Change Log 2609 RFC Editor: remove this section upon publication as an RFC. 2611 C.1. Changes Between Versions -01 and -02 2613 o Added module "ietf-ipv6-unicast-routing". 2615 o The example in Appendix B now uses IP addresses from blocks 2616 reserved for documentation. 2618 o Direct routes appear by default in the FIB table. 2620 o Logical interfaces must be assigned to a router instance. 2621 Additional interface configuration may be present. 2623 o The "when" statement is only used with "augment", "must" is used 2624 elsewhere. 2626 o Additional "must" statements were added. 2628 o The "route-content" grouping for IPv4 and IPv6 unicast now 2629 includes the material from the "ietf-routing" version via "uses 2630 rt:route-content". 2632 o Explanation of symbols in the tree representation of data model 2633 hierarchy. 2635 C.2. Changes Between Versions -00 and -01 2637 o AFN/SAFI-independent stuff was moved to the "ietf-routing" module. 2639 o Typedefs for AFN and SAFI were placed in a separate "iana-afn- 2640 safi" module. 2642 o Names of some data nodes were changed, in particular "routing- 2643 process" is now "router". 2645 o The restriction of a single AFN/SAFI per router was lifted. 2647 o RPC operation "delete-route" was removed. 2649 o Illegal XPath references from "get-route" to the datastore were 2650 fixed. 2652 o Section "Security Considerations" was written. 2654 Author's Address 2656 Ladislav Lhotka 2657 CZ.NIC 2659 Email: lhotka@nic.cz