idnits 2.17.1 draft-lhotka-netmod-routing-cfg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (March 03, 2011) is 4800 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4741 (Obsoleted by RFC 6241) ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-INFOSET' -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 March 03, 2011 5 Expires: September 4, 2011 7 A YANG Data Model for Routing Configuration 8 draft-lhotka-netmod-routing-cfg-00 10 Abstract 12 This document contains a specification of a core YANG data model for 13 IP routing configuration. It is expected that this module will serve 14 as a basis for further development of data models for individual 15 routing protocols and other related functions. The present data 16 model defines the building blocks for such configurations - routes 17 and routing tables, routing protocol instances, route filters and 18 route pipes. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 4, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4 56 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Design of the Routing Data Model . . . . . . . . . . . . . . . 7 58 4.1. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.2. Routing Tables . . . . . . . . . . . . . . . . . . . . . . 9 60 4.3. Routing Protocol Instances . . . . . . . . . . . . . . . . 9 61 4.3.1. Defining New Routing Protocols . . . . . . . . . . . . 10 62 4.4. Route Pipes . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.5. Route Filters . . . . . . . . . . . . . . . . . . . . . . 12 64 5. Core Routing YANG Module . . . . . . . . . . . . . . . . . . . 13 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 71 Appendix A. Example Module for Routing Information Protocol . . . 26 72 A.1. Example YANG Module for Routing Information Protocol . . . 26 73 A.2. Sample Reply to the NETCONF Message . . . . . . . . 27 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 76 1. Introduction 78 The NETCONF Data Modeling Language (NETMOD) Working Group has 79 completed the essential specifications for the YANG data modeling 80 language [RFC6020], common data types [RFC6021], and the 81 corresponding data modeling environment and tools [RFC6087], 82 [RFC6110]. The new NETMOD WG charter puts emphasis on the 83 development of a set of core YANG data models for the following 84 subsystems: 86 1. core system data model, 88 2. core interface data model, 90 3. core routing data model. 92 The initial version of the core interface data model (item 2) was 93 already published [YANG-IF]. 95 This document contains an initial specification for item 3, namely 96 the "ietf-routing" YANG module representing the core routing data 97 model. While the module can be directly used for simple devices with 98 static routing, its main purpose is to provide basic building blocks 99 for more complicated setups involving multiple routing protocols and 100 advanced functions, such as route filtering and policy routing. To 101 this end, it is expected that this module will be augmented by 102 numerous modules developed by other IETF working groups. 104 2. Terminology and Notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 The following terms are defined in [RFC4741]: 112 o client 114 o datastore 116 o message 118 o operation 120 o server 122 The following terms are defined in [RFC6020]: 124 o augment 126 o configuration data 128 o container 130 o data model 132 o data node 134 o data tree 136 o data type 138 o feature 140 o grouping 142 o identity 144 o instance identifier 146 o leaf-list 148 o list 150 o mandatory node 151 o module 153 o operational state data 155 o RPC operation 157 o submodule 159 The following terms are defined in [XML-INFOSET]: 161 o attribute 163 o document 165 o document element 167 o element 169 o information set 171 o namespace 173 3. Objectives 175 The initial design of the core routing data model was driven by the 176 following main objectives: 178 o The data model should be suitable for the common address families, 179 in particular IPv4 and IPv6. 181 o Simple routing setups, such as static routing, should be 182 configurable in a simple way, ideally without any need to define 183 additional YANG modules. 185 o On the other hand, the framework defined by the module must allow 186 for complicated setups involving multiple routing tables and 187 multiple routing protocols, as well as controlled redistributions 188 of routing information. 190 o Device vendors will want to map the data models built on this 191 generic framework to their proprietary data models and 192 configuration interfaces. Therefore, the framework should be 193 flexible enough to facilitate such a mapping and accommodate data 194 models with different logic. 196 4. Design of the Routing Data Model 198 The "ietf-routing" YANG module presented in Section 5 defines a data 199 modeling framework with several essential components: routes, routing 200 tables, routing protocol instances, route filters and route pipes. 201 By combining these components in various ways, and filling them with 202 appropriate content models defined in other modules, a broad range of 203 routing setups can be covered. 205 +------------+ 206 | kernel FIB | 207 +------------+ 208 ^ | 209 | v 210 +---+ +---+ 211 | F | | F | 212 +---+ +---+ 213 ^ | 214 | v 215 +--------------+ +---+ +--------------+ 216 +--------+ | |<---| F |<---| | 217 | static | +---+ | main | +---+ | additional | 218 | routes |--->| F |--->| routing | | routing | 219 +--------+ +---+ | table | +---+ | table | 220 | |--->| F |--->| | 221 +--------------+ +---+ +--------------+ 222 ^ | ^ | 223 | v | v 224 +---+ +---+ +---+ +---+ 225 | F | | F | | F | | F | 226 +---+ +---+ +---+ +---+ 227 ^ | ^ | 228 | v | v 229 +----------+ +----------+ 230 | routing | | routing | 231 | protocol | | protocol | 232 +----------+ +----------+ 234 Figure 1: Example setup of the routing subsystem 236 Figure 1 shows an example of a more complicated setup: 238 o Along with the main routing table, which must always be present, 239 an additional routing table is defined. 241 o Each routing protocol instance, including the static pseudo- 242 protocol instance, is connected to exactly one routing table with 243 which it can exchange routes (in both directions, except for the 244 static pseudo-protocol). 246 o Routing tables may also be connected to each other through route 247 pipes and exchange routes in one or both directions. 249 o The main routing table exchanges routes with the forwarding 250 information base (FIB) in the operating system kernel as follows: 251 active routes from the main routing table are installed in the FIB 252 and used for packet forwarding, and automatic routes set up by the 253 kernel (for example, direct routes to connected networks) are 254 passed to the main routing table. 256 o Route exchanges along all connections may be controlled by means 257 of route filters denoted by "F" in the figure. 259 All configuration and operational state data defined by the "ietf- 260 routing" module apear inside the "routing" container. The following 261 subsections describe the individual components of the core routing 262 framework. 264 4.1. Route 266 Routes are basic units of information in a routing system. The 267 "ietf-routing" module defines only the following essential route 268 parameters: 270 o route-type - permitted values are "unicast" (default), "multicast" 271 and "anycast". 273 o destination-prefix - IP prefix specifying the set of destination 274 addresses for which the route may be used. This parameter is 275 mandatory. 277 o next-hop - IP address of the adjacent router or host to which 278 packets with destination addresses belonging to destination-prefix 279 should be sent. 281 o outgoing-interface - network interface that should be used for 282 sending packets with destination addresses belonging to 283 destination-prefix. 285 The above list of route parameters is sufficient for a simple static 286 route configuration. It is expected that future modules defining 287 routing protocols will add other route attributes such as metrics or 288 preferences. 290 Routes are used in both configuration data, for example as manually 291 configured static routes, as well as in operational state data, for 292 example as entries in routing tables. 294 4.2. Routing Tables 296 Routing tables are lists of routes complemented with administrative 297 data, namely: 299 o source-protocol - name of the routing protocol from which the 300 route arrived. 302 o last-modified - date and time of last modification, or 303 installation, of the route. 305 In the core routing data model, routing tables are represented as 306 operational state data. Routing protocol operations result in route 307 additions, removals and modifications. This also includes 308 manipulations via the "static" pseudo-protocol. 310 The data model also defines an RPC operation, "delete-route" which 311 allows the client to immediately delete a specified route from a 312 routing table. 314 Every compliant implementation MUST automatically configure the main 315 routing table. Additional routing tables MAY be configured by adding 316 their unique names to the "configured-routing-tables" leaf-list. 318 4.3. Routing Protocol Instances 320 The "ietf-routing" module provides an open-ended framework for 321 defining multiple routing protocol instances. Each of them is 322 identified by a unique name and MUST be assigned a type from a 323 selection which includes all routing protocol types supported by the 324 server, such as RIP, OSPF or BGP. 326 Each routing protocol instance is connected to exactly one routing 327 table. By default, every routing protocol instance is connected to 328 the main routing table, but any routing protocol instance can be 329 configured to use a different routing table, provided such an extra 330 table is configured. 332 Routes learned from the network by a routing protocol instance are 333 passed to the connected routing table and vice versa - routes 334 appearing in a routing table may be passed to any routing protocol 335 connected to the table and advertised by that protocol to the 336 network. 338 Two independent route filters (see Section 4.5) may be defined for a 339 routing protocol instance to control the exchange of routes in both 340 directions between the routing protocol instance and the connected 341 routing table: 343 o import filter controls which routes are passed from a routing 344 protocol instance to the routing table, 346 o export filter controls which routes the routing protocol instance 347 may receive from the connected routing table. 349 Note that, for historical reasons, the terms import and export are 350 used from the viewpoint of a routing table. 352 The "ietf-routing" module defines two special routing protocols - 353 "direct" and "static". Both are in fact pseudo-protocols, which 354 means that they are confined to the local server and do not exchange 355 any routing information with neighboring routers. Routes from both 356 "direct" and "static" protocol instances are passed to the connected 357 routing table (subject to route filters, if any), but an exchange in 358 the opposite direction is not allowed. 360 The "direct" pseudo-protocol MUST exist in exactly one instance in 361 any server implementation. It is the source for routes to directly 362 connected networks (so-called direct routes). Such routes are 363 supplied by the operating system kernel based on the detected and 364 configured network interfaces, and they usually appear in the main 365 routing table. However, using the framework defined in this 366 document, the target routing table for direct routes can be changed 367 by connecting the "direct" protocol instance to a non-default routing 368 table, and the direct routes can also be filtered before they appear 369 in the routing table. 371 The "static" routing pseudo-protocol allows for specifying routes 372 manually. It can be configured in zero or more instances, although 373 typically one instance suffices. 375 4.3.1. Defining New Routing Protocols 377 It is expected that other YANG modules will create data models for 378 additional routing protocol types. In order to do so, the new module 379 has to define the protocol-specific information and fit it to the 380 core routing framework in the following way: 382 o A new identity MUST be defined for the routing protocol and its 383 base identity set to "routing-protocol", or to an identity derived 384 from "routing-protocol". 386 o Additional route attributes MAY be defined. Their definitions 387 have to be inserted as operational state data by augmenting the 388 definition of "route" under "routing-table". Naturally, routes 389 (including the extra attributes) may be used in configuration 390 data, too, as demonstrated by the "static" pseudo-protocol. 392 o The recommended way of defining configuration data specific to the 393 new protocol is to augment the "routing-protocol-instance" list 394 entry with a container that encapsulates the configuration 395 hierarchy of the new protocol. The 'augment' statement SHOULD be 396 made conditional by using a 'when' substatement requiring that the 397 new nodes be used only if the "type" leaf node is equal to the new 398 protocol's identity. 400 The above steps are implemented by the example YANG module for the 401 RIP routing protocol in Appendix A. In particular, the module first 402 defines a new identity for the RIP protocol: 404 identity rip { 405 base rt:routing-protocol; 406 description "Identity for the RIP routing protocol."; 407 } 409 RIP-specific configuration data are then integrated into the 410 "routing-protocol-instance" node by using the following 'augment' 411 statement, which applies only for routing protocol instances whose 412 type is "rip": 414 augment "/rt:routing/rt:routing-protocol-instances/" + 415 "rt:routing-protocol-instance" { 416 container rip-configuration { 417 when "../rt:type='rip'"; 418 ... 419 } 420 } 422 4.4. Route Pipes 424 Route pipes are unidirectional links connecting pairs of routing 425 tables that allow for passing routes from one routing table to 426 another. Each route pipe is identified by a unique name and has two 427 mandatory parameters, "origin" and "recipient", that specify the two 428 routing tables that are being connected. 430 The transport of routes from the "origin" table to the "recipient" 431 table may be controlled by means of a route filter (see Section 4.5). 432 If no filter is defined, all routes present in the "origin" table 433 MUST also appear in the "recipient" table. 435 4.5. Route Filters 437 The "ietf-routing" module provides a skeleton for defining route 438 filters that can be used to restrict the set of routes being 439 exchanged between a routing protocol instance and a routing table, or 440 between two routing tables connected through a route pipe. Route 441 filters may also manipulate routes, i.e., add, delete, or modify 442 their properties. 444 By itself, the route filtering framework defined in the "ietf- 445 routing" module allows to establish only the two extreme routing 446 policies in which either all routes are allowed or all routes are 447 denied. It is expected that a real route filtering framework (or 448 several alternative frameworks) will be developed separately. 450 Each route filter is identified by a unique name. Its type may be 451 specified by the "type" identity reference - this opens the space for 452 multiple route filtering framework implementations. The only route 453 filter type defined in the "ietf-routing" module carries the default 454 "route-filter" identity, and represents the "deny all" route 455 filtering policy. 457 5. Core Routing YANG Module 458 file "ietf-routing@2011-03-03.yang" 460 module ietf-routing { 461 namespace "urn:ietf:params:xml:ns:yang:ietf-routing"; 462 prefix rt; 464 import ietf-yang-types { 465 prefix yang; 466 } 467 import ietf-inet-types { 468 prefix inet; 469 } 470 import ietf-interfaces { 471 prefix if; 472 } 474 organization 475 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 477 contact 478 "WG Web: 479 WG List: 481 WG Chair: David Kessens 482 484 WG Chair: Juergen Schoenwaelder 485 487 Editor: Ladislav Lhotka 488 "; 490 description 491 "This module contains YANG definitions for basic 492 configuration of IP routing. 494 It is immediately usable for a device that needs just a single 495 routing table populated with static routes. 497 On the other hand, the framework is designed to handle arbitrarily 498 complex configurations with any number of routing tables and 499 various routing protocols (in multiple instances). 501 Every compliant implementation MUST support IPv4 unicast routing 502 and implement at least one (main) routing table, which is 503 connected to the OS kernel forwarding information base."; 505 revision 2011-03-03; 507 /* Features */ 509 feature ipv6-routing { 510 description 511 "This feature MUST be advertised by devices supporting IPv6 512 routing. Such a device MUST implement at least one extra routing 513 table to which all IPv6 unicast routing protocols are connected 514 by default."; 515 } 517 feature ipv4-multicast-routing { 518 description 519 "This feature MUST be set by devices supporting IPv4 520 multicast routing. Such a device MUST implement at least one 521 extra routing table to which all IPv6 multicast routing 522 protocols are connected by default."; 523 } 525 feature ipv6-multicast-routing { 526 description 527 "This feature MUST be set by devices supporting IPv6 528 multicast routing. Such a device MUST implement at least one 529 extra routing table to which all IPv6 multicast routing 530 protocols are connected by default."; 531 } 533 /* Identities */ 535 identity address-family { 536 description 537 "Base identity from which address family identities are 538 derived."; 539 } 541 identity af-ipv4 { 542 base address-family; 543 description 544 "IPv4 address family."; 545 } 547 identity af-ipv6 { 548 base address-family; 549 description 550 "IPv6 address family."; 551 } 552 identity routing-protocol { 553 description 554 "Base identity from which routing protocol identities are 555 derived."; 556 } 558 identity direct { 559 base routing-protocol; 560 description 561 "Identity for the pseudo-protocol providing routes to 562 directly connected networks. An implementation MUST preconfigure 563 an instance of this pseudo-protocol."; 564 } 566 identity static { 567 base routing-protocol; 568 description 569 "Identity for static routing pseudo-protocol."; 570 } 572 identity route-filter { 573 description 574 "Base identity for route filters. It also represents the 575 empty route filter that blocks everything."; 576 } 578 identity route-type { 579 description 580 "Base identity for route types."; 581 } 583 identity unicast { 584 base route-type; 585 description 586 "Unicast route type."; 587 } 589 identity multicast { 590 base route-type; 591 description 592 "Multicast route type."; 593 } 595 identity anycast { 596 base route-type; 597 description 598 "Anycast route type."; 599 } 600 /* Type definitions */ 602 typedef routing-table-ref { 603 type leafref { 604 path "/routing/configured-routing-tables/name"; 605 } 606 description 607 "This type represents a reference to a configured routing 608 table."; 609 } 611 typedef routing-protocol-instance-ref { 612 type leafref { 613 path "/routing/routing-protocol-instances/" + 614 "routing-protocol-instance/name"; 615 } 616 description 617 "This type represents a reference to a configured routing 618 protocol instance."; 619 } 621 typedef route-filter-ref { 622 type leafref { 623 path "/routing/route-filters/route-filter/name"; 624 } 625 description 626 "This type represents a reference to a configured route 627 filter."; 628 } 630 /* Groupings */ 632 grouping ip-route-content { 633 description 634 "Components of an IP route."; 635 leaf type { 636 type identityref { 637 base route-type; 638 } 639 default "unicast"; 640 } 641 leaf destination-prefix { 642 type inet:ip-prefix; 643 mandatory true; 644 description 645 "The set of destination addresses for which the route may 646 be used."; 647 } 648 leaf next-hop { 649 type inet:ip-address; 650 description 651 "IP address of the host or router to which packets whose 652 address matches 'destination-prefix' are to be forwarded."; 653 } 654 leaf outgoing-interface { 655 type if:interface-ref; 656 description 657 "Name of the outgoing interface. This parameter is mainly 658 used in direct routes."; 659 } 660 } 662 rpc delete-route { 663 description 664 "This operation deletes a route with given parameters from 665 a specified routing table. is returned by the server 666 upon successful completion."; 667 input { 668 container route { 669 description 670 "All routes that match this parameter MUST be deleted 671 from the target routing table."; 672 uses ip-route-content; 673 } 674 leaf routing-table { 675 type routing-table-ref; 676 description 677 "This parameter specifies the target routing 678 table."; 679 } 680 } 681 } 683 /* Data tree */ 685 container routing { 686 description 687 "IP routing parameters."; 688 container configured-routing-tables { 689 description 690 "Names of configured routing tables. Their contents are 691 available as operational state data under 'routing-tables'. At 692 least one (main) table MUST be configured for every supported 693 address family. This default routing table is usually 694 connected to the main kernel forwarding table."; 695 leaf-list name { 696 type string; 697 min-elements 1; 698 } 699 } 700 container routing-protocol-instances { 701 description 702 "Container for configured routing protocol instances. 704 Every implementation MUST preconfigure the 'direct' 705 pseudo-protocol instance providing the routes to directly 706 connected networks."; 707 list routing-protocol-instance { 708 key "name"; 709 container static-routes { 710 when "../type='static'"; 711 description 712 "Configuration of a 'static' pseudo-protocol instance 713 consists of a list of routes."; 714 list static-route { 715 key "id"; 716 leaf id { 717 type string; 718 } 719 leaf description { 720 type string; 721 } 722 uses ip-route-content; 723 } 724 } 725 leaf name { 726 type string; 727 } 728 leaf description { 729 type string; 730 } 731 leaf address-family { 732 type identityref { 733 base address-family; 734 } 735 default "af-ipv4"; 736 description 737 "Address family used by the routing protocol instance."; 738 } 739 leaf type { 740 type identityref { 741 base routing-protocol; 742 } 743 mandatory true; 744 description 745 "Type of the routing protocol."; 746 } 747 leaf routing-table { 748 type routing-table-ref; 749 description 750 "The routing table to which the protocol instance is 751 connected. By default it is the main routing table for the 752 given address family."; 753 } 754 leaf import-filter { 755 type route-filter-ref; 756 description 757 "Reference to a route filter that is used for 758 filtering routes passed from this routing protocol instance 759 to the routing table specified by the 'routing-table' 760 sibling node. If this leaf is not present, the behavior is 761 protocol-specific, but typically it means that all routes 762 are accepted."; 763 } 764 leaf export-filter { 765 type route-filter-ref; 766 description 767 "Reference to a route filter that is used for 768 filtering routes passed from the routing table specified 769 by the 'routing-table' sibling to this routing protocol 770 instance. If this leaf is not present, the behavior is 771 protocol-specific - typically it means that all routes 772 are accepted, except for the 'direct' and 'static' 773 pseudo-protocols which accept no routes from 774 anywhere."; 775 } 776 } 777 } 778 container route-pipes { 779 description 780 "Route pipes facilitate transport of routes between pairs 781 of routing tables."; 782 list route-pipe { 783 key "name"; 784 description 785 "A route-pipe is a unidirectional connection between 786 'origin' and 'recipient'."; 787 leaf name { 788 type string; 789 } 790 leaf description { 791 type string; 793 } 794 leaf origin { 795 type routing-table-ref; 796 mandatory true; 797 description 798 "The originating routing-table."; 799 } 800 leaf recipient { 801 type routing-table-ref; 802 mandatory true; 803 description 804 "The receiving routing-table."; 805 } 806 leaf route-filter { 807 type route-filter-ref; 808 description 809 "All routes passing through the route pipe are filtered by 810 the route filter referred to by this leaf. If it is not 811 present, all routes from 'origin' are passed to 812 'destination'."; 813 } 814 } 815 } 816 container route-filters { 817 description 818 "Non-trivial route filters are expected to be defined in 819 other modules."; 820 list route-filter { 821 key "name"; 822 description 823 "A route filter is used for filtering routes between 824 routing protocol instances and routing tables (import 825 filter) and vice versa (export filter), and in route pipes 826 that connect pairs of routing tables."; 827 leaf name { 828 type string; 829 } 830 leaf description { 831 type string; 832 } 833 leaf type { 834 type identityref { 835 base route-filter; 836 } 837 default "route-filter"; 838 description 839 "Type of the route-filter. The default value 840 represents an all-blocking filter."; 842 } 843 } 844 } 846 /* Operational state data */ 848 container routing-tables { 849 config false; 850 description 851 "Routing tables and their contents."; 852 list routing-table { 853 min-elements 1; 854 description 855 "Exactly one routing table MUST be present for every 'name' 856 entry appearing in '/routing/configured-routing-tables'."; 857 leaf name { 858 type routing-table-ref; 859 } 860 leaf address-family { 861 type identityref { 862 base address-family; 863 } 864 default "af-ipv4"; 865 description 866 "Address family of all routes in the routing table."; 867 } 868 list route { 869 leaf source-protocol { 870 type routing-protocol-instance-ref; 871 description 872 "Protocol instance from which the route comes."; 873 } 874 leaf last-modified { 875 type yang:date-and-time; 876 description 877 "Time stamp of the last modification of the 878 route. If the route was never modified, it is the time 879 when the route was inserted to the routing table."; 880 } 881 uses ip-route-content; 882 } 883 } 884 } 885 } 886 } 888 889 6. IANA Considerations 891 This document requests the following registration of a namespace URI 892 in the IETF XML registry [RFC3688]: 894 ----------------------------------------------------- 895 URI: urn:ietf:params:xml:ns:yang:ietf-routing 897 Registrant Contact: The IESG. 899 XML: N/A, the requested URI is an XML namespace. 900 ----------------------------------------------------- 902 7. Security Considerations 904 TBD. 906 8. Acknowledgments 908 The author wishes to thank the following individuals who provided 909 helpful suggestions and/or comments on this document: TBD. 911 9. References 913 9.1. Normative References 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, March 1997. 918 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 919 January 2004. 921 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 922 December 2006. 924 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 925 Network Configuration Protocol (NETCONF)", RFC 6020, 926 September 2010. 928 [RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types", 929 RFC 6021, September 2010. 931 [XML-INFOSET] 932 Tobin, R. and J. Cowan, "XML Information Set (Second 933 Edition)", World Wide Web Consortium Recommendation REC- 934 xml-infoset-20040204, February 2004, 935 . 937 [YANG-IF] Bjorklund, M., "A YANG Data Model for Interface 938 Configuration", draft-bjorklund-netmod-interfaces-cfg-00 939 (work in progress), December 2010. 941 9.2. Informative References 943 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 944 Data Model Documents", RFC 6087, January 2011. 946 [RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema 947 Definition Languages and Validating NETCONF Content", 948 RFC 6110, February 2011. 950 Appendix A. Example Module for Routing Information Protocol 952 This appendix demonstrates how the "ietf-routing" module can be 953 extended to support a new routing protocol. Appendix A.1 contains a 954 YANG module that is used for this purpose. It is intended only as an 955 illustration and not as a real definition of a data model for the RIP 956 routing protocol. This module also imports the "ietf-interfaces" 957 module defined in [YANG-IF]. 959 Appendix A.2 then contains a complete instance XML document - a reply 960 to the NETCONF message from a server that uses the RIP protocol 961 as well as static routing. A route filter is also defined in order 962 to prevent static routes to private networks from being redistributed 963 to RIP. The instance document also uses data nodes from the two 964 example YANG modules "ex-ethernet" and "ex-ip" defined in [YANG-IF]. 966 A.1. Example YANG Module for Routing Information Protocol 968 module example-rip { 969 namespace "http://example.com/rip"; 970 prefix rip; 972 import ietf-interfaces { 973 prefix if; 974 } 975 import ietf-routing { 976 prefix rt; 977 } 979 identity rip { 980 base rt:routing-protocol; 981 description 982 "Identity for the RIP routing protocol."; 983 } 985 typedef rip-metric { 986 type uint8 { 987 range "0..16"; 988 } 989 } 991 augment "/rt:routing/rt:routing-protocol-instances/" + 992 "rt:routing-protocol-instance" { 993 when "rt:type='rip:rip'"; 994 container rip-configuration { 995 container rip-interfaces { 996 list rip-interface { 997 key "name"; 998 leaf name { 999 type if:interface-ref; 1000 } 1001 leaf enabled { 1002 type boolean; 1003 default "true"; 1004 } 1005 leaf metric { 1006 type rip-metric; 1007 default "1"; 1008 } 1009 /* Additional per-interface RIP configuration */ 1010 } 1011 } 1012 leaf update-interval { 1013 type uint8 { 1014 range "10..60"; 1015 } 1016 units "seconds"; 1017 default "30"; 1018 description 1019 "Time interval between periodic updates."; 1020 } 1021 /* Additional RIP configuration */ 1022 } 1023 } 1024 augment "/rt:routing/rt:routing-tables/rt:routing-table/rt:route" { 1025 when "../../../rt:routing-protocol-instances/" + 1026 "rt:routing-protocol-instance[rt:name=" + 1027 "current()/rt:source-protocol]/rt:type='rip:rip'"; 1028 description 1029 "RIP-specific route components."; 1030 leaf metric { 1031 type rip-metric; 1032 } 1033 leaf tag { 1034 type uint16; 1035 default "0"; 1036 description 1037 "This leaf may be used to carry additional info, e.g. AS 1038 number."; 1039 } 1040 } 1041 } 1043 A.2. Sample Reply to the NETCONF Message 1045 1046 1054 1055 1056 1057 eth0 1058 eth:ethernet 1059 05:00.0 1060 1061 1062 192.0.2.1 1063 24 1064 1065 1066 1067 1068 eth1 1069 eth:ethernet 1070 05:00.1 1071 1072 1073 192.168.1.1 1074 24 1075 1076 1077 1078 1079 1080 1081 rt0 1082 1083 1084 1085 direct 1086 direct 1087 1088 1089 st0 1090 1091 Static routing is used for the internal network. 1092 1093 static 1094 1095 1096 id-6378 1097 192.168.2.0/24 1098 192.168.1.254 1099 1100 1101 1102 1103 rip0 1104 rip:rip 1105 to-rip 1106 1107 1108 1109 eth0 1110 1111 1112 1113 1114 1115 1116 1117 to-rip 1118 1119 Block redistribution of static routes. 1120 1121 1122 1123 1124 1125 rt0 1126 1127 192.168.1.0/24 1128 direct 1129 eth0 1130 2010-02-24T17:11:23+01:00 1131 1132 1133 192.168.2.0/24 1134 st0 1135 192.168.1.254 1136 64500 1137 2010-02-24T17:11:27+01:00 1138 1139 1140 0.0.0.0/0 1141 192.0.2.2 1142 2 1143 64500 1144 rip0 1145 2010-03-03T13:00:23+01:00 1146 1147 1148 1149 1150 1151 1153 Author's Address 1155 Ladislav Lhotka 1156 CESNET 1158 Email: lhotka@cesnet.cz