idnits 2.17.1 draft-white-i2rs-use-case-04.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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 12, 2014) is 3605 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-03 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-03 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-03 == Outdated reference: A later version (-07) exists of draft-lapukhov-bgp-routing-large-dc-06 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 i2rs R. White 3 Internet-Draft IETF 4 Intended status: Informational S. Hares 5 Expires: December 14, 2014 Hickory Hill 6 A. Retana 7 Cisco Systems, Inc. 8 June 12, 2014 10 Protocol Independent Use Cases for an Interface to the Routing System 11 draft-white-i2rs-use-case-04 13 Abstract 15 Programmatic interfaces to provide control over individual forwarding 16 devices in a network promise to reduce operational costs while 17 improving scaling, control, and visibility into the operation of 18 large scale networks. To this end, several programmatic interfaces 19 have been proposed. OpenFlow, for instance, provides a mechanism to 20 replace the dynamic control plane processes on individual forwarding 21 devices throughout a network with off box processes that interact 22 with the forwarding tables on each device. Another example is 23 NETCONF, which provides a fast and flexible mechanism to interact 24 with device configuration and policy. 26 There is, however, no proposal which provides an interface to all 27 aspects of the routing system as a system. Such a system would not 28 interact with the forwarding system on individual devices, but rather 29 with the control plane processes already used to discover the best 30 path to any given destination through the network, as well as 31 interact with the routing information base (RIB), which feeds the 32 forwarding table the information needed to actually switch traffic at 33 a local level. 35 This document describes a set of use cases such a system could 36 fulfill. It is designed to provide underlying support for the 37 framework, policy, and other drafts describing the Interface to the 38 Routing System (I2RS). 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on December 14, 2014. 57 Copyright Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 76 2. Summary of Requirements . . . . . . . . . . . . . . . . . . . 3 77 3. Distributed Reaction to Network Based Attacks . . . . . . . . 5 78 4. Remote Service Routing . . . . . . . . . . . . . . . . . . . 7 79 5. Within Data Center Routing . . . . . . . . . . . . . . . . . 9 80 6. Temporary Overlays between Data Centers . . . . . . . . . . . 11 81 7. Comparison of I2RS requirements with I2RS RIB Information 82 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 8.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 88 1. Introduction 90 The Architecture for the Interface to the Routing System 91 [I-D.ietf-i2rs-architecture] allows for a mechanism where the 92 distributed control plane can be augmented by an outside control 93 plane through an open, accessible interface, including the Routing 94 Information Base (RIB), in individual devices to solve issues 95 described in [I-D.ietf-i2rs-problem-statement]. The RIB Info Model 96 [I-D.ietf-i2rs-rib-info-model] specifies the information elements 97 accessible by the I2RS system in the RIB. 99 This represents a "halfway point" between completely replacing the 100 traditional distributed control plane and directly configuring 101 devices to distribute policy or modifications to routing through off- 102 board processes. This draft proposes a set of use cases that explain 103 where the work described utilizing the RIB information model will be 104 useful. The goal is to inform not only the community's understanding 105 of where I2RS fits in the larger scheme of SDN proposals, but also to 106 inform the requirements, framework, and specification of I2RS to 107 provide the best fit for the purposes which make the most sense for 108 this type of programmatic interface. 110 Towards this end the authors have searched for a number of different 111 use cases representing not only complex modifications of the control 112 plane, including interaction with applications and network 113 conditions, but also simpler use cases. The array of use cases 114 presented here should provide the reader with a solid understanding 115 of the power of an SDN solution that will augment, rather than 116 replace, traditional distributed control planes. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 2. Summary of Requirements 126 Each use case is presented in its own section with a list of 127 requirements. The full list of requirements is below. Each 128 requirement in these lists has a number REQnn where nn represents a 129 number such as REQ01. Each unique has been given a number so in some 130 use cases the numbers may skip numbers. For example, use case 2 has 131 requirements REQ01, REQ06, and REQ07. 133 At the end of this document, these use cases are compared against the 134 current I2RS specifications. 136 o REQ01: The ability to monitor the available routes installed in 137 the RIB of each forwarding device, including near real time 138 notification of route installation and removal. This information 139 must include the destination prefix (NLRI), a table identifier (if 140 the forwarding device has multiple forwarding instances), the 141 metric of the installed route, and an identifier indicating the 142 installing process. 144 o REQ02: The ability to install source and destination based routes 145 in the local RIB of each forwarding device. This must include the 146 ability to supply the destination prefix (NLRI), the source prefix 147 (NLRI), a table identifier (if the forwarding device has multiple 148 forwarding instances), a route preference, a route metric, a next 149 hop, an outbound interface, and a route process identifier. 151 o REQ03: The ability to install a route to a null destination, 152 effectively filtering traffic to this destination. 154 o REQ04: The ability to interact with various policies configured on 155 the forwarding devices, in order to inform the policies 156 implemented by the dynamic routing processes. This interaction 157 should be through existing configuration mechanisms, such as 158 NETCONF, and should be recorded in the configuration of the local 159 device so operators are aware of the full policy implemented in 160 the network from the running configuration. 162 o REQ05: The ability to interact with traffic flow and other network 163 traffic level measurement protocols and systems, in order to 164 determine path performance, top talkers, and other information 165 required to make an informed path decision based on locally 166 configured policy. 168 o REQ06: The ability to install destination based routes in the 169 local RIB of each forwarding device. This must include the 170 ability to supply the destination prefix (NLRI), a table 171 identifier (if the forwarding device has multiple forwarding 172 instances), a route preference, a route metric, a next hop, an 173 outbound interface, and a route process identifier. 175 o REQ07: The ability to read the local RIB of each forwarding 176 device, including the destination prefix (NLRI), a table 177 identifier (if the forwarding device has multiple forwarding 178 instances), the metric of each installed route, a route 179 preference, and an identifier indicating the installing process. 181 o REQ08: The ability to read the tables of other local protocol 182 processes running on the device. This reading action should be 183 supported through an import/export interface which can present the 184 information in a consistent manner across all protocol 185 implementations, rather than using a protocol specific model for 186 each type of available process. 188 o REQ09: The ability to inject information directly into the local 189 tables of other protocol processes running on the forwarding 190 device. This injection should be supported through an import/ 191 export interface which can inject routing information in a 192 consistent manner across all protocol implementations, rather than 193 using a protocol specific model for each type of available 194 process. 196 o REQ10: The ability to interact with policies and configurations on 197 the forwarding devices using time based processing, either through 198 timed auto-rollback or some other mechanism. This interaction 199 should be through existing configuration mechanisms, such as 200 NETCONF, and should be recorded in the configuration of the local 201 device so operators are aware of the full policy implemented in 202 the network from the running configuration. 204 3. Distributed Reaction to Network Based Attacks 206 Quickly modifying the control plane to reroute traffic for one 207 destination while leaving a standard configuration in place (filters, 208 metrics, and other policy mechanisms) is a challenge --but this is 209 precisely the challenge of a network engineer attempting to deal with 210 a network incursion. The ability to redirect specific flows of 211 information or specific classes of traffic into, through, and back 212 out of traffic analyzers on the fly is crucial in these situations. 213 The following network diagram provides an illustration of the 214 problem. 216 Valid Source---\ /--R2--------------------\ 217 R1 R3---Valid Destination 218 Attack Source--/ \--Monitoring Device-----/ 220 Modifying the cost of the link between R1 and R2 to draw the attack 221 traffic through the monitoring device in the distributed control 222 plane will, of necessity, also draw the valid traffic through the 223 monitoring device. Drawing valid traffic through a monitoring device 224 introduces delay, jitter, and other quality of service issues, as 225 well as posing a problem for the monitoring device itself in terms of 226 traffic load and management. 228 An I2RS controller could stand between the detection of the attack 229 and the control plane to facilitate the rapid modification of control 230 and forwarding planes to either block the traffic or redirect it to 231 analysis devices connected to the network. 233 +----------+ 234 |i2rs-client|------------------- 235 | |-----------+ | 236 -----------+ | | 237 | +------+ | 238 | | ir2s | | 239 | | agent| | 240 Valid Source--\ | /---|R2 |-------+\ 241 +-------+/ +------+ | \ 242 |R1 i2rs| | R3--Valid 243 | agent| | Destination 244 +-------+ i2rs agent 245 Attack Source--/ \--Monitoring Device-----/ 247 Summary of I2RS Capabilities and Interactions: 249 In the lists below, the REQnn in which nn is a number indicates a 250 unique requirement from the use cases. 252 o REQ01: The ability to monitor the available routes installed in 253 the RIB of each forwarding device, including near real time 254 notification of route installation and removal. The information 255 pulled from the RIB must include the destination prefix (NLRI), 256 the table identifier (if the forwarding device has multiple 257 forwarding instances), the metric of the installed route, and the 258 identifier for the installing process. 260 o REQ02: The ability to install source and destination based routes 261 in the local RIB of each forwarding device. This must include the 262 ability to supply the destination prefix (NLRI), the source prefix 263 (NLRI), a table identifier (if the forwarding device has multiple 264 forwarding instances), a route preference, a route metric, a next 265 hop, an outbound interface, and a route process identifier. 267 o REQ03: The ability to install a route to a null destination, 268 effectively filtering traffic to this destination. 270 o REQ04: The ability to interact with various policies configured on 271 the forwarding devices, in order to inform the policies 272 implemented by the dynamic routing processes. This interaction 273 should be through existing configuration mechanisms, such as 274 NETCONF, and should be recorded in the configuration of the local 275 device so operators are aware of the full policy implemented in 276 the network from the running configuration. 278 o REQ5: The ability to interact with traffic flow and other network 279 traffic level measurement protocols and systems, in order to 280 determine path performance, top talkers, and other information 281 required to make an informed path decision based on locally 282 configured policy. 284 4. Remote Service Routing 286 In hub and spoke overlay networks, there is always an issue with 287 balancing between the information held in the spoke routing table, 288 optimal routing through the network underlying the overlay, and 289 mobility. Most solutions in this space use some form of centralized 290 route server that acts as a directory of all reachable destinations 291 and next hops, a protocol by which spoke devices and this route 292 server communicate, and caches at the remote sites. 294 An I2RS solution would use the same elements, but with a different 295 control plane. Remote sites would register (or advertise through 296 some standard routing protocol, such as BGP), the reachable 297 destinations at each site, along with the address of the router (or 298 other device) used to reach that destination. These would, as 299 always, be stored in a route server (or several redundant route 300 servers) at a central location. 302 When a remote site sends a set of packets to the central location 303 that are eventually destined to some other remote site, the central 304 location can forward this traffic, but at the same time simply 305 directly insert the correct routing information into the remote 306 site's routing table. If the location of the destination changes, 307 the route server can directly modify the routing information at the 308 remote site as needed. 310 +---------------------+ 311 | APP or Controller | 312 +---------------------+ 313 | 314 | 315 +----------------+ 316 / Centralized \ 317 + Route server + 318 ---------------------- 319 | hub | 320 | 192.50.128/24 *---------+ 321 +--*----*---*------*-+ | 322 | | | | | | 323 +--*--+ | +-*--+ +*----+ | 324 source 1---| A |---| C |--| D |---- | 325 \ /+--+--+ | +----+ +-----+ | 326 \ / | | | | 327 \/ | | | | 328 /\ +-----+ | +-----+*-----------+ 329 source 2 \ | B *-| | D | 330 \| |-----| |----- 331 +-----+ +-----+ 333 *- are RS connections 334 |- are hub/spoke connects 336 An interesting aspect of this solution is that no new and specialized 337 protocols are needed between the remote sites and the centralized 338 route server(s). Normal routing protocols can be used to notify the 339 centralized route server(s) of modifications in reachability 340 information, and the route server(s) can respond as needed, based on 341 local algorithms optimized for a particular application or network. 342 For instance, short lived flows might be allowed to simply pass 343 through the hub site with no reaction, while longer lived flows might 344 warrant a specific route to be installed in the remote router. 345 Algorithms can also be developed that would optimize traffic flow 346 through the overlay, and also to remove routing entries from remote 347 devices when they are no longer needed based on far greater 348 intelligence than simple non-use for some period of time. 350 Summary of I2RS Capabilities and Interactions: 352 o REQ01: The ability to monitor the available routes installed in 353 the RIB of each forwarding device, including near real time 354 notification of route installation and removal. This information 355 must include the destination prefix (NLRI), a table identifier (if 356 the forwarding device has multiple forwarding instances), the 357 metric of the installed route, and an identifier indicating the 358 installing process. 360 o REQ06: The ability to install destination based routes in the 361 local RIB of each forwarding device. This must include the 362 ability to supply the destination prefix (NLRI), a table 363 identifier (if the forwarding device has multiple forwarding 364 instances), a route preference, a route metric, a next hop, an 365 outbound interface, and a route process identifier. 367 o REQ07: The ability to read the local RIB of each forwarding 368 device, including the destination prefix (NLRI), a table 369 identifier (if the forwarding device has multiple forwarding 370 instances), the metric of each installed route, a route 371 preference, and an identifier indicating the installing process. 373 5. Within Data Center Routing 375 Data Centers have evolved into massive topologies with thousands of 376 server racks and millions of hosts. Data Centers use BGP with ECMP, 377 ISIS (with multiple LAGs), or other protocols to tie the data center 378 together. Data centers are currently designed around a three or four 379 tier structure with: server, top-of-rack switches, aggregation 380 switches, and router interfacing the data center to the Internet. 381 [I-D.lapukhov-bgp-routing-large-dc] examines many of these elements 382 of data center design. 384 One element of these Data Center routing infrastructures is the 385 ability to quickly read topology information and execute 386 configuration from a centralized location. Key to this environment 387 is the tight feedback loop between learning about topology changes or 388 loading changes, and instantiating new routing policy. Without I2RS, 389 may Data Centers are using extra physical topologies or logical 390 topologies to work around the features. 392 An I2RS solution would use the same elements, but with a different 393 control plane. The I2RS enabled control plane could provide the Data 394 Center 4 tier infrastructure the quick access to topology and data 395 flow information needed for traffic flow optimization. Changes to 396 the Data Center infrastructure done via I2RS could have a tight 397 feedback loop. 399 Again, this solution would reduce the need for new and specialized 400 protocols while giving the Data Center the control it desire. The 401 I2RS routing interface could be extended to virtual routers. 403 Summary of I2RS Capabilities and Interactions: 405 o REQ01: The ability to monitor the available routes installed in 406 the RIB of each forwarding device, including near real time 407 notification of route installation and removal. This information 408 must include the destination prefix (NLRI), a table identifier (if 409 the forwarding device has multiple forwarding instances), the 410 metric of the installed route, and an identifier indicating the 411 installing process. 413 o REQ04: The ability to interact with various policies configured on 414 the forwarding devices, in order to inform the policies 415 implemented by the dynamic routing processes. This interaction 416 should be through existing configuration mechanisms, such as 417 NETCONF, and should be recorded in the configuration of the local 418 device so operators are aware of the full policy implemented in 419 the network from the running configuration. 421 o REQ05: The ability to interact with traffic flow and other network 422 traffic level measurement protocols and systems, in order to 423 determine path performance, top talkers, and other information 424 required to make an informed path decision based on locally 425 configured policy. 427 o REQ06: The ability to install destination based routes in the 428 local RIB of each forwarding device. This must include the 429 ability to supply the destination prefix (NLRI), a table 430 identifier (if the forwarding device has multiple forwarding 431 instances), a route preference, a route metric, a next hop, an 432 outbound interface, and a route process identifier. 434 o REQ07: The ability to read the local RIB of each forwarding 435 device, including the destination prefix (NLRI), a table 436 identifier (if the forwarding device has multiple forwarding 437 instances), the metric of each installed route, a route 438 preference, and an identifier indicating the installing process. 440 o REQ08: The ability to read the tables of other local protocol 441 processes running on the device. This reading action should be 442 supported through an import/export interface which can present the 443 information in a consistent manner across all protocol 444 implementations, rather than using a protocol specific model for 445 each type of available process. 447 o REQ09: The ability to inject information directly into the local 448 tables of other protocol processes running on the forwarding 449 device. This injection should be supported through an import/ 450 export interface which can inject routing information in a 451 consistent manner across all protocol implementations, rather than 452 using a protocol specific model for each type of available 453 process. 455 6. Temporary Overlays between Data Centers 457 Data Centers within one organization may operate as one single entity 458 even though they may be geographically distributed. Applications are 459 load balanced within Data Centers and between data centers to take 460 advantage of cost economics in power, storage, and server 461 availability for compute resources. Applications are also transfer 462 to alternate data centers in case of failures within a data center. 463 To reduce time during failure, Data Centers often replicate user 464 storage between two or more data centers. During the transfer of 465 stored information prior to a Data Center to Data Center move, the 466 Data Center controllers need to dynamically acquire a large amount of 467 inter-data center bandwidth through an overlay network, often during 468 off hours. 470 I2RS could provide the connection between the overlay network 471 configuration, local policies, and the control plane to dynamically 472 bring a large bandwidth inter-data center overlay or channel into 473 use, and then to remove it from use when the data transfer is 474 completed. 476 Similarly, during a fail-over, a control process within data centers 477 interacts with a group host process and the network to seamless move 478 the processing to another data center. During the fail-over case, 479 additional process state may need to be moved as well to restart the 480 system. The difference between these data-to-data center moves is 481 immediate and urgent need to move systems. If an application (such 482 as medical or banking services) pays to have this type of fail-over, 483 it is likely the network service this application uses will pay for 484 the preemption on network bandwidth and a Quality of Service (QoS) on 485 the data transfer to allow the failover traffic to flow quickly to 486 the remote datacenter. I2RS can allow the Data Center network and 487 the Network connecting the data center to preempt other best-effort 488 traffic to send this priority data flow and to set a QoS that will 489 allow quick data transfer. After the high priority data flow has 490 finished, networks can return to their previous condition. 492 Summary of I2RS Capabilities and Interactions: 494 o REQ01: The ability to monitor the available routes installed in 495 the RIB of each forwarding device, including near real time 496 notification of route installation and removal. This information 497 must include the destination prefix (NLRI), a table identifier (if 498 the forwarding device has multiple forwarding instances), the 499 metric of the installed route, and an identifier indicating the 500 installing process. 502 o REQ02: The ability to install source and destination based routes 503 in the local RIB of each forwarding device. This must include the 504 ability to supply the destination prefix (NLRI), the source prefix 505 (NLRI), a table identifier (if the forwarding device has multiple 506 forwarding instances), a route preference, a route metric, a next 507 hop, an outbound interface, and a route process identifier. 509 o REQ05: The ability to interact with traffic flow and other network 510 traffic level measurement protocols and systems, in order to 511 determine path performance, top talkers, and other information 512 required to make an informed path decision based on locally 513 configured policy. 515 o REQ06: The ability to install destination based routes in the 516 local RIB of each forwarding device. This must include the 517 ability to supply the destination prefix (NLRI), a table 518 identifier (if the forwarding device has multiple forwarding 519 instances), a route preference, a route metric, a next hop, an 520 outbound interface, and a route process identifier. 522 o REQ07: The ability to read the local RIB of each forwarding 523 device, including the destination prefix (NLRI), a table 524 identifier (if the forwarding device has multiple forwarding 525 instances), the metric of each installed route, a route 526 preference, and an identifier indicating the installing process. 528 o REQ10: The ability to interact with policies and configurations on 529 the forwarding devices using time based processing, either through 530 timed auto-rollback or some other mechanism. This interaction 531 should be through existing configuration mechanisms, such as 532 NETCONF, and should be recorded in the configuration of the local 533 device so operators are aware of the full policy implemented in 534 the network from the running configuration. 536 7. Comparison of I2RS requirements with I2RS RIB Information Model 538 Comparison of I2RS Capabilities versus the I2RS RIB 540 In summary, the I2RS client/agent architecture and protocol SHOULD 541 support the following requirements: 543 REQ01: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] specifies 544 the routes as associated with routing-instance, interface-list and 545 RIBs within a Router (virtual or physical) identified by 546 Router_ID. Each route has a prefixes, route attributes, family 547 attributes (IPv4, Ipv6, MPLS, MAC, interface), and next-hop list. 548 The RIB info model does not keep information on the FIB the route 549 was installed in, the metric of the installed route, or the 550 identifier of the installing process. The RIB Info Model 551 [I-D.ietf-i2rs-rib-info-model] does provide a notification for 552 route change with an installed in FIB flag, active flag, and 553 reason (for non-installation). 555 REQ02: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] supports 556 installing source-destination routes for IPv4 and IPv6 for a RIB 557 associated with set of RIBs within a route instance of a Router 558 (virtual or physical). If there is policy that links RIBs within 559 a route instance of router to a specific FIB, it is not clearly 560 stated in the RIB Info Model [I-D.ietf-i2rs-rib-info-model]. The 561 source-destination is only for IPv4 and IPv6 NLRI. The RIB Info 562 Model [I-D.ietf-i2rs-rib-info-model]. does has a route_preference 563 (ROUTE_PREFERENCE), but not a route metric. The nexthop field 564 does have a primary/back preference, a load balancing weight, and 565 an egress (outbound) interface per nexthop, and a RIB_ID. It is 566 unclear if the RIB_ID serves the same purpose as the multiple 567 forwarding instances. 569 REQ03: The RIB Info Model does not provide a specific indication 570 that the default (zero length prefix) route can be installed, but 571 this can be implied from the different match lengths. 573 REQ04: The ability to interact with various policies via existing 574 configuration functions such as NETCONF has not be specified 575 directly in RIB Informational Model [I-D.ietf-i2rs-rib-info-model] 576 or any other informational model. 578 REQ05: The ability to interact with traffic flow and other network 579 traffic level measurement protocols and systems is not included in 580 any I2RS information model. 582 REQ06: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] supports 583 installing destination routes in a RIB for all RIB families from a 584 route-instance. The route_instance is identified by the tuple of 585 INSTANCE_NAME and ROUTER_ID. Each route may contain a route 586 preference and multiple next hops, but it does not contain a 587 metric per route. Each nexthop may contains a RIB_ID to look-up 588 nexthop, an egress-interface, tunnel nexthop (logical or 589 encapsulated). This must include the ability to supply the 590 destination prefix (NLRI), a table identifier (if the forwarding 591 device has multiple forwarding instances), a route preference, a 592 route metric, a next hop, an outbound interface, and a route 593 process identifier. 595 REQ07: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] supports 596 the ability to read the RIBs associated with each routing- 597 instance. The routing instance is identified by tuple of 598 ROUTE_INSTANCE plus optionally interface_list and router ID. The 599 RIBS are identified by NAME and RIB_FAMILY. The routes within the 600 RIB Can be identified by route-match that identifies destination 601 (IPv4, IPv6, IEEE MAC, MPLS, interface). The information read per 602 route is the destination prefix (NLRI), route preference and 603 multiple nexthops (each with associated metric and RIB). However, 604 it does not indicate the metric of an installed route and the 605 identifier of the installing process. 607 REQ08: The ability to read the tables of other local protocol 608 processes running on the device. This reading action should be 609 supported through an import/export interface which can present the 610 information in a consistent manner across all protocol 611 implementations, rather than using a protocol specific model for 612 each type of available process. 614 REQ09: No informational model supports the ability to inject 615 information of other protocol processing running on the forwarding 616 device. The RIB Info Model [I-D.ietf-i2rs-rib-info-model] inserts 617 the routes with RIB with a The ability to inject information 618 directly into the local tables of other protocol processes running 619 on the forwarding device. This injection should be supported 620 through an import/export interface which can inject routing 621 information in a consistent manner across all protocol 622 implementations, rather than using a protocol specific model for 623 each type of available process. 625 REQ10: The ability to interact with policies and configurations on 626 the forwarding devices using time based processing, either through 627 timed auto-rollback or some other mechanism. This interaction 628 should be through existing configuration mechanisms, such as 629 NETCONF, and should be recorded in the configuration of the local 630 device so operators are aware of the full policy implemented in 631 the network from the running configuration. 633 8. References 635 8.1. Normative References 637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 638 Requirement Levels", BCP 14, RFC 2119, March 1997. 640 8.2. Informative References 642 [I-D.ietf-i2rs-architecture] 643 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 644 Nadeau, "An Architecture for the Interface to the Routing 645 System", draft-ietf-i2rs-architecture-03 (work in 646 progress), May 2014. 648 [I-D.ietf-i2rs-problem-statement] 649 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 650 Routing System Problem Statement", draft-ietf-i2rs- 651 problem-statement-03 (work in progress), June 2014. 653 [I-D.ietf-i2rs-rib-info-model] 654 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 655 Information Base Info Model", draft-ietf-i2rs-rib-info- 656 model-03 (work in progress), May 2014. 658 [I-D.lapukhov-bgp-routing-large-dc] 659 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 660 routing in large-scale data centers", draft-lapukhov-bgp- 661 routing-large-dc-06 (work in progress), August 2013. 663 Authors' Addresses 665 Russ White 666 IETF 668 Email: russw@riw.us 670 Susan Hares 671 Hickory Hill 673 Email: shares@ndzh.com 675 Alvaro Retana 676 Cisco Systems, Inc. 677 7025 Kit Creek Road 678 Research Triangle Park, NC 27617 679 USA 681 Email: aretana@cisco.com