idnits 2.17.1 draft-acee-rtgwg-yang-rib-extend-06.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ROUTING-CFG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 8, 2018) is 2298 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) ** Obsolete normative reference: RFC 8022 (ref. 'ROUTING-CFG') (Obsoleted by RFC 8349) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem 3 Internet-Draft Y. Qu 4 Intended status: Standards Track Cisco Systems 5 Expires: July 12, 2018 January 8, 2018 7 RIB YANG Data Model 8 draft-acee-rtgwg-yang-rib-extend-06.txt 10 Abstract 12 The Routing Information Base (RIB) is a list of routes and their 13 corresponding administrative data and operational state. 15 The document [ROUTING-CFG] defines the basic building blocks for RIB, 16 and this model augments it to support multiple next-hops (aka, paths) 17 for each route as well as additional attributes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 12, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2 55 2. Design of the Model . . . . . . . . . . . . . . . . . . . . . 2 56 2.1. RIB Tags and Preference . . . . . . . . . . . . . . . . . 3 57 2.2. Multiple next-hops . . . . . . . . . . . . . . . . . . . 3 58 2.3. Repair path . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. RIB Model Tree . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. RIB YANG Model . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 65 7.2. Informative References . . . . . . . . . . . . . . . . . 11 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 This document defines a YANG, [YANG], data model which extends the 72 generic data model for RIB by augmenting the ietf-routing model as 73 defined in [ROUTING-CFG]. 75 RIB is a collection of best routes from all routing protocols. 76 Within a protocol routes are selected based on the metrics in use by 77 that protocol, and the protocol install its best routes to RIB. RIB 78 selects the best route by comparing the route preference (aka, 79 administrative distance) of the associated protocol. 81 The augmentations described herein extend the RIB to support multiple 82 paths per route, route metrics, and administrative tags. 84 1.1. Requirements Notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC-KEYWORDS]. 90 2. Design of the Model 92 The YANG definitions in this document augment the ietf-routing model 93 defined in [ROUTING-CFG], which provides a basis for routing system 94 data model development. Together with modules defined in 96 [ROUTING-CFG], a generic RIB Yang model is defined to implement and 97 monitor RIB. 99 The models in [ROUTING-CFG] also define the basic configuration and 100 operational state for both IPv4 and IPv6 static routes and this 101 document also provides augmentations for static routes to support 102 multiple next-hop and more next-hop attributes. 104 2.1. RIB Tags and Preference 106 Individual routes tags will be supported at both the route and next- 107 hop level. A preference per next-hop is also supported for selection 108 of the most prefered reachable static route. 110 2.2. Multiple next-hops 112 Both Ipv4 and IPv6 static route configuration defined in 113 [ROUTING-CFG] have been augmented with a multi-next-hop option. 115 A static route/prefix can be configured to have multiple next-hops, 116 each with their own tag and route preference. 118 In RIB, a route may have multiple next-hops. They can be either 119 equal cost multiple paths (ECMP), or they may have different metrics. 121 2.3. Repair path 123 The loop-free alternate (LFA) Fast Reroute (FRR) pre-computes repair 124 paths by routing protocols, and RIB stores the best repair path. 126 A repair path is augmented in RIB operation state for each path. 128 3. RIB Model Tree 130 A simplified graphical representation of the augmentations described 131 herein is included below. 133 The meaning of the symbols in this diagrams is as follows: 135 o Brackets "[" and "]" enclose list keys. 137 o Curly braces "{" and "}" contain names of optional features that 138 make the corresponding node conditional. 140 o Abbreviations before data node names: "rw" means configuration 141 (read-write), "ro" state data (read-only), "-x" RPC operations, 142 and "-n" notifications. 144 o Symbols after data node names: "?" means an optional node, "!" a 145 container with presence, and "*" denotes a "list" or "leaf-list". 147 o Parentheses enclose choice and case nodes, and case nodes are also 148 marked with a colon (":"). 150 o Ellipsis ("...") stands for contents of subtrees that are not 151 shown. 153 augment /rt:routing/rt:control-plane-protocols 154 /rt:control-plane-protocol/rt:static-routes 155 /v4ur:ipv4/v4ur:route/v4ur:next-hop 156 /v4ur:next-hop-options/v4ur:simple-next-hop: 157 +--rw preference? uint32 158 +--rw tag? uint32 159 augment /rt:routing/rt:control-plane-protocols 160 /rt:control-plane-protocol/rt:static-routes 161 /v4ur:ipv4/v4ur:route/v4ur:next-hop 162 /v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list 163 /v4ur:next-hop: 164 +--rw preference? uint32 165 +--rw tag? uint32 166 augment /rt:routing/rt:control-plane-protocols 167 /rt:control-plane-protocol/rt:static-routes 168 /v6ur:ipv6/v6ur:route/v6ur:next-hop 169 /v6ur:next-hop-options/v6ur:simple-next-hop: 170 +--rw preference? uint32 171 +--rw tag? uint32 172 augment /rt:routing/rt:control-plane-protocols 173 /rt:control-plane-protocol/rt:static-routes 174 /v6ur:ipv6/v6ur:route/v6ur:next-hop 175 /v6ur:next-hop-options/v6ur:next-hop-list/v6ur:next-hop-list 176 /v6ur:next-hop: 177 +--rw preference? uint32 178 +--rw tag? uint32 179 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: 180 +--ro metric? uint32 181 +--ro tag? uint32 182 augment /rt:routing/rt:ribs/rt:rib/rt:routes: 183 +--ro repair-route* [id] 184 +--ro id string 185 +--ro next-hop 186 | +--ro outgoing-interface? if:interface-state-ref 187 | +--ro next-hop-address? inet:ip-address 188 +--ro metric? uint32 189 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route 190 /rt:next-hop/rt:next-hop-options/rt:simple-next-hop: 191 +--ro repair-path? 192 -> /rt:routing/ribs/rib/routes/repair-route/id 193 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route 194 /rt:next-hop/rt:next-hop-options/rt:special-next-hop: 195 +--ro repair-path? 196 -> /rt:routing/ribs/rib/routes/repair-route/id 197 augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route 198 /rt:next-hop/rt:next-hop-options/rt:next-hop-list 199 /rt:next-hop-list/rt:next-hop: 200 +--ro repair-path? 201 -> /rt:routing/ribs/rib/routes/repair-route/id 203 4. RIB YANG Model 205 file "ietf-rib-extension@2017-10-16.yang" 206 module ietf-rib-extension { 207 namespace "urn:ietf:params:xml:ns:yang:ietf-rib-extension"; 209 prefix rib; 211 import ietf-inet-types { 212 prefix "inet"; 213 } 215 import ietf-interfaces { 216 prefix "if"; 217 } 219 import ietf-routing { 220 prefix "rt"; 221 } 223 import ietf-ipv4-unicast-routing { 224 prefix "v4ur"; 225 } 227 import ietf-ipv6-unicast-routing { 228 prefix "v6ur"; 229 } 231 organization 232 "Cisco Systems 233 170 West Tasman Drive 234 San Jose, CA 95134-1706 235 USA"; 236 contact 237 "Acee Lindem - acee@cisco.com 238 Yingzhen QU - yiqu@cisco.com"; 240 description 241 "This YANG module extends the generic data model for 242 RIB by augmenting the ietf-netmod-routing-cfg 243 model. It is intended that the module will be extended 244 by vendors to define vendor-specific RIB parameters. 245 "; 247 revision 2017-10-16 { 248 description 249 "Initial RFC Version"; 250 reference 251 "RFC XXXX: A YANG Data Model for RIB Extensions."; 252 } 254 /* Groupings */ 255 grouping next-hop { 256 description 257 "Next-hop grouping"; 258 leaf interface { 259 type if:interface-ref; 260 description 261 "Outgoing interface"; 262 } 263 leaf address { 264 type inet:ip-address; 265 description 266 "IPv4 or IPv6 Address of the next-hop"; 267 } 268 } 270 grouping attributes { 271 description 272 "Common attributes applicable to all paths"; 273 leaf metric { 274 type uint32; 275 description "Route metric"; 276 } 277 leaf tag { 278 type uint32; 279 description "Route tag"; 280 } 281 } 282 grouping path-attribute { 283 description 284 "Path attribute grouping"; 285 leaf repair-path { 286 type leafref { 287 path "/rt:routing/rt:ribs/rt:rib/" 288 + "rt:routes/repair-route/id"; 289 } 290 description 291 "IP Fast ReRoute (IPFRR) repair path, use a path 292 from repair-route list"; 293 } 294 } 296 augment "/rt:routing/rt:control-plane-protocols/" 297 + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/" 298 + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/" 299 + "v4ur:simple-next-hop" 300 { 301 description 302 "Augment 'simple-next-hop' case in IPv4 unicast route."; 303 leaf preference { 304 type uint32; 305 default "1"; 306 description "Route preference - Used to select among multiple 307 static routes with a lower preference next-hop 308 preferred and equal preference paths yielding 309 Equal Cost Multi-Path (ECMP)."; 310 } 311 leaf tag { 312 type uint32; 313 default "0"; 314 description "Route tag"; 315 } 316 } 318 augment "/rt:routing/rt:control-plane-protocols/" 319 + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/" 320 + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/" 321 + "v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop" 322 { 323 description 324 "Augment static route configuration 'next-hop-list'."; 326 leaf preference { 327 type uint32; 328 default "1"; 329 description "Route preference - Used to select among multiple 330 static routes with a lower preference next-hop 331 preferred and equal preference paths yielding 332 Equal Cost Multi-Path (ECMP)."; 333 } 334 leaf tag { 335 type uint32; 336 default "0"; 337 description "Route tag"; 338 } 339 } 341 augment "/rt:routing/rt:control-plane-protocols/" 342 + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/" 343 + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/" 344 + "v6ur:simple-next-hop" 345 { 346 description 347 "Augment 'simple-next-hop' case in IPv6 unicast route."; 348 leaf preference { 349 type uint32; 350 default "1"; 351 description "Route preference - Used to select among multiple 352 static routes with a lower preference next-hop 353 preferred and equal preference paths yielding 354 Equal Cost Multi-Path (ECMP)."; 355 } 356 leaf tag { 357 type uint32; 358 default "0"; 359 description "Route tag"; 360 } 361 } 363 augment "/rt:routing/rt:control-plane-protocols/" 364 + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/" 365 + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/" 366 + "v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop" 367 { 368 description 369 "Augment static route configuration 'next-hop-list'."; 371 leaf preference { 372 type uint32; 373 default "1"; 374 description "Route preference - Used to select among multiple 375 static routes with a lower preference next-hop 376 preferred and equal preference paths yielding 377 Equal Cost Multi-Path (ECMP)."; 378 } 379 leaf tag { 380 type uint32; 381 default "0"; 382 description "Route tag"; 383 } 385 } 387 augment "/rt:routing/rt:ribs/rt:rib/" 388 + "rt:routes/rt:route" 389 { 390 description 391 "Augment a route in RIB with tag."; 392 uses attributes; 393 } 395 augment "/rt:routing/rt:ribs/rt:rib/" 396 + "rt:routes" 397 { 398 description 399 "Augment a route with a list of repair-paths."; 400 list repair-route { 401 key "id"; 402 description 403 "A repair-path entry, which can be referenced 404 by a repair-path."; 405 leaf id { 406 type string; 407 description 408 "A unique identifier."; 409 } 411 container next-hop { 412 description 413 "Route's next-hop attribute."; 414 leaf outgoing-interface { 415 type if:interface-state-ref; 416 description 417 "Name of the outgoing interface."; 418 } 419 leaf next-hop-address { 420 type inet:ip-address; 421 description 422 "IP address of the next hop."; 423 } 424 } 425 leaf metric { 426 type uint32; 427 description "Route metric"; 428 } 429 } 430 } 432 augment "/rt:routing/rt:ribs/rt:rib/" 433 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 434 + "rt:simple-next-hop" 435 { 436 description 437 "Add more parameters to a path."; 438 uses path-attribute; 439 } 441 augment "/rt:routing/rt:ribs/rt:rib/" 442 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 443 + "rt:special-next-hop" 444 { 445 description 446 "Add more parameters to a path."; 447 uses path-attribute; 448 } 450 augment "/rt:routing/rt:ribs/rt:rib/" 451 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 452 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" 453 { 454 description 455 "This case augments the 'next-hop-options' in the routing 456 model."; 457 uses path-attribute; 458 } 459 } 460 462 5. Security Considerations 464 The YANG model augmentations defined herein do not introduce any 465 security issues other than those already discussed in [ROUTING-CFG], 466 and [NETCONF]. If confidentiality is desired, the underlying NETCONF 467 communication should be utilized as described in [NETCONF-SSH]. 469 6. IANA Considerations 471 This document registers a URI in the IETF XML registry 472 [XML-REGISTRY]. Following the format in RFC 3688, the following 473 registration is requested to be made: 475 URI: urn:ietf:params:xml:ns:yang:ietf-rib 477 Registrant Contact: The IESG. 479 XML: N/A, the requested URI is an XML namespace. 481 This document registers a YANG module in the YANG Module Names 482 registry [YANG]. 484 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-rib 485 prefix: ietf-rib reference: RFC XXXX 487 7. References 489 7.1. Normative References 491 [RFC-KEYWORDS] 492 Bradner, S., "Key words for use in RFC's to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 [ROUTING-CFG] 496 Lhothka, L. and A. Lindem, "A YANG Data Model for Routing 497 Management", RFC 8022, November 2016. 499 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 500 Network Configuration Protocol (NETCONF)", RFC 6020, 501 October 2010. 503 7.2. Informative References 505 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 506 Bierman, "Network Configuration Protocol (NETCONF)", RFC 507 6241, June 2011. 509 [NETCONF-SSH] 510 Wasserman, M., "Using NETCONF Protocol over Secure Shell 511 (SSH)", RFC 6242, June 2011. 513 [XML-REGISTRY] 514 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 515 January 2004. 517 Appendix A. Acknowledgments 519 The RFC text was produced using Marshall Rose's xml2rfc tool. 521 The authors wish to thank Les Ginsberg, Krishna Deevi and Suyoung 522 Yoon for their helpful comments and suggestions. 524 Authors' Addresses 525 Acee Lindem 526 Cisco Systems 527 301 Midenhall Way 528 Cary, NC 27513 529 USA 531 Email: acee@cisco.com 533 Yingzhen Qu 534 Cisco Systems 535 170 West Tasman Drive 536 San Jose, CA 95134 537 USA 539 Email: yiqu@cisco.com