idnits 2.17.1 draft-white-i2rs-use-case-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 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 (July 4, 2014) is 3583 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-04 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-04 == 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 Ericsson 4 Intended status: Informational S. Hares 5 Expires: January 5, 2015 Huawei 6 A. Retana 7 Cisco Systems, Inc. 8 July 4, 2014 10 Protocol Independent Use Cases for an Interface to the Routing System 11 draft-white-i2rs-use-case-06 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 January 5, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 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 an identifier PI-REQnn where PI-REQ 129 standard for protocol independent requirements and nn is a 130 requirement number. Each unique requirement has been given a number 131 so in some use cases the numbers may skip numbers. For example, use 132 case 2 has requirements PI-REQ01, PI-REQ06, and PI-REQ07. 134 At the end of this document, these use case requirements are compared 135 against the current I2RS RIB informational model (RIB IM) 136 ([I-D.ietf-i2rs-rib-info-model]). In this section, the RIB Inform 137 requirements are numbered PI-RIB_IM-nn where nn is the requirement 138 number. 140 o PI-REQ01: The ability to monitor the available routes installed in 141 the RIB of each forwarding device, including near real time 142 notification of route installation and removal. This information 143 must include the destination prefix (NLRI), a table identifier (if 144 the forwarding device has multiple forwarding instances), the 145 metric of the installed route, and an identifier indicating the 146 installing process. 148 o PI-REQ02: The ability to install source and destination based 149 routes in the local RIB of each forwarding device. This must 150 include the ability to supply the destination prefix (NLRI), the 151 source prefix (NLRI), a table identifier (if the forwarding device 152 has multiple forwarding instances), a route preference, a route 153 metric, a next hop, an outbound interface, and a route process 154 identifier. 156 o PI-REQ03: The ability to install a route to a null destination, 157 effectively filtering traffic to this destination. 159 o PI-REQ04: The ability to interact with various policies configured 160 on the forwarding devices, in order to inform the policies 161 implemented by the dynamic routing processes. This interaction 162 should be through existing configuration mechanisms, such as 163 NETCONF, and should be recorded in the configuration of the local 164 device so operators are aware of the full policy implemented in 165 the network from the running configuration. 167 o PI-REQ05: The ability to interact with traffic flow and other 168 network traffic level measurement protocols and systems, in order 169 to determine path performance, top talkers, and other information 170 required to make an informed path decision based on locally 171 configured policy. 173 o PI-REQ06: The ability to install destination based routes in the 174 local RIB of each forwarding device. This must include the 175 ability to supply the destination prefix (NLRI), a table 176 identifier (if the forwarding device has multiple forwarding 177 instances), a route preference, a route metric, a next hop, an 178 outbound interface, and a route process identifier. 180 o PI-REQ07: The ability to read the local RIB of each forwarding 181 device, including the destination prefix (NLRI), a table 182 identifier (if the forwarding device has multiple forwarding 183 instances), the metric of each installed route, a route 184 preference, and an identifier indicating the installing process. 186 o PI-REQ08: The ability to read the tables of other local protocol 187 processes running on the device. This reading action should be 188 supported through an import/export interface which can present the 189 information in a consistent manner across all protocol 190 implementations, rather than using a protocol specific model for 191 each type of available process. 193 o PI-REQ09: The ability to inject information directly into the 194 local tables of other protocol processes running on the forwarding 195 device. This injection should be supported through an import/ 196 export interface which can inject routing information in a 197 consistent manner across all protocol implementations, rather than 198 using a protocol specific model for each type of available 199 process. 201 o PI-REQ10: The ability to interact with policies and configurations 202 on the forwarding devices using time based processing, either 203 through timed auto-rollback or some other mechanism. This 204 interaction should be through existing configuration mechanisms, 205 such as NETCONF, and should be recorded in the configuration of 206 the local device so operators are aware of the full policy 207 implemented in the network from the running configuration. 209 3. Distributed Reaction to Network Based Attacks 211 Quickly modifying the control plane to reroute traffic for one 212 destination while leaving a standard configuration in place (filters, 213 metrics, and other policy mechanisms) is a challenge --but this is 214 precisely the challenge of a network engineer attempting to deal with 215 a network incursion. The ability to redirect specific flows of 216 information or specific classes of traffic into, through, and back 217 out of traffic analyzers on the fly is crucial in these situations. 218 The following network diagram provides an illustration of the 219 problem. 221 Valid Source---\ /--R2--------------------\ 222 R1 R3---Valid Destination 223 Attack Source--/ \--Monitoring Device-----/ 225 Modifying the cost of the link between R1 and R2 to draw the attack 226 traffic through the monitoring device in the distributed control 227 plane will, of necessity, also draw the valid traffic through the 228 monitoring device. Drawing valid traffic through a monitoring device 229 introduces delay, jitter, and other quality of service issues, as 230 well as posing a problem for the monitoring device itself in terms of 231 traffic load and management. 233 An I2RS controller could stand between the detection of the attack 234 and the control plane to facilitate the rapid modification of control 235 and forwarding planes to either block the traffic or redirect it to 236 analysis devices connected to the network. 238 +----------+ 239 |i2rs-client|------------------- 240 | |-----------+ | 241 -----------+ | | 242 | +------+ | 243 | | ir2s | | 244 | | agent| | 245 Valid Source--\ | /---|R2 |-------+\ 246 +-------+/ +------+ | \ 247 |R1 i2rs| | R3--Valid 248 | agent| | Destination 249 +-------+ i2rs agent 250 Attack Source--/ \--Monitoring Device-----/ 252 Summary of I2RS Capabilities and Interactions: 254 In the lists below, the REQnn in which nn is a number indicates a 255 unique requirement from the use cases. 257 o PI-REQ01: The ability to monitor the available routes installed in 258 the RIB of each forwarding device, including near real time 259 notification of route installation and removal. The information 260 pulled from the RIB must include the destination prefix (NLRI), 261 the table identifier (if the forwarding device has multiple 262 forwarding instances), the metric of the installed route, and the 263 identifier for the installing process. 265 o PI-REQ02: The ability to install source and destination based 266 routes in the local RIB of each forwarding device. This must 267 include the ability to supply the destination prefix (NLRI), the 268 source prefix (NLRI), a table identifier (if the forwarding device 269 has multiple forwarding instances), a route preference, a route 270 metric, a next hop, an outbound interface, and a route process 271 identifier. 273 o PI-REQ03: The ability to install a route to a null destination, 274 effectively filtering traffic to this destination. 276 o PI-REQ04: The ability to interact with various policies configured 277 on the forwarding devices, in order to inform the policies 278 implemented by the dynamic routing processes. This interaction 279 should be through existing configuration mechanisms, such as 280 NETCONF, and should be recorded in the configuration of the local 281 device so operators are aware of the full policy implemented in 282 the network from the running configuration. 284 o PI-REQ5: The ability to interact with traffic flow and other 285 network traffic level measurement protocols and systems, in order 286 to determine path performance, top talkers, and other information 287 required to make an informed path decision based on locally 288 configured policy. 290 4. Remote Service Routing 292 In hub and spoke overlay networks, there is always an issue with 293 balancing between the information held in the spoke routing table, 294 optimal routing through the network underlying the overlay, and 295 mobility. Most solutions in this space use some form of centralized 296 route server that acts as a directory of all reachable destinations 297 and next hops, a protocol by which spoke devices and this route 298 server communicate, and caches at the remote sites. 300 An I2RS solution would use the same elements, but with a different 301 control plane. Remote sites would register (or advertise through 302 some standard routing protocol, such as BGP), the reachable 303 destinations at each site, along with the address of the router (or 304 other device) used to reach that destination. These would, as 305 always, be stored in a route server (or several redundant route 306 servers) at a central location. 308 When a remote site sends a set of packets to the central location 309 that are eventually destined to some other remote site, the central 310 location can forward this traffic, but at the same time simply 311 directly insert the correct routing information into the remote 312 site's routing table. If the location of the destination changes, 313 the route server can directly modify the routing information at the 314 remote site as needed. 316 +---------------------+ 317 | APP or Controller | 318 +---------------------+ 319 | 320 | 321 +----------------+ 322 / Centralized \ 323 + Route server + 324 ---------------------- 325 | hub | 326 | 192.50.128/24 *---------+ 327 +--*----*---*------*-+ | 328 | | | | | | 329 +--*--+ | +-*--+ +*----+ | 330 source 1---| A |---| C |--| D |---- | 331 \ /+--+--+ | +----+ +-----+ | 332 \ / | | | | 333 \/ | | | | 334 /\ +-----+ | +-----+*-----------+ 335 source 2 \ | B *-| | D | 336 \| |-----| |----- 337 +-----+ +-----+ 339 *- are RS connections 340 |- are hub/spoke connects 342 An interesting aspect of this solution is that no new and specialized 343 protocols are needed between the remote sites and the centralized 344 route server(s). Normal routing protocols can be used to notify the 345 centralized route server(s) of modifications in reachability 346 information, and the route server(s) can respond as needed, based on 347 local algorithms optimized for a particular application or network. 348 For instance, short lived flows might be allowed to simply pass 349 through the hub site with no reaction, while longer lived flows might 350 warrant a specific route to be installed in the remote router. 351 Algorithms can also be developed that would optimize traffic flow 352 through the overlay, and also to remove routing entries from remote 353 devices when they are no longer needed based on far greater 354 intelligence than simple non-use for some period of time. 356 Summary of I2RS Capabilities and Interactions: 358 o PI-REQ01: The ability to monitor the available routes installed in 359 the RIB of each forwarding device, including near real time 360 notification of route installation and removal. This information 361 must include the destination prefix (NLRI), a table identifier (if 362 the forwarding device has multiple forwarding instances), the 363 metric of the installed route, and an identifier indicating the 364 installing process. 366 o PI-REQ06: The ability to install destination based routes in the 367 local RIB of each forwarding device. This must include the 368 ability to supply the destination prefix (NLRI), a table 369 identifier (if the forwarding device has multiple forwarding 370 instances), a route preference, a route metric, a next hop, an 371 outbound interface, and a route process identifier. 373 o PI-REQ07: The ability to read the local RIB of each forwarding 374 device, including the destination prefix (NLRI), a table 375 identifier (if the forwarding device has multiple forwarding 376 instances), the metric of each installed route, a route 377 preference, and an identifier indicating the installing process. 379 5. Within Data Center Routing 381 Data Centers have evolved into massive topologies with thousands of 382 server racks and millions of hosts. Data Centers use BGP with ECMP, 383 ISIS (with multiple LAGs), or other protocols to tie the data center 384 together. Data centers are currently designed around a three or four 385 tier structure with: server, top-of-rack switches, aggregation 386 switches, and router interfacing the data center to the Internet. 387 [I-D.lapukhov-bgp-routing-large-dc] examines many of these elements 388 of data center design. 390 One element of these Data Center routing infrastructures is the 391 ability to quickly read topology information and execute 392 configuration from a centralized location. Key to this environment 393 is the tight feedback loop between learning about topology changes or 394 loading changes, and instantiating new routing policy. Without I2RS, 395 may Data Centers are using extra physical topologies or logical 396 topologies to work around the features. 398 An I2RS solution would use the same elements, but with a different 399 control plane. The I2RS enabled control plane could provide the Data 400 Center 4 tier infrastructure the quick access to topology and data 401 flow information needed for traffic flow optimization. Changes to 402 the Data Center infrastructure done via I2RS could have a tight 403 feedback loop. 405 Again, this solution would reduce the need for new and specialized 406 protocols while giving the Data Center the control it desire. The 407 I2RS routing interface could be extended to virtual routers. 409 Summary of I2RS Capabilities and Interactions: 411 o PI-REQ01: The ability to monitor the available routes installed in 412 the RIB of each forwarding device, including near real time 413 notification of route installation and removal. This information 414 must include the destination prefix (NLRI), a table identifier (if 415 the forwarding device has multiple forwarding instances), the 416 metric of the installed route, and an identifier indicating the 417 installing process. 419 o PI-REQ04: The ability to interact with various policies configured 420 on the forwarding devices, in order to inform the policies 421 implemented by the dynamic routing processes. This interaction 422 should be through existing configuration mechanisms, such as 423 NETCONF, and should be recorded in the configuration of the local 424 device so operators are aware of the full policy implemented in 425 the network from the running configuration. 427 o PI-REQ05: The ability to interact with traffic flow and other 428 network traffic level measurement protocols and systems, in order 429 to determine path performance, top talkers, and other information 430 required to make an informed path decision based on locally 431 configured policy. 433 o PI-REQ06: The ability to install destination based routes in the 434 local RIB of each forwarding device. This must include the 435 ability to supply the destination prefix (NLRI), a table 436 identifier (if the forwarding device has multiple forwarding 437 instances), a route preference, a route metric, a next hop, an 438 outbound interface, and a route process identifier. 440 o PI-REQ07: The ability to read the local RIB of each forwarding 441 device, including the destination prefix (NLRI), a table 442 identifier (if the forwarding device has multiple forwarding 443 instances), the metric of each installed route, a route 444 preference, and an identifier indicating the installing process. 446 o PI-REQ08: The ability to read the tables of other local protocol 447 processes running on the device. This reading action should be 448 supported through an import/export interface which can present the 449 information in a consistent manner across all protocol 450 implementations, rather than using a protocol specific model for 451 each type of available process. 453 o PI-REQ09: The ability to inject information directly into the 454 local tables of other protocol processes running on the forwarding 455 device. This injection should be supported through an import/ 456 export interface which can inject routing information in a 457 consistent manner across all protocol implementations, rather than 458 using a protocol specific model for each type of available 459 process. 461 6. Temporary Overlays between Data Centers 463 Data Centers within one organization may operate as one single entity 464 even though they may be geographically distributed. Applications are 465 load balanced within Data Centers and between data centers to take 466 advantage of cost economics in power, storage, and server 467 availability for compute resources. Applications are also transfer 468 to alternate data centers in case of failures within a data center. 469 To reduce time during failure, Data Centers often replicate user 470 storage between two or more data centers. During the transfer of 471 stored information prior to a Data Center to Data Center move, the 472 Data Center controllers need to dynamically acquire a large amount of 473 inter-data center bandwidth through an overlay network, often during 474 off hours. 476 I2RS could provide the connection between the overlay network 477 configuration, local policies, and the control plane to dynamically 478 bring a large bandwidth inter-data center overlay or channel into 479 use, and then to remove it from use when the data transfer is 480 completed. 482 Similarly, during a fail-over, a control process within data centers 483 interacts with a group host process and the network to seamless move 484 the processing to another data center. During the fail-over case, 485 additional process state may need to be moved as well to restart the 486 system. The difference between these data-to-data center moves is 487 immediate and urgent need to move systems. If an application (such 488 as medical or banking services) pays to have this type of fail-over, 489 it is likely the network service this application uses will pay for 490 the preemption on network bandwidth and a Quality of Service (QoS) on 491 the data transfer to allow the failover traffic to flow quickly to 492 the remote datacenter. I2RS can allow the Data Center network and 493 the Network connecting the data center to preempt other best-effort 494 traffic to send this priority data flow and to set a QoS that will 495 allow quick data transfer. After the high priority data flow has 496 finished, networks can return to their previous condition. 498 Summary of I2RS Capabilities and Interactions: 500 o PI-REQ01: The ability to monitor the available routes installed in 501 the RIB of each forwarding device, including near real time 502 notification of route installation and removal. This information 503 must include the destination prefix (NLRI), a table identifier (if 504 the forwarding device has multiple forwarding instances), the 505 metric of the installed route, and an identifier indicating the 506 installing process. 508 o PI-REQ02: The ability to install source and destination based 509 routes in the local RIB of each forwarding device. This must 510 include the ability to supply the destination prefix (NLRI), the 511 source prefix (NLRI), a table identifier (if the forwarding device 512 has multiple forwarding instances), a route preference, a route 513 metric, a next hop, an outbound interface, and a route process 514 identifier. 516 o PI-REQ05: The ability to interact with traffic flow and other 517 network traffic level measurement protocols and systems, in order 518 to determine path performance, top talkers, and other information 519 required to make an informed path decision based on locally 520 configured policy. 522 o PI-REQ06: The ability to install destination based routes in the 523 local RIB of each forwarding device. This must include the 524 ability to supply the destination prefix (NLRI), a table 525 identifier (if the forwarding device has multiple forwarding 526 instances), a route preference, a route metric, a next hop, an 527 outbound interface, and a route process identifier. 529 o PI-REQ07: The ability to read the local RIB of each forwarding 530 device, including the destination prefix (NLRI), a table 531 identifier (if the forwarding device has multiple forwarding 532 instances), the metric of each installed route, a route 533 preference, and an identifier indicating the installing process. 535 o PI-REQ10: The ability to interact with policies and configurations 536 on the forwarding devices using time based processing, either 537 through timed auto-rollback or some other mechanism. This 538 interaction should be through existing configuration mechanisms, 539 such as NETCONF, and should be recorded in the configuration of 540 the local device so operators are aware of the full policy 541 implemented in the network from the running configuration. 543 7. Comparison of I2RS requirements with I2RS RIB Information Model 545 Comparison of I2RS Capabilities versus the I2RS RIB 547 In summary, the I2RS client/agent architecture and protocol SHOULD 548 support the following requirements: 550 PI-RIB_IM-REQ01: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] 551 specifies the routes as associated with routing-instance, 552 interface-list and RIBs within a Router (virtual or physical) 553 identified by Router_ID. Each route has a prefixes, route 554 attributes, family attributes (IPv4, Ipv6, MPLS, MAC, interface), 555 and next-hop list. The RIB info model does not keep information 556 on the FIB the route was installed in, the metric of the installed 557 route, or the identifier of the installing process. The RIB Info 558 Model [I-D.ietf-i2rs-rib-info-model] does provide a notification 559 for route change with an installed in FIB flag, active flag, and 560 reason (for non-installation). 562 PI-RIB_IM-REQ02: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] 563 supports installing source-destination routes for IPv4 and IPv6 564 for a RIB associated with set of RIBs within a route instance of a 565 Router (virtual or physical). If there is policy that links RIBs 566 within a route instance of router to a specific FIB, it is not 567 clearly stated in the RIB Info Model 568 [I-D.ietf-i2rs-rib-info-model]. The source-destination is only 569 for IPv4 and IPv6 NLRI. PI-RIB_IM-REQ02: The RIB Info Model 570 [I-D.ietf-i2rs-rib-info-model]. does has a route_preference 571 (ROUTE_PREFERENCE), but not a route metric. The nexthop field 572 does have a primary/back preference, a load balancing weight, and 573 an egress (outbound) interface per nexthop, and a RIB_ID. It is 574 unclear if the RIB_ID serves the same purpose as the multiple 575 forwarding instances. 577 PI-RIB_IM-REQ03: The RIB Info Model does not provide a specific 578 indication that the default (zero length prefix) route can be 579 installed, but this can be implied from the different match 580 lengths. 582 PI-RIB_IM-REQ04: The ability to interact with various policies via 583 existing configuration functions such as NETCONF has not be 584 specified directly in RIB Informational Model 585 [I-D.ietf-i2rs-rib-info-model] or any other informational model. 587 PI-TED-REQ01/PI-RIB_IM_REQ05: The PI-REQ05 use case requirement 588 requires the ability to interact with traffic flow and other 589 network traffic level measurement protocols and systems is not 590 included the I2RS RIB information model. The traffic flow and 591 traffic level measurement does not need to be in the I2RS RIB, but 592 in some Traffic Engineering Information model. 594 PI-RIB_IM-REQ06: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] 595 supports installing destination routes in a RIB for all RIB 596 families from a route-instance. The route_instance is identified 597 by the tuple of INSTANCE_NAME and ROUTER_ID. Each route may 598 contain a route preference and multiple next hops, but it does not 599 contain a metric per route. Each nexthop may contains a RIB_ID to 600 look-up nexthop, an egress-interface, tunnel nexthop (logical or 601 encapsulated). This must include the ability to supply the 602 destination prefix (NLRI), a table identifier (if the forwarding 603 device has multiple forwarding instances), a route preference, a 604 route metric, a next hop, an outbound interface, and a route 605 process identifier. 607 PI-RIB_IM-REQ07: The RIB Info Model [I-D.ietf-i2rs-rib-info-model] 608 supports the ability to read the RIBs associated with each 609 routing-instance. The routing instance is identified by tuple of 610 ROUTE_INSTANCE plus optionally interface_list and router ID. The 611 RIBS are identified by NAME and RIB_FAMILY. The routes within the 612 RIB Can be identified by route-match that identifies destination 613 (IPv4, IPv6, IEEE MAC, MPLS, interface). The information read per 614 route is the destination prefix (NLRI), route preference and 615 multiple nexthops (each with associated metric and RIB). However, 616 it does not indicate the metric of an installed route and the 617 identifier of the installing process. 619 PI-RIB_IM-REQ08: The ability to read the tables of other local 620 protocol processes running on the device. This reading action 621 should be supported through an import/export interface which can 622 present the information in a consistent manner across all protocol 623 implementations, rather than using a protocol specific model for 624 each type of available process. 626 PI-RIB_IM-REQ09: No informational model supports the ability to 627 inject information of other protocol processing running on the 628 forwarding device. The RIB Info Model 629 [I-D.ietf-i2rs-rib-info-model] inserts the routes with RIB with a 630 The ability to inject information directly into the local tables 631 of other protocol processes running on the forwarding device. 632 This injection should be supported through an import/export 633 interface which can inject routing information in a consistent 634 manner across all protocol implementations, rather than using a 635 protocol specific model for each type of available process. 637 PI-RIB_IM-REQ10: The ability to interact with policies and 638 configurations on the forwarding devices using time based 639 processing, either through timed auto-rollback or some other 640 mechanism. This interaction should be through existing 641 configuration mechanisms, such as NETCONF, and should be recorded 642 in the configuration of the local device so operators are aware of 643 the full policy implemented in the network from the running 644 configuration. 646 8. References 648 8.1. Normative References 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, March 1997. 653 8.2. Informative References 655 [I-D.ietf-i2rs-architecture] 656 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 657 Nadeau, "An Architecture for the Interface to the Routing 658 System", draft-ietf-i2rs-architecture-04 (work in 659 progress), June 2014. 661 [I-D.ietf-i2rs-problem-statement] 662 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 663 Routing System Problem Statement", draft-ietf-i2rs- 664 problem-statement-04 (work in progress), June 2014. 666 [I-D.ietf-i2rs-rib-info-model] 667 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 668 Information Base Info Model", draft-ietf-i2rs-rib-info- 669 model-03 (work in progress), May 2014. 671 [I-D.lapukhov-bgp-routing-large-dc] 672 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 673 routing in large-scale data centers", draft-lapukhov-bgp- 674 routing-large-dc-06 (work in progress), August 2013. 676 Authors' Addresses 678 Russ White 679 Ericsson 681 Email: russw@riw.us 683 Susan Hares 684 Huawei 686 Email: shares@ndzh.com 687 Alvaro Retana 688 Cisco Systems, Inc. 689 7025 Kit Creek Road 690 Research Triangle Park, NC 27617 691 USA 693 Email: aretana@cisco.com