idnits 2.17.1 draft-acee-rtgwg-yang-rib-extend-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 7) being 61 lines 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 (October 28, 2016) is 2735 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) == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-24 Summary: 1 error (**), 0 flaws (~~), 4 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: May 1, 2017 October 28, 2016 7 YANG Data Model for RIB Extensions 8 draft-acee-rtgwg-yang-rib-extend-02.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 repair paths and additional 17 attributes for routes and next-hops (aka, paths). 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 May 1, 2017. 36 Copyright Notice 38 Copyright (c) 2016 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. Static routes . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Repair path . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. RIB Model Tree . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. RIB YANG Model . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 64 7.2. Informative References . . . . . . . . . . . . . . . . . 10 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 This document defines a YANG, [YANG], data model which extends the 71 generic data model for RIB by augmenting the ietf-routing model as 72 defined in [ROUTING-CFG]. 74 RIB is a collection of best routes from all routing protocols. 75 Within a protocol routes are selected based on the metrics in use by 76 that protocol, and the protocol install its best routes to RIB. RIB 77 selects the best route by comparing the route preference (aka, 78 administrative distance) of the associated protocol. 80 The augmentations described herein extend the RIB to support repair 81 paths route metrics, and administrative tags. 83 1.1. Requirements Notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC-KEYWORDS]. 89 2. Design of the Model 91 The YANG definitions in this document augment the ietf-routing model 92 defined in [ROUTING-CFG], which provides a basis for routing system 93 data model development. Together with modules defined in 94 [ROUTING-CFG], a generic RIB Yang model is defined to implement and 95 monitor RIB. 97 The models in [ROUTING-CFG] also define the basic configuration and 98 operational state for both IPv4 and IPv6 static routes and this 99 document also provides augmentations for static routes to support 100 more next-hop attributes. 102 2.1. Static routes 104 Both Ipv4 and IPv6 static route configuration are defined in 105 [ROUTING-CFG] with a multi-next-hop option. 107 A static route/prefix can be configured to have multiple next-hops, 108 each with their own tag and route preference. 110 This model augments both IPv4 and IPv6 static route configuration 111 with tag and route preference. 113 2.2. Next-Hop Repair path 115 IP Fast Reroute repair paths can be pre-computed for route next-hops 116 and installed in a RIB. For example, a routing protocol can install 117 repair paths computed using the LFA (Loop-Free Alternative) 118 computation. 120 A repair path is augmented in RIB operation state for each path. 122 3. RIB Model Tree 124 A simplified graphical representation of the augmentations described 125 herein is included below. 127 The meaning of the symbols in this diagrams is as follows: 129 o Brackets "[" and "]" enclose list keys. 131 o Curly braces "{" and "}" contain names of optional features that 132 make the corresponding node conditional. 134 o Abbreviations before data node names: "rw" means configuration 135 (read-write), "ro" state data (read-only), "-x" RPC operations, 136 and "-n" notifications. 138 o Symbols after data node names: "?" means an optional node, "!" a 139 container with presence, and "*" denotes a "list" or "leaf-list". 141 o Parentheses enclose choice and case nodes, and case nodes are also 142 marked with a colon (":"). 144 o Ellipsis ("...") stands for contents of subtrees that are not 145 shown. 147 module: ietf-rib-extension 148 augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol 149 /rt:static-routes/v4ur:ipv4/v4ur:route/v4ur:next-hop 150 /v4ur:next-hop-options/v4ur:simple-next-hop: 151 +--rw preference? uint32 152 +--rw tag? uint32 153 augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol 154 /rt:static-routes/v4ur:ipv4/v4ur:route/v4ur:next-hop 155 /v4ur:next-hop-options/v4ur:next-hop-list/v4ur:next-hop-list 156 /v4ur:next-hop: 157 +--rw preference? uint32 158 +--rw tag? uint32 159 augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol 160 /rt:static-routes/v6ur:ipv6/v6ur:route/v6ur:next-hop 161 /v6ur:next-hop-options/v6ur:simple-next-hop: 162 +--rw preference? uint32 163 +--rw tag? uint32 164 augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol 165 /rt:static-routes/v6ur:ipv6/v6ur:route/v6ur:next-hop 166 /v6ur:next-hop-options/v6ur:next-hop-list 167 /v6ur:next-hop-list/v6ur:next-hop: 168 +--rw preference? uint32 169 +--rw tag? uint32 170 augment /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route: 171 +--ro metric? uint32 172 +--ro tag? uint32 173 augment /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 174 /rt:next-hop/rt:next-hop-options/rt:simple-next-hop: 175 +--ro repair-path 176 +--ro interface? if:interface-ref 177 +--ro address? inet:ip-address 178 +--ro metric? uint32 179 augment /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 180 /rt:next-hop/rt:next-hop-options/rt:special-next-hop: 181 +--ro repair-path 182 +--ro interface? if:interface-ref 183 +--ro address? inet:ip-address 184 +--ro metric? uint32 185 augment /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route 186 /rt:next-hop/rt:next-hop-options/rt:next-hop-list 187 /rt:next-hop-list/rt:next-hop: 188 +--ro repair-path 189 +--ro interface? if:interface-ref 190 +--ro address? inet:ip-address 191 +--ro metric? uint32 193 4. RIB YANG Model 195 file "ietf-rib-extension@2015-10-28.yang" 196 module ietf-rib-extension { 197 namespace "urn:ietf:params:xml:ns:yang:ietf-rib-extension"; 199 prefix rib; 201 import ietf-inet-types { 202 prefix "inet"; 203 } 205 import ietf-interfaces { 206 prefix "if"; 207 } 209 import ietf-routing { 210 prefix "rt"; 211 } 213 import ietf-ipv4-unicast-routing { 214 prefix "v4ur"; 215 } 217 import ietf-ipv6-unicast-routing { 218 prefix "v6ur"; 219 } 221 organization 222 "Cisco Systems 223 170 West Tasman Drive 224 San Jose, CA 95134-1706 225 USA"; 226 contact 227 "Acee Lindem - acee@cisco.com 228 Yingzhen QU - yiqu@cisco.com"; 230 description 231 "This YANG module extends the generic data model for 232 RIB by augmenting the ietf-netmod-routing-cfg 233 model. It is intended that the module will be extended 234 by vendors to define vendor-specific RIB parameters. 235 "; 237 revision 2016-10-28 { 238 description 239 "* Update to new routing-cfg model. 240 "; 242 reference 243 "RFC XXXX: A YANG Data Model for RIB Extensions."; 244 } 246 revision 2016-03-15 { 247 description 248 "* Update to new routing-cfg model. 249 * Added MPLS label forwarding table. 250 "; 251 reference 252 "RFC XXXX: A YANG Data Model for RIB Extensions."; 253 } 255 revision 2015-10-16 { 256 description 257 "Initial revision."; 258 reference 259 "RFC XXXX: A YANG Data Model for RIB Extensions."; 260 } 262 /* Groupings */ 263 grouping next-hop { 264 description 265 "Next-hop grouping"; 266 leaf interface { 267 type if:interface-ref; 268 description 269 "Outgoing interface"; 270 } 271 leaf address { 272 type inet:ip-address; 273 description 274 "IPv4 or IPv6 Address of the next-hop"; 275 } 276 } 278 grouping attributes { 279 description 280 "Common attributes applicable to all paths"; 281 leaf metric { 282 type uint32; 283 description "Route metric"; 284 } 285 leaf tag { 286 type uint32; 287 description "Route tag"; 288 } 289 } 290 grouping path-attribute { 291 description 292 "Path attribute grouping"; 293 container repair-path { 294 uses next-hop; 295 leaf metric { 296 type uint32; 297 description "Route metric"; 298 } 299 description 300 "IP Fast ReRoute (IPFRR) repair path"; 301 } 302 } 304 augment "/rt:routing/rt:control-plane-protocols/" 305 + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/" 306 + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/" 307 + "v4ur:simple-next-hop" 308 { 309 description 310 "Augment 'simple-next-hop' case in IPv4 unicast route."; 311 leaf preference { 312 type uint32; 313 default "1"; 314 description "Route preference - Used to select among multiple 315 static routes with a lower preference next-hop 316 preferred and equal preference paths yielding 317 Equal Cost Multi-Path (ECMP)."; 318 } 319 leaf tag { 320 type uint32; 321 default "0"; 322 description "Route tag"; 323 } 324 } 326 augment "/rt:routing/rt:control-plane-protocols/" 327 + "rt:control-plane-protocol/rt:static-routes/v4ur:ipv4/" 328 + "v4ur:route/v4ur:next-hop/v4ur:next-hop-options/" 329 + "v4ur:next-hop-list/v4ur:next-hop-list/v4ur:next-hop" 330 { 331 description 332 "Augment static route configuration 'next-hop-list'."; 334 leaf preference { 335 type uint32; 336 default "1"; 337 description "Route preference - Used to select among multiple 338 static routes with a lower preference next-hop 339 preferred and equal preference paths yielding 340 Equal Cost Multi-Path (ECMP)."; 341 } 342 leaf tag { 343 type uint32; 344 default "0"; 345 description "Route tag"; 346 } 347 } 349 augment "/rt:routing/rt:control-plane-protocols/" 350 + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/" 351 + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/" 352 + "v6ur:simple-next-hop" 353 { 354 description 355 "Augment 'simple-next-hop' case in IPv6 unicast route."; 356 leaf preference { 357 type uint32; 358 default "1"; 359 description "Route preference - Used to select among multiple 360 static routes with a lower preference next-hop 361 preferred and equal preference paths yielding 362 Equal Cost Multi-Path (ECMP)."; 363 } 364 leaf tag { 365 type uint32; 366 default "0"; 367 description "Route tag"; 368 } 369 } 371 augment "/rt:routing/rt:control-plane-protocols/" 372 + "rt:control-plane-protocol/rt:static-routes/v6ur:ipv6/" 373 + "v6ur:route/v6ur:next-hop/v6ur:next-hop-options/" 374 + "v6ur:next-hop-list/v6ur:next-hop-list/v6ur:next-hop" 375 { 376 description 377 "Augment static route configuration 'next-hop-list'."; 379 leaf preference { 380 type uint32; 381 default "1"; 382 description "Route preference - Used to select among multiple 383 static routes with a lower preference next-hop 384 preferred and equal preference paths yielding 385 Equal Cost Multi-Path (ECMP)."; 386 } 387 leaf tag { 388 type uint32; 389 default "0"; 390 description "Route tag"; 391 } 392 } 394 augment "/rt:routing-state/rt:ribs/rt:rib/" 395 + "rt:routes/rt:route" 396 { 397 description 398 "Augment a route in RIB with tag."; 399 uses attributes; 400 } 402 augment "/rt:routing-state/rt:ribs/rt:rib/" 403 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 404 + "rt:simple-next-hop" 405 { 406 description 407 "Add more parameters to a path."; 408 uses path-attribute; 409 } 411 augment "/rt:routing-state/rt:ribs/rt:rib/" 412 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 413 + "rt:special-next-hop" 414 { 415 description 416 "Add more parameters to a path."; 417 uses path-attribute; 418 } 420 augment "/rt:routing-state/rt:ribs/rt:rib/" 421 + "rt:routes/rt:route/rt:next-hop/rt:next-hop-options/" 422 + "rt:next-hop-list/rt:next-hop-list/rt:next-hop" 423 { 424 description 425 "This case augments the 'next-hop-options' in the routing 426 model."; 427 uses path-attribute; 428 } 429 } 430 432 5. Security Considerations 434 The YANG model augmentations defined herein do not introduce any 435 security issues other than those already discussed in [ROUTING-CFG], 436 and [NETCONF]. If confidentiality is desired, the underlying NETCONF 437 communication should be utilized as described in [NETCONF-SSH]. 439 6. IANA Considerations 441 This document registers a URI in the IETF XML registry 442 [XML-REGISTRY]. Following the format in RFC 3688, the following 443 registration is requested to be made: 445 URI: urn:ietf:params:xml:ns:yang:ietf-rib 446 Registrant Contact: The IESG. 448 XML: N/A, the requested URI is an XML namespace. 450 This document registers a YANG module in the YANG Module Names 451 registry [YANG]. 453 name: ietf-acl namespace: urn:ietf:params:xml:ns:yang:ietf-rib 454 prefix: ietf-rib reference: RFC XXXX 456 7. References 458 7.1. Normative References 460 [RFC-KEYWORDS] 461 Bradner, S., "Key words for use in RFC's to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [ROUTING-CFG] 465 Lhothka, L. and A. Lindem, "A YANG Data Model for Routing 466 Management", draft-ietf-netmod-routing-cfg-24.txt (work in 467 progress), October 2016. 469 [YANG] Bjorklund, M., "YANG - A Data Modeling Language for the 470 Network Configuration Protocol (NETCONF)", RFC 6020, 471 October 2010. 473 7.2. Informative References 475 [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 476 Bierman, "Network Configuration Protocol (NETCONF)", 477 RFC 6241, June 2011. 479 [NETCONF-SSH] 480 Wasserman, M., "Using NETCONF Protocol over Secure Shell 481 (SSH)", RFC 6242, June 2011. 483 [XML-REGISTRY] 484 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 485 January 2004. 487 Appendix A. Acknowledgments 489 The RFC text was produced using Marshall Rose's xml2rfc tool. 491 The authors wish to thank Les Ginsberg, Krishna Deevi and Suyoung 492 Yoon for their helpful comments and suggestions. 494 Authors' Addresses 496 Acee Lindem 497 Cisco Systems 498 301 Midenhall Way 499 Cary, NC 27513 500 USA 502 Email: acee@cisco.com 504 Yingzhen Qu 505 Cisco Systems 506 170 West Tasman Drive 507 San Jose, CA 95134 508 USA 510 Email: yiqu@cisco.com