idnits 2.17.00 (12 Aug 2021) /tmp/idnits31308/draft-hares-i2rs-usecase-reqs-summary-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 4, 2014) is 2878 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SFC-Use-REQ06' is mentioned on line 923, but not defined == Missing Reference: 'SFC-Use-REQ07' is mentioned on line 947, but not defined == Missing Reference: 'MPLS-TE-REQ-05' is mentioned on line 1026, but not defined == Missing Reference: 'MPLS-TE-REQ-06' is mentioned on line 1035, but not defined == Missing Reference: 'MPLS-TE-REQ-07' is mentioned on line 1043, but not defined == Missing Reference: 'MPLS-TE-REQ-08' is mentioned on line 1053, but not defined == Missing Reference: 'MPLS-TE-09' is mentioned on line 1058, but not defined == Missing Reference: 'MPLS-TE-REQ-10' is mentioned on line 1067, but not defined == Missing Reference: 'MPLS-TE-REQ-11' is mentioned on line 1071, but not defined == Missing Reference: 'MPLS-TE-REQ-12' is mentioned on line 1073, but not defined == Missing Reference: 'MPLS-TE-REQ-13' is mentioned on line 1077, but not defined == Missing Reference: 'MPLS-LDP-REQ-01' is mentioned on line 1088, but not defined == Missing Reference: 'MPLS-LDP-REQ-02' is mentioned on line 1096, but not defined == Missing Reference: 'MPLS-LDP-REQ-03' is mentioned on line 1103, but not defined == Missing Reference: 'MPLS-LDP-REQ04' is mentioned on line 1114, but not defined == Missing Reference: 'I-D.ietf-cdni-framework' is mentioned on line 1348, but not defined == Unused Reference: 'RFC2119' is defined on line 1404, but no explicit reference was found in the text == Unused Reference: 'RFC3746' is defined on line 1407, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 1452, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1457, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-problem-statement' is defined on line 1462, but no explicit reference was found in the text == Unused Reference: 'I-D.lapukhov-bgp-routing-large-dc' is defined on line 1485, but no explicit reference was found in the text == Unused Reference: 'RFC5212' is defined on line 1519, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-chen-i2rs-ts-use-case-00 == Outdated reference: A later version (-03) exists of draft-hares-i2rs-use-case-vn-vc-02 == Outdated reference: A later version (-02) exists of draft-huang-i2rs-mpls-te-usecases-01 == Outdated reference: draft-ietf-i2rs-architecture has been published as RFC 7921 == Outdated reference: draft-ietf-i2rs-problem-statement has been published as RFC 7920 == Outdated reference: draft-ietf-i2rs-rib-info-model has been published as RFC 8430 == Outdated reference: draft-ietf-sfc-problem-statement has been published as RFC 7498 == Outdated reference: A later version (-02) exists of draft-ji-i2rs-usecases-ccne-service-01 == Outdated reference: A later version (-04) exists of draft-keyupate-i2rs-bgp-usecases-03 == Outdated reference: A later version (-07) exists of draft-lapukhov-bgp-routing-large-dc-06 == Outdated reference: A later version (-06) exists of draft-white-i2rs-use-case-05 Summary: 0 errors (**), 0 flaws (~~), 36 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 i2rs S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational July 4, 2014 5 Expires: January 5, 2015 7 Summary of I2RS Use Case Requirements 8 draft-hares-i2rs-usecase-reqs-summary-00 10 Abstract 12 The I2RS Working Group (WG) has described a set of use cases that the 13 I2RS systems could fulfil. This document summarizes these use cases. 14 It is designed to provide requirements that will aid the design of 15 the I2RS architecture, Information Models, Data Models, Security, and 16 protocols. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 5, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Protocol Independent Use Case Requirements . . . . . . . . . 4 54 3. BGP Use Case Requirements . . . . . . . . . . . . . . . . . . 5 55 4. IGP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5. CCNE Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9 57 6. Topology Related Use Cases . . . . . . . . . . . . . . . . . 10 58 6.1. Virtual Connection Use Case Requirements . . . . . . . . 10 59 6.2. Virtual Network Use Case Requirements . . . . . . . . . . 11 60 6.3. Topology Use Case . . . . . . . . . . . . . . . . . . . . 12 61 6.4. Virtual Topology Data Model . . . . . . . . . . . . . . . 17 62 6.5. Virtual Topology IP Data Model . . . . . . . . . . . . . 18 63 6.6. Virtual Topology Network Element . . . . . . . . . . . . 19 64 7. Requirements from SFC Use Cases . . . . . . . . . . . . . . . 20 65 8. Requirements from Traffic Steering Use Cases . . . . . . . . 21 66 9. Requirements from MPLS TE Networks Use Cases . . . . . . . . 22 67 10. Requirements from MPLS LDP Networks Use Cases . . . . . . . . 24 68 11. Requirements from Mobile Backhaul Ues Cases . . . . . . . . . 25 69 12. Requirements from :arge Data Flows are . . . . . . . . . . . 27 70 13. Large Data Collection Systems . . . . . . . . . . . . . . . . 28 71 14. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 72 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 73 16. Security Considerations . . . . . . . . . . . . . . . . . . . 30 74 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 75 17.1. Normative References . . . . . . . . . . . . . . . . . . 31 76 17.2. Informative References . . . . . . . . . . . . . . . . . 31 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 79 1. Introduction 81 The Architecture for the Interface to the Routing System 82 [I-D.ietf-i2rs-architecture] allows for a mechanism where the 83 distributed control plane can be augmented by an outside control 84 plane through an open, accessible interface. This document 85 summarizes the use case requirements for theI2RS client-I2RS Agent 86 exchange found in the following documents: 88 o Protocol Independent described in [I-D.white-i2rs-use-case] 90 o BGP described in [I-D.keyupate-i2rs-bgp-usecases] 92 o IGP protocols as described in [draft-ietf-wu-i2rs-igp-usecases] 94 o Control of Forwarding Path by Central Control Network Element 95 (CCNE) [I-D.ji-i2rs-usecases-ccne-service] 97 o Virtual Connections and Virtual Networks described in 98 [I-D.hares-i2rs-use-case-vn-vc] 100 o Topology use cases [I-D.amante-i2rs-topology-use-cases] 102 o Topology requirements [I-D.medved-i2rs-topology-requirements] 104 o Service chaining described in [I-D.bitar-i2rs-service-chaining] 106 o Traffic Steering described in [I-D.chen-i2rs-ts-use-case] 108 o MPLS TE Networks described in [I-D.huang-i2rs-mpls-te-usecases] 110 o MPLS LDP Networks described in [I-D.chen-i2rs-mpls-ldp-usecases] 112 o Mobile BackHaul Use cases described in 113 [I-D.zhang-i2rs-mbb-usecases] 115 o Large Flows use case described in 116 [I-D.krishnan-i2rs-large-flow-use-case] 118 o Large Data Collection Systems Use cases described in 119 [I-D.swhyte-i2rs-data-collection-system] 121 o CDNI requesting routing 122 [I-D.shin-i2rs-usecases-cdni-request-routing] 124 Each group of use cases is presented in its own document. Each use 125 case is labeled with an identifier TTT-REQ-nn where TTT represents 126 the type of use case. The abbreviations for TTT are: 128 o PI - Protocol Independent 130 o BGP - BGP 132 o IGP - IGP protocols 134 o CCNE - CCNE control of forwarding path 136 o VCoD - Virtual Connections on Demand 138 o VNoD - Virtual Networks on Demand 140 o Topo - Topology Information 142 o VT-TMD - Virtual Topology: Topology Data Model 144 o VT-TDM-IP - Virtual Topology: Topology Data Mode for IP/MPLS 145 o SFC - Service Chaining requirements 147 o TS - Traffic Steering 149 o MPLS-LDP - MLPS Topologies supported by LDP 151 o MPLS-TE - MPLS-TE topologies 153 o MBH - Mobile Back-Haul 155 o L-Flow - Large Flows 157 o L-Data - Large Data Collection 159 o CDNI - CDNI networks 161 2. Protocol Independent Use Case Requirements 163 This is a summary of the I2RS requirements found in the Protocol 164 Independent Use Cases described in: [I-D.white-i2rs-use-case]: 166 o PI-REQ01: The ability to monitor the available routes installed in 167 the RIB of each forwarding device, including near real time 168 notification of route installation and removal. This information 169 must include the destination prefix (NLRI), a table identifier (if 170 the forwarding device has multiple forwarding instances), the 171 metric of the installed route, and an identifier indicating the 172 installing process. 174 o PI-REQ02: The ability to install source and destination based 175 routes in the local RIB of each forwarding device. This must 176 include the ability to supply the destination prefix (NLRI), the 177 source prefix (NLRI), a table identifier (if the forwarding device 178 has multiple forwarding instances), a route preference, a route 179 metric, a next hop, an outbound interface, and a route process 180 identifier. 182 o PI-REQ03: The ability to install a route to a null destination, 183 effectively filtering traffic to this destination. 185 o PI-REQ04: The ability to interact with various policies configured 186 on the forwarding devices, in order to inform the policies 187 implemented by the dynamic routing processes. This interaction 188 should be through existing configuration mechanisms, such as 189 NETCONF, and should be recorded in the configuration of the local 190 device so operators are aware of the full policy implemented in 191 the network from the running configuration. 193 o PI-REQ05: The ability to interact with traffic flow and other 194 network traffic level measurement protocols and systems, in order 195 to determine path performance, top talkers, and other information 196 required to make an informed path decision based on locally 197 configured policy. 199 o PI-REQ06: The ability to install destination based routes in the 200 local RIB of each forwarding device. This must include the 201 ability to supply the destination prefix (NLRI), a table 202 identifier (if the forwarding device has multiple forwarding 203 instances), a route preference, a route metric, a next hop, an 204 outbound interface, and a route process identifier. 206 o PI-REQ07: The ability to read the local RIB of each forwarding 207 device, including the destination prefix (NLRI), a table 208 identifier (if the forwarding device has multiple forwarding 209 instances), the metric of each installed route, a route 210 preference, and an identifier indicating the installing process. 212 o PI-REQ08: The ability to read the tables of other local protocol 213 processes running on the device. This reading action should be 214 supported through an import/export interface which can present the 215 information in a consistent manner across all protocol 216 implementations, rather than using a protocol specific model for 217 each type of available process. 219 o PI-REQ09: The ability to inject information directly into the 220 local tables of other protocol processes running on the forwarding 221 device. This injection should be supported through an import/ 222 export interface which can inject routing information in a 223 consistent manner across all protocol implementations, rather than 224 using a protocol specific model for each type of available 225 process. 227 o PI-REQ10: The ability to interact with policies and configurations 228 on the forwarding devices using time based processing, either 229 through timed auto-rollback or some other mechanism. This 230 interaction should be through existing configuration mechanisms, 231 such as NETCONF, and should be recorded in the configuration of 232 the local device so operators are aware of the full policy 233 implemented in the network from the running configuration. 235 3. BGP Use Case Requirements 237 This is a summary of the requirements listed in 238 [I-D.keyupate-i2rs-bgp-usecases] are: 240 o BGP-REQ01: I2RS client/agent exchange SHOULD support the read, 241 write and quick notification of status of the BGP peer operational 242 state on each router within a given Autonomous System (AS). This 243 operational status includes the quick notification of protocol 244 events that proceed a destructive tear-down of BGP session 246 o BGP-REQ02: I2RS client SHOULD be able to push BGP routes with 247 custom cost communities to specific I2RS agents on BGP routers for 248 insertion in specific BGP Peer(s) to aid Traffic engineering of 249 data paths. These routes SHOULD be tracked by the I2RS Agent as 250 specific BGP routes with customer cost communities. These routes 251 (will/will not) installed via the RIB-Info. 253 o BGP-REQ03: I2RS client SHOULD be able to track via read/ 254 notifications all Traffic engineering changes applied via I2RS 255 agents to BGP route processes in all routers in a network. 257 o BGP-REQ04: I2RS Agents SHOULD support identification of routers as 258 BGP ASBRs, PE routers, and IBGP routers. 260 o BGP-REQ05: I2RS client-agent SHOULD support writing traffic flow 261 specifications to I2RS Agents that will install them in associated 262 BGP ASBRs and the PE routers. 264 o BGP-REQ06: I2RS Client SHOULD be able to track flow specifications 265 installed within a IBGP Cloud within an AS via reads of BGP Flow 266 Specification information in I2RS Agent, or via notifications from 267 I2RS agent 269 o BGP-REQ07: I2RS client-agent exchange SHOULD support the I2RS 270 client being able to prioritize and control BGP's announcement of 271 flow specifications after status information reading BGP ASBR and 272 PE router's capacity. BGP ASBRs and PE routers functions within a 273 router MAY forward traffic flow specifications received from EBGP 274 speakers to I2RS agents, so the I2RS Agent SHOULD be able to send 275 these flow specifications from EBGP sources to a client in 276 response to a read or notification. 278 o BGP-REQ08: I2RS Client SHOULD be able to read BGP route filter 279 information from I2RS Agents associated with legacy BGP routers, 280 and write filter information via the I2RS agent to be installed in 281 BGP RR. The I2RS Agent SHOULD be able to install these routes in 282 the BGP RR, and engage a BGP protocol action to push these routers 283 to ASBR and PE routers. 285 o BGP-REQ09: I2RS client(s) SHOULD be able to request the I2RS agent 286 to read BGP routes with all BGP parameters that influence BGP best 287 path decision, and write appropriate changes to the BGP Routes to 288 BGP and to the RIB-Info in order to manipulate BGP routes 290 o BGP-REQ10: I2RS client SHOULD be able instruct the I2RS agent(s) 291 to notify the I2RS client when the BGP processes on an associated 292 routing system observe a route change to a specific set of IP 293 Prefixes and associated prefixes. Route changes include: 1) 294 prefixes being announced or withdrawn, 2) prefixes being 295 suppressed due to flap damping, or 3) prefixes using an alternate 296 best-path for a given IP Prefix. The I2RS agent should be able to 297 notify the client via publish or subscribe mechanism. 299 o BGP-REQ11: I2RS client SHOULD be able to read BGP route 300 information from BGP routers on routes in received but rejected 301 from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, 302 but not selected as best path, and on route not sent to IBGP peers 303 (due to non-selection). 305 o BGP-REQ12: I2RS client SHOULD be able to request the I2RS agent to 306 read installed BGP Policies. 308 o BGP-REQ13: I2RS client SHOULD be able to instruct the I2RS Agent 309 to write BGP Policies into the running BGP protocols and into the 310 BGP configurations. 312 o BGP-REQ14: I2RS client-agent SHOULD be able to read BGP statistics 313 associated with Peer, and to receive notifications when certain 314 statistics have exceeded limits. An example of one of these 315 protocol statistics is the max-prefix limit. 317 o BGP-REQ15: The I2RS client via the I2RS agent MUST have the 318 ability to read the loc-RIB-In BGP table that gets all the routes 319 that the CE has provided to a PE router. 321 o BGP-REQ16: The I2RS client via the I2RS agent MUST have the 322 ability to install destination based routes in the local RIB of 323 the PE devices. This must include the ability to supply the 324 destination prefix (NLRI), a table identifier, a route preference, 325 a route metric, a next-hop tunnel through which traffic would be 326 carried 328 o BGP-REQ17: The I2RS client via the I2RS agent SHOULD have the the 329 ability to read the loc-RIB-in BGP table to discover overlapping 330 routes, and determine which may be safely marked for removal. 332 o BGP-REQ18: The I2RS client via the I2RS Agent SHOULD have the 333 ability to modify filtering rules and initiate a re-computation of 334 the local BGP table through those policies to cause specific 335 routes to be marked for removal at the outbound eBGP edge. 337 4. IGP Use Cases 339 This is a summary of the requirements listed in (ietf-draft-wu-ir2s- 340 igp-usecases-00.txt) 342 o IGP-REQ-01: I2RS Client/Agent SHOULD Be able to read/write the the 343 unique IGP identification for router within an AS (router-id, 344 system-id, or others). I2RS agents may notify the I2RS client of 345 the detection of another router with the same unique ID 347 o IGP-REQ-02: I2RS Client SHOULD BE able to aid in IGP table 348 reduction by actively monitoring IGP tables, allowing updates of 349 IGP configuration in order to partition the IGPS and place ABR and 350 ASBRs. The I2RS Client/Agent exchange must allopw for a rapid 351 cycle of querying of IGP topology information and downloading of a 352 new protocol configuration to rapidly switch to new temporary IGP 353 topologies. 355 o IGP-REQ-03: I2RS protocol and models should support Loop-Free 356 Alternative (LFAs) [RFC5286] deployments in in pure IP and MPLS/ 357 LDP networks to provide single-point-failure protection for 358 unicast traffic. This includes the configuration, monitoring of 359 LFA changes, and letting off-line pre-computed paths for LFA 360 backup of all links and prefixes in the network and calculating 361 the protection coverage and recognizing optimization to be 362 downloaded to appropriate devices via the I2RS interface (Client- 363 Agent). Again, it is important to have deployment of changes 364 followed by real-time feedback. 366 o IGP-REQ-04: The I2RS programmatic interface SHOULD allow the 367 balancing of both ECMP traffic flows and end-to-end traffic flows 368 in the IGP. The I2RS SHOULD support monitoring of the dynamic 369 traffic flow in the network, and the query of the maximum capacity 370 of the network. This include the I2RS client's transmission to 371 the I2RS agent of updated configuration after an off-line 372 optimization to either spread traffic (across ECMP pathways) or 373 aggregation of traffic onto a single path so the rest of the 374 devices may power off saving power (and money. 376 o IGP-REQ-05: The I2RS interface (protocol and data models) SHOULD 377 use the subscription mechanism to filter the topology changes to 378 interested events and use the publish mechanism to control the 379 pace these events are notified. This filtering should protect the 380 I2RS Client or even applications who depend on topology data from 381 being drowned by massive original events or duplicate events from 382 different sources 384 o IGP-REQ-06: Since IGP protocol is essential to the whole network, 385 the I2RS Clients SHOULD monitor about the protocol's running 386 status before forwarding is impacted. Performance data can be 387 collected through collecting static configuration and observing 388 dynamic status. Static data includes the number of instances, 389 interfaces, nodes in the network and etc. Dynamic data includes 390 adjacency status, the number of entries in link-state database and 391 in the routing table, the calculation status, the overload status, 392 the graceful switch-over status, and others 394 o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a 395 mechanism where the I2RS Clients can subscribe to the I2RS Agent's 396 notification of critical node IGP events. For example, link-state 397 database or routing table is under the status of overflow or the 398 overflow status is released, the calculation continues for a long 399 time, the system is under graceful reboot. 401 o IGP-REQ-08: The I2RS interface (protocol and IMs) should support 402 the reporting of IGP statistic such as dropped packet statistics. 403 These statistics will aid detection of network failures or 404 secruity attacks. 406 5. CCNE Use Cases 408 The use cases in I2RS Use Cases for Control of the Forwarding Path by 409 a Central Control Network Element (CCNE) 410 [I-D.ji-i2rs-usecases-ccne-service] indicate the following 411 requirements for I2RS: 413 o CCNE-REQ-01: I2RS interface should support I2RS client running on 414 a CCNE to be able to pull information from both the BGP RR and the 415 PCE. This information can include: BGP topology information, BGP 416 routes, BGP statistics, BGP Peer topologies, PCE topology 417 information, and PCE state information. The I2RS Client's request 418 for reading of the RR and PCE topology information needs to have 419 timely and rapid response from the I2RS Agent. 421 o CCNE-REQ-02: I2RS client should be able to set resource 422 constraints at the I2RS Agent, and receive status information on 423 the setting of resource constraints. 425 o CCNE-REQ-03: I2RS interface should be able to set service goal 426 value to CCNE. 428 o CCNE-REQ-04: I2RS client should be able support information models 429 that allow re-optimization traffic model at at CCNE . 431 o CCNE-REQ-05: I2RS client should be able to receive notification at 432 the CCNE, and be able to send status to the I2RS agent. 434 o CCNE-REQ-06: I2RS client should work in parallel with traditional 435 network management or OAM protocols sent to the general NE. 437 o CCNE-REQ-07: I2RS clients should be able to to be light weight 438 enough to be able to support running on a variety of devices 439 (routers, centralized servers, or devices doing both). 441 6. Topology Related Use Cases 443 This section describes Topology or Virtual Topology related 444 requirements the I2RS interface (protocol and information model (IM) 445 included in the following types of use cases: 447 o Virtual Connections on Demand: VCoD-REQ 449 o Virtual Networks on Demand: VNoD-REQ 451 o Virtual Topology Information Topo-REQ 453 o Virtual Topology Data Model: VT-TDM-REQ 455 o Virtual Topology IP Data Model: VT-TDMIP-REQ 457 o Virtual Topology Network Element: VT-NE-REQ (TMF-GEN-1) 459 6.1. Virtual Connection Use Case Requirements 461 o VCoD-REQ01: I2RS Agents SHOULD provide the ability to read the 462 virtual network topology database for the technology supported. 463 For optical, these are the optical connections and what node they 464 connect to, and the topologies created. For MPLS, this is virtual 465 circuit available, what nodes they connect to, and the network 466 topologies created. For IP technologies, this could include the 467 GRE tunnels, what interface it connects to, and the topologies 468 created. For Ethernet circuits this should involve circuit type 469 (e.g, point-to-point (p2p) or point-to-multipoint (p2mp)) and what 470 nodes it can reach, and the topologies created. 472 o VCoD-REQ02: I2RS Agent SHOULD provide the ability to influence the 473 configuration of a virtual circuit in a node. 475 o VCoD-REQ03: I2RS Agent SHOULD provide monitor and provide 476 statistics on the virtual connection to the I2RS client via a Read 477 request or status Notification. The I2RS client can then 478 determine if the connection falls below a quality level the 479 application has requested. If the I2RS client does determine the 480 circuit is below the required quality, it could create another 481 circuit. The I2RS may choose to create the second virtual 482 circuit, transfer flows, and then break the first circuit. 484 6.2. Virtual Network Use Case Requirements 486 The requirements for the Virtual Networks on Demand (VCoD) are: 488 o VT-VN-REQ01: I2RS Agents SHOULD provide the ability to read the 489 virtual network topology database for the technology supported to 490 determine nodes and connections. For optical, these are the 491 optical connections and what node they connect to, and the 492 topologies created. For MPLS, this is virtual circuit available, 493 what nodes they connect to, and the network topologies created. 494 For IP technologies, this could include the GRE tunnels, what 495 interface it connects to, and the topologies created. For 496 Ethernet circuits this should involve circuit type (e.g, point-to- 497 point (p2p) or point-to-multipoint (p2mp)) and what nodes it can 498 reach, and the topologies created. 500 o VNoD-REQ02: I2RS Agent SHOULD provide the ability to influence the 501 configuration of a virtual circuit in a node. 503 o VNoD-REQ03: I2RS Agent SHOULD provide monitor and provide 504 statistics on the virtual connection to the I2RS client via a Read 505 request or status Notification. The I2RS client can then 506 determine if the connection falls below a quality level the 507 application has requested. If the I2RS client does determine the 508 circuit is below the required quality, it could create another 509 circuit. The I2RS may choose to create the second virtual 510 circuit, transfer flows, and then break the first circuit. 512 o VNoD-REQ04: I2RS Agent SHOULD provide the ability to influence the 513 configuration of a virtual network in a node. 515 o VNoD-REQ05: I2RS Agent SHOULD provide the ability to report 516 statistics on the network nodes and end-to-end traffic flows via 517 read of status data or via notifications of status. 519 o VNoD-REQ06: The I2RS protocol and RIB Informational Model (IM) 520 must support logical tunnels of type MPLS as well as IP, GRE, 521 VxLAN and GRE. Large Carrier networks utilize MPLS in a variety 522 of forms (LDP, static MPLS TE, or dynamic TE LSPS created by RSVP- 523 TE or CR-LDP). 525 o VNoD-REQ07: I2RS SHOULD support Informational Models and featurs 526 to allow MPLS technologies to create Hub-spoke topology and 527 service routing in networks in Carriers, Enterprise, and Data 528 Centers. 530 o VNoD-REQ08: I2RS protocols, Information Models, and Data Models 531 must be able to support Carriers using these MPLS technologies to 532 support networks for Mobile BackHaul, on-demand MPLS overlays, and 533 on-demand video conferencing networkings. 535 6.3. Topology Use Case 537 The requirements in [I-D.amante-i2rs-topology-use-cases] topology use 538 cases focus around the architecture of topology manager, 539 orchestration manager, and policy in the figure below: 541 +---------------+ 542 +----------------+ | 543 | Applications |-+ 544 +----------------+ 545 ^ Websockets, ReST, XMPP... 546 +------------------------+-------------------------+ 547 | | | 548 +------------+ +------------------------+ +-------------+ 549 | Policy |<----| Topology Manager |---->|Orchestration| 550 | Manager | | +--------------------+ | | Manager | 551 +------------+ | |Topology Information| | +-------------+ 552 | | Model | | 553 | +--------------------+ | 554 +------------------------+ 555 ^ ^ ^ 556 Websockets, ReST, XMPP # | * Websockets, ReST, XMPP 557 ####################### | ************************ 558 # | * 559 +------------+ | +------------+ 560 | Statistics | | | Inventory | 561 | Collection | | | Collection | 562 +------------+ | +------------+ 563 ^ | I2RS, NETCONF, SNMP, ^ 564 | | TL1 ... | 565 +------------------------+------------------------+ 566 | | | 567 +---------------+ +---------------+ +---------------+ 568 |Network Element| |Network Element| |Network Element| 569 | +-----------+ | | +-----------+ | | +-----------+ | 570 | |Information| |<-LLDP->| |Information| |<-LMP-->| |Information| | 571 | | Model | | | | Model | | | | Model | | 572 | +-----------+ | | +-----------+ | | +-----------+ | 573 +---------------+ +---------------+ +---------------+ 575 o Topo-REQ:01 The Topology Manager Should be able to collect 576 topological information via the I2RS Client-Exchange exchange from 577 a variety of sources in a normalized topological model. These 578 sources can be: 580 * Live Layer IGP IGPs with information about the active topology 581 such as the LSDB database or IGP updates, 583 * The I2RS must enable the inventory system information to query 584 for information about network components which are not not 585 visible to active L3. These systems can be active or simply 586 invisible to the L3. Examples of this are L2 Ethernet switches 587 or ROADMS. 589 * Statistic Collection systems that provide traffic information, 590 such as traffic demands or link utilizations. 592 (from section 3.2) 594 o Topo-REQ-02: Topology information is provided from Clients to 595 high-layer applications via a northbound interface (such as ReST, 596 Websockts, or XMPP. 598 o Topo-REQ-03: Topology Manager should be able to collect and keep 599 current topology information for multiple layers of the network: 600 Transport, Ethernet and IP/MPLS, as well as information for 601 multiple Layer 3 IGP areas and multiple Autonomous Systems (ASes). 602 This information must contain cross-layer unerlying Shared Risk 603 Link Groups (SRLG) within transport or Ethernet layers. (from 604 section 3.2) 606 o Topo-REQ-04: Topology manager be able to use I2RS Client-Agent 607 protocol to to collect dynamic inventory information from network 608 elements. An example of these protocols are the Link Layer 609 discovery protocols (LLDP, LMP, etc.) which automatically identify 610 remote nodes and ports. (from section 3.2) 612 o Topo-REQ-05:I2RS Should enable the Policy manager to query and 613 store the following types of policies: 615 * Policies that contain Logical identifier Numbering in order to 616 correlate IP Prefixes to 618 + link based on link type (P-P, P-PE, or PE-CE), 620 + IGP Area 622 + L2 VLAN assignments 624 * Routing Configuration policies that correlate: 626 + OSPF area/ISIS Net-ID to Node (type) 628 + BGP node related policies (aggregation routes at node, max- 629 prefix (per node), or AFI/SAFI per node 631 + Security policies - with ACLs or rate-limits 633 + Network Component access policies (for management 635 (from section 3.3) 637 o Topo-REQ-06: I2RS should enable a orchestration manager attached 638 to an I2RS client to communicate with I2RS agents into order to 639 stitch together End-to-end services for network bandwidth 640 optimization, load balancing, and Class-of-Service with point 641 services (Firewall or NAT) within the end-to-end service). The 642 orchestration manager should also be able to immediately schedule 643 any of these resources via the I2RS-Client I2RS agent exchange. 644 (from section 3.4) 646 o Topp-REQ-07: The I2RS exchange should enable a statistics 647 collector to collect statistics from the routing function of the 648 network nodes and archive and aggregate the statistics into a 649 statistics warehouse. Statistics must be given and stored in an 650 normalized form. Metadata must be stored with the statistics. 651 (from section 4.1.1.2) (Editor: there is some suggestion of 652 periodic reports) 654 o Topo-REQ-08: I2RS Client-I2RS agent exchange must be provide 655 enough interoperability that the Topology manager, Policy manager, 656 and inventory systems can be available from different vendors 658 o Topo-REQ-09: TE tunnels must be able to be created by the exchange 659 between the I2RS client and the I2RS agent. (from section 4.1.1) 661 o Topo-Req-10: I2RS must provide a common and up-to-date normalized 662 view of the topologies that that support security auditing, and 663 IP/MPLS Provisioning (L2/L3) which includes: 665 * Identifying Service PE's in all markets/cities where the 666 customer has identified they want service, 668 * Identifying one or more existing Servies PE's in each city with 669 connectivity to the access network(s) ( e.g.: SONET/TDM) used 670 to deliver the PE-CE tail circuits to the Service's PE), 672 * Obtain via query/notification the available capacity on 673 Services PE in both the PE-CE access interface and its uplinks 674 to terminate the tail circuit 676 * Providing the context in I2RS for an iterative query mechanism 677 needed by I2RS client attached to the the Topology to narrow 678 down the scope of resources to the set of Services PEs with the 679 appropriate uplink bandwidth and access circuit capability plus 680 capacity to realize the requested VPN service. 682 (from section 4.1.2) 684 o Topo-REQ-11: The VPN application attached to the I2RS client 685 should be able to hand the I2RS Client a candidate list of Service 686 PE's and associated access circuits to set up a Customer's VPN 687 service into the network. (from section 4.1.3) [Editor's note 688 This request shares requirements with VCoD-REQ-01.] 690 o Topo-REQ-12: The Topology Manager associated with the I2RS client 691 must be able to use the normalized view of the network to set up 692 additional queries (or notification publications) to provide an 693 accurate and comprehensive picture in order a) diagnose faults/ 694 failures, and b) augment the network with additional services, and 695 c) provide network topology maps for different purposes. (from 696 section 4.1.3) 698 o Topo-REQ-13:The I2RS client-agent exchange and informational 699 models should support a Virtual Network Topology (VNT) comprise of 700 one or more LSPS and lower layer resources. The VNT of MPLS must 701 be able to link lower layer resources with the higher layer, and 702 present a normalize form the the PCE as defined [RFC5623]. 704 o Topo-REQ-14: The I2RS client-agent protocol and models should 705 support the use of a PCE to compute MPLS-TE paths within an 706 "domain" (IGP area), or across multiple "domains" (multi-area AS, 707 multiple ASes") as specified in [RFC4655]. This means the PCE 708 Informational model should support: 710 * enhanced computation in the single IGP domain 712 * cross-AS path computation based on the multiple entrance of 713 exit points from an AS, 715 * linking multiple PEs in multiple domains together, and 717 * synchronization of TED associated with the PCE to the topology 718 manager (via I2RS client/messages), and 720 * sending read/writes to the head-end-nodes 722 (section 4.3) 724 o Topo-REQ-15: the I2RS protocol and Information models should 725 support the ALTO ([RFC5693]) generation of abstract network 726 topology models and the APIs it support over web-service API. The 727 ALTO abstract network topology comes in two forms: Network Map 728 (based prefix-to PID mapping), and Cost map. The ALTO map is 729 automatically generated from BGP and IGP data which the ALTO 730 server queries from the network and makes available to 731 applications via web-service API. (from section 4.4) 733 6.4. Virtual Topology Data Model 735 The [I-D.medved-i2rs-topology-requirements] specifies the following 736 Topology Data Model requirements: 738 VT-TDM-REQ1: The topology data model MAY be able to describe 739 topology and characteristics of the following layers: 741 * Optical DWDM (optional), 743 * Optical OTN (optional), 745 * L2 (Aggregated links, L2 topologies), 747 * IP/MPLS, 749 * VPNs, and 751 * Services (such as cloud services, or CDNs). 753 VT-TDM-REQ2: The topology data model MUST support multiple 754 Autonomous System deployments. 756 VT-TDM-REQ3: The I2RS topology data model must support include 757 topology information from multiple Administrative Domains or 758 multiple elements into a single common format. 760 VT-TDM-REQ4: The I2RS topology data model MUST be able to convey 761 enough information so that an I2RS client can correlate topologies 762 in different layers and multiple Autonomous Systems. 764 VT-TDM-REQ5: The topology data model MUST support multi-layer 765 group of elements as a means of coalescing different SFF Nodes and 766 links into a network layers from various layers. For example, 767 links with IPv4 addresses might represent Layer 3 of the network 768 topology while links with Ethernet MAC addresses might represent 769 Layer 2. 771 VT-TDM-REQ6: The topology model should allow association between 772 components of different layers. For example, Layer 2 port may 773 have several IPv4/IPv6 interfaces. The Layer-2 port and the IPv4/ 774 IPv6 interfaces would have an association. 776 VT-TDM-REQ7: The topology model MUST represent both inactive and 777 active topologies in the topology Data base. Inactive topologies 778 may include new line cards, ports in down state, etc. 780 VT-TMF-DM-REQ8: The topology data model MUST be hierarchical and 781 MUST support summarization of sub-topologies. Topology 782 summarization and creation of abstract topologies can be provided 783 by either by the application associated with the I2RS client, or 784 by the I2RS Agent prior to transmission to the I2RS client. 786 VT-TDM-REQ9: The topology data model MUST be able to describe 787 abstract topologies. Abstract topologies can contain real and 788 abstract nodes and real and abstract links. An abstract topology 789 MAY be used by a provider to describe characteristics of a transit 790 network (bandwidth, delay, protection, etc.) 792 VT-TDM-REQ10: The topology data model MUST support dynamic data, 793 such as link and node utilizations (perhaps as optional 794 attributes). 796 VT-TDM-REQ11a: The topology data model MUST allow I2RS client- 797 agent to be able to identify and query for the path between two 798 nodes. 800 VT-TDM-REQ11b: The topology data model should support the I2RS 801 Client requesting the I2RS Agent to trace the path at all network 802 layers that participate in the delivery of packets between two 803 nodes. This trace MAY involve either an I2RS Agent information 804 trace or the I2RS Agent requesting the routing function trace the 805 path at multiple levels (L3/L2.5/L2/L1) 807 VT-TDM-REQ12: The topology data model MUST support multiple BGP 808 Autonomous Systems and multiple IGP areas. Support for multiple 809 administrative domains is for further study. 811 VT-TDM-REQ13: The topology data model MUST be human-friendly, i.e. 812 not SNMP MIBs, but something much more analogous to YANG models. 814 VT-TDM-REQ14: The data model SHOULD support topology abstraction, 815 allowing clients that consume topology information in a 816 constrained manner. For example, a client wishing to view only 817 interfaces and nodes present in a sub-graph of the Layer 3 818 topology should be able to specify an interest in this subset of 819 information rather than having to read out and parse through the 820 entire set of links and nodes. 822 6.5. Virtual Topology IP Data Model 824 The [I-D.medved-i2rs-topology-requirements] specifies the following 825 requirements for the Virtual Topology IP Data Model's IP/MPLS links 826 and topologies: 828 o VT-TDM-IP-REQ1: The I2RS topology data model for the IP/MPLS layer 829 MUST support both link topology and prefixes, 831 o VT-TDM-IP-REQ2: The I2RS agent may import topology information 832 from the routing processes, IGP process, BGP-LS information, or 833 management processes. 835 o TM-DM-IP-REQ3: The I2RS SFC Data model must support links that are 836 IP/MPLS with the following attributes: 838 * local and Remote anchor node IDs (Router ID, AS#, Area ID, MT 839 topology), 841 * metrics, 843 * admin group, 845 * max bandwidth links 847 * unreserved/utilized bandwidth 849 * link-protection type 851 * MPLS protocol mask 853 * link prefix 855 * link characteristics (BW, Delay, error rate) 857 * Link Description, and 859 * Link-specific timers (Hello and Holddown). 861 6.6. Virtual Topology Network Element 863 The [I-D.medved-i2rs-topology-requirements] specifies the following 864 requirements: 866 o VT-NE-01: Each network element should contain an inventory data 867 base which should be a definitive source of information with 868 respect to the physical HW and Logical, logically significant 869 identifiers (E.g. VLANs). The I2RS client should be able to 870 import data from this DB into the I2RS Node IM or SFC IM. 872 o VT-NE-02: The inventory DB of the network element should be 873 augmented with the physical properties associated with the ports/ 874 interfaces that are directly connected to the device (BW, media 875 type). The I2RS client should be able to import data from this 876 augmented DB into the I2RS Node IM or SFC IM. 878 o NE-3: The I2RS client may write information into the NE inventory 879 data base via the Network-element Data Model that the network 880 element may not be able to learn on its own. This information may 881 include the physical location (address), rack/bay information. 883 7. Requirements from SFC Use Cases 885 The SFC use case document in [I-D.bitar-i2rs-service-chaining] 886 suggests that the following requirements: 888 SFC-Use-REQ01:Address 890 has the following address requirements: 892 * IP address 894 * service-node tuple (service node IP address, Host system 895 address) 897 * host-node tuple (hosting system IP-address, system internal 898 identifier) 900 SFC-Use-REQ02:Supported Service Types 902 SHOULD include: NAT, IP Firewall, Load balancer, DPI, and others 904 SFC-Use-REQ03:Virtual contexts 906 SHOULD include: 908 * Maximum Number of virtual contexts supported 910 * Current number of virtual contexts in use 912 * Number of virtual contexts available 914 * Supported Context (VRF) 916 SFC-Use-REQ04: Customers currently on node 918 SFC-Use-REQ05: Customer Support Table (per customer ID) 920 * Customer-id 921 * List of supported Virtual Contexts 923 [SFC-Use-REQ06] Service Resource table 925 which includes: 927 * index: Comprised of service node, virtual context, service type 929 * service bandwidth capacity 931 * supported packet rate (packets/second) 933 * supported bandwidth (kps) 935 * IP Forwarding support: specified as routing-instance(s), RIBs, 936 Address-families supported 938 * Maximum RIB-size 940 * Maximum Forward Data Base size 942 * Maximum Number of 64 bit statistics counters for policy 943 accounting 945 * Maximum number of supported flows for services 947 [SFC-Use-REQ07] Virtual Network Topology (VNT) 949 which includes: 951 * number of access points to which service topology applies 953 * topology of access points 955 8. Requirements from Traffic Steering Use Cases 957 The requirements from the Traffic Steering use case described in 958 [I-D.chen-i2rs-ts-use-case] are: 960 o TS-REQ01: The I2RS Client-Agent must be able to collect the 961 topology (especially the exit links) and the traffic load of each 962 link; 964 o TS-REQ02: The I2RS Client-Agent must be able to read the local rib 965 of each DC/Metro gateway and the policies deployed on each 966 gateway; 968 o TS-REQ03: The I2RS Client-Agent must be able to add or delete or 969 modify the relevant rib items and relevant polices to steer the 970 traffic as expected; and adjust traffic placement. 972 o TS-REQ-04: The I2RS Client-Agent must have the ability to collect 973 the LSP information either from the PCE or directly from network 974 devices; 976 o TS-REQ-05: The I2RS Client-Agent must have the ability to collect 977 the traffic matrix of the network, this is used to help the I2RS 978 client to determine how to adjust the traffic placement; 980 o TS-REQ-06: The I2RS Client-Agent must have the ability to read the 981 rib information and relevant policies of each network node; 983 o TS-REQ-07:collect the topology and segment information needed to 984 help the I2RS client to compute the end-to-end path; 986 o TS-REQ-08:read rib (especially the segment routing rib) 987 information; 989 o TS-REQ-09: add/delete/modify the segment rib, this finally 990 determines how the traffic is forwarded. 992 9. Requirements from MPLS TE Networks Use Cases 994 Theses are the requirements from the Traffic Steering use case 995 described in [I-D.huang-i2rs-mpls-te-usecases]: 997 o MPLS-TE-REQ-01: Network programming software managing the static 998 CR-LSP devices may incorporate an I2RS Client along with a path 999 calculation entity, a label management entity, and a bandwidth 1000 management entity. The I2RS Client should be abl to communicate 1001 the static configuration to the network nodes, and monitor the 1002 status of the CR-LSPs. 1004 o MPLS-TE-REQ-02: The I2Client should be able to synchronously send 1005 the configuration for all of the network nodes from egress node to 1006 ingress node via the I2RS Agents attached to each node, and be 1007 able to delay the final ingress node configuration until all the 1008 I2RS AGents on all other nodes toward the egress have denoted a 1009 successful path set-up. 1011 o [MPLS-TE-REQ-03:] MPLS TE defines abundant constraints such as 1012 explicit path, bandwidth, affinity, SRLG, priority, hop limit, and 1013 others. The I2RS Client Agent exchange should be able to signal 1014 concurrent local path calculation could obtain an optimized result 1015 and allow more services to be held in a TE network. The I2RS 1016 Agent should be able to trigger a global concurrent re- 1017 optimization at a specific time on multiple nodes by communicating 1018 with each node's I2RS agent. 1020 o [MPLS-TE-REQ-04:] The I2RS client should be able to manually 1021 calculate a re-optimization of the the MPLS TE network and send 1022 the new constraints including the calculated path to each node via 1023 the I2RS agent with an indication to re-signal the TE LSPs with 1024 make-before-break method. 1026 o [MPLS-TE-REQ-05] With I2RS, the node's I2RS agent should be able 1027 to send to an I2RS client a status notification that not enough 1028 resources exist for a back up LSP and TE tunnel. Upon receiving 1029 this notification the I2RS client should be able to trigger 1030 concurrent calculation for the failed path calculation of the 1031 backup LSP or TE tunnel and send the updated paths to I2RS agents 1032 with a command to re-signal the TE LSPS with make-before-break 1033 Method. 1035 o [MPLS-TE-REQ-06] With I2RS, upon receipt the failure notification 1036 from an I2RS Agent, the I2RS client would create a global 1037 concurrent optimization to handle the failure event. This would 1038 occur by the I2RS client signalling the I2RS agents on all nodes 1039 to: a) trigger a new concurrent calculation of the backup LSP or 1040 TE tunnel via failed path calculation, and b) re-signal updates to 1041 the TE LSPs process with a make-before-break method. 1043 o [MPLS-TE-REQ-07] Upon receiving a signal an upgrade event signal 1044 (from operator), the I2RS client could calculate another path for 1045 the affected TE tunnels to deviate traffic away from the resource 1046 being upgraded, and then send the request to I2RS agents on the 1047 appropriate nodes to move the traffic. After the upgrade 1048 completes, the I2RS client can simply remove I2RS configurations 1049 causing the traffic to revert to the original path. Or, the I2RS 1050 can re-optimize the TE tunnels for another pathways (E.g. as a 1051 part of a sequence of upgrades). 1053 o [MPLS-TE-REQ-08] I2RS agents can notify I2RS Clients of impending 1054 or existing MPLS TE overload conditions that might cause TE LSP 1055 rejections. This overload conditions include: due to CPU, memory, 1056 LSP label space, or LSP numbers. 1058 o [MPLS-TE-09] Automatic bandwidth adjustment applications can also 1059 be linked to the I2RS clients need to monitor the traffic on TE 1060 tunnels in order to provide traffic analysis. The I2RS client 1061 should be able to read the TE Tunnel topology and the bandwidth 1062 analysis in order to automatically calculate a new path for the TE 1063 tunnel if it is needed. The I2RS Client also needs to be able to 1064 the I2RS agents in the nodes to install the new TE Tunnels with 1065 the make-before-break option. 1067 o [MPLS-TE-REQ-10] With I2RS, the node failure or link failure can 1068 be part of the notification stream sent by an I2RS Agent to an 1069 I2RS Client on a centralized server gathering information. 1071 o [MPLS-TE-REQ-11] The I2RS client can notify the I2RS agents on 1072 specific nodes (or devices) to re-signal TE LSPs one by one if 1073 there is a resource dependency. [MPLS-TE-REQ-12] The I2RS Client 1074 can gather the TE LSPs' state from I2RS Agents on all nodes in 1075 order to coordinate such handling of LSP resources. 1077 o [MPLS-TE-REQ-13] The I2RS Clients collecting information from I2RS 1078 Agents can be arranged in a hierarchy to provide scaling of 1079 collections. An application hosting an I2RS client collecting 1080 information from I2RS Agents on nodes can have an I2RS Agent that 1081 reports combined information to a single location. 1083 10. Requirements from MPLS LDP Networks Use Cases 1085 These are the I2RS requirements for the MPLS LDP use case described 1086 in [I-D.chen-i2rs-mpls-ldp-usecases]: 1088 o [MPLS-LDP-REQ-01]: The I2RS Client-agent exchange should allow the 1089 distribution of the configuration for PWE3, MPLS LDP and 1090 associated protocols to be distributed from a central location 1091 where the global PWE3 provisioning information could be stored. 1092 The I2RS Client-Agent exchange should also be able to push the 1093 configuration of the local LDP LSR ID and peer addresses to set up 1094 the targeted session to the pseudowire endpoints. 1096 o [MPLS-LDP-REQ-02] When an the end-user wants to disable IPoMPLS 1097 (IP over MPLS) application on a L2VPN/PW Targeted LDP session, the 1098 I2RS Client-I2RS agent should be able to set type of application 1099 over the established LDP session. In this way LDP speaker can 1100 only advertise to its peer the application data which the user is 1101 interested in. 1103 o [MPLS-LDP-REQ-03] The I2RS Agent notifications should allow an 1104 I2RS client to subscribe to a stream of state changes regarding 1105 the LDP sessions or LDP LSPs from the I2RS Agent. Specifically it 1106 is important that LDP session is tract for sessions state coming 1107 up or going down. The I2RS Client-I2RS Agent exchange should 1108 allow additional queries to the AGent to determine a) why the 1109 service is invalid, b) calculating whether an alternate path 1110 should be switched to, and c) determining how to switch to other 1111 links or nodes in order to recover from the link failure or node 1112 failure. 1114 o [MPLS-LDP-REQ04] The I2RS interface provides way to monitor and 1115 control the limited resources on these access devices. The I2RS 1116 client should be able to instruct the I2RS agent in each of these 1117 devices to set the maximum number of LDP LSPs in each device prior 1118 to enabling LDP on the devices. The I2RS client should also be 1119 able to enable a notification service on each device with a with a 1120 warning threshold. Once the number of LDP LSPs reaches the 1121 threshold, the I2RS agent will send a notification message to the 1122 I2RS client. Often the I2RS client will be associated a network 1123 management agent that can determine what next steps need to be 1124 done based on policy or operator input. 1126 11. Requirements from Mobile Backhaul Ues Cases 1128 Mobile BackHaul Use cases described in [draft-ietf-zhang-mbb- 1129 usecases-01] are: 1131 o MBH-REQ-01: The I2RS client-agent communication can distribute 1132 position-critical changes to IGP nodes using this global knowledge 1133 to quicken changes to support traffic during failures or traffic 1134 overloads. To enable this feature, the I2RS Clients-Agent 1135 communication needs to pass information on which IGP process or 1136 Level or Area the given node and links belong to. 1138 o MBH-REQ-02: I2RS must allow operators to use of I2RS clients to 1139 distribute time-critical changes in configuration to I2RS agents 1140 associated with each routing node. This feature will simplify and 1141 automate configuration and monitoring of a mobile backhaul network 1142 to allow it to readily adapt to changing network sizes (and 1143 scales) and radio applications. 1145 o MBB-REQ-03: I2RS Clients-Agent communication needs to pass 1146 information on: 1148 * T-LDP configurations and status; 1150 * BGP peer configurations, peer topologies and status; 1152 * BGP-based LSP topologies and status; 1154 * Reset VPN topologies, and per node configurations; 1156 o MBB-REQ04: Route policy enforcement in mobile backhaul networks 1157 needs to be more dynamic and flexible than the current methods 1158 take hours (or even days) to configure route policy across a 1159 network. The I2RS interface must provide a programmatic way to 1160 configure (both policy and device) and monitor thousands of 1161 devices individually whose configuration is based on the devices 1162 role (such as ASRSs in one AS, ASBRs between ASs and other 1163 service-touch nodes). 1165 o MBB-REQ-05: I2RS clients should be able to contact I2RS agents on 1166 nodes to query role-based information from the network status. 1167 After collecting the status, the I2RS client can develop the BGP 1168 policies based on role information and push the BGP policies to 1169 the I2RS agents that would load the alternate policies into the 1170 network device. The I2RS Agents loading the alternate policies 1171 could then send status back to the I2RS Client. 1173 o MBH-REQ06: I2RS clients can provide centralized control of many 1174 network devices via the I2RS Client-Agent communication. The I2RS 1175 programmatic interface can automate the collection and analysis of 1176 each device's capability so that the centralized I2RS client could 1177 calculate the optimal LSP path and distribute the configuration to 1178 individual devices. Automation of the collection of device 1179 capability should be available as query, notification, or a 1180 published stream. 1182 o MBH-REQ07: While the I2RS RIB Information Model 1183 [[I-D.ietf-i2rs-rib-info-model]] provides for routes with tunnels 1184 or MPLS LSP, the features defined in this model are not sufficient 1185 to configure both types of LSPs needed for the VPN technology in 1186 mobile backhaul networks. Additional I2RS Informational models 1187 need to be created to support these features. 1189 o MBH-REQ08: The hierarchical protection architecture in mobile 1190 backhaul network offer high network reliability and more 1191 flexibility to meet the various needs of the tunnels and services. 1192 The I2RS interface in this use case is needed to automate the 1193 configuration and monitoring so that tunnel protection and service 1194 protection interwork in a flexible and reliable manner. 1196 o MBB-REQ09: The I2RS architecture (client-agent) should allow the 1197 two features for network monitoring naturally in its basic modes: 1199 * allow a combination of multi-layer network monitor tools with 1200 exact detection parameters to be configured on the network 1201 device 1203 * Facilitate the reporting the detection result as notification 1204 or publication stream 1206 It is important the result of these features allow the outages and 1207 traffic congestion or discards to be detected real-time with I2RS 1208 Client(s) in each node, and the detection result will be reported 1209 to the I2RS agents to get the exact status of the network. 1211 12. Requirements from :arge Data Flows are 1213 Each of these requirements has been given an an ID number of L-Flow- 1214 nn for ease of reference. 1216 The requirements from the Large Data Flows use case described in 1217 [I-D.krishnan-i2rs-large-flow-use-case] are: 1219 L-Flow-REQ-01: For redirecting large flows to a specific 1220 component, a PBR entry should be programmable for the flow with 1221 its nexthop that identifies the specific LAG or ECMP component. 1223 L-Flow-REQ-02: For adjusting the weights used to distribute 1224 traffic across components of the LAG or ECMP, I2RS should provide 1225 a programmable mechanism should be provided that identifies ECMP 1226 entries and is able to associate weights that can be programmed 1227 for each of the components. To do this in a scalable fashion, it 1228 would be useful to have the notion of an ECMP nexthop that is used 1229 by multiple routes 1231 L-Flow-REQ-03: The I2RS interface (protocol/IMs) should allow for 1232 a globally optimal path is programmed in the IP network using hop- 1233 by-hop PBR rules. These PBR rules may include: 1235 * Being able to adjust the weights of the ECMP table for 1236 different nexthops should be adjusted to factor the large flows 1238 * Being able to address an ECMP group, so that all routes sharing 1239 an ECMP group are addressed together. 1241 * the ability to program PBR entries at the edge LSR, and 1243 * the ability to program new LSPs in the network. 1245 L-Flow-REQ-04: The I2RS protocol should be able to invoke the link 1246 aggregation IEEE 802.1AX Marker Protocol via the I2RS protocol. 1247 This is useful during a period of rebalancing occurs before flows 1248 are moved. 1250 L-Flow-REQ-05: The I2rs protocol should allow Quality of Service 1251 (QoS) actions such as rate-limiting, re-marking, or discarding can 1252 be performed on the flows based on configured policies and nexthop 1253 redirection actions to be programmed, and to be programmed 1254 independently of of each other. 1256 L-Flow-REQ-06: Once a large flow has been detected, I2RS must be 1257 used to modify the forwarding tables in the router to: 1259 * In the case of large flow load balancing, be able to 1260 redirecting the large flow to a particular member with the LAG 1261 or ECMP group and readjusting the weights of the other members 1262 to account for the large flow 1264 * In the case of DDoS mitigation, the action involves rate 1265 limiting, remarking or potentially discarding the large flow in 1266 question. 1268 13. Large Data Collection Systems 1270 The requirements from the Large Data Collection Systems Use cases 1271 described in [draft-swhyte-i2rs-data-collection-system] are: 1273 L-Data-REQ-01: I2rs must be able to collect large data set from 1274 the network with high frequency and resolution with minimal impact 1275 to the device's CPU and memory. 1277 L-Data-REQ-02: I2RS must be able to use a database model where the 1278 data on the network node must be able to be described in the I2RS 1279 exchange as the data plus the structure of the data. The I2RS 1280 management system consumes and understand the data only after it 1281 consumes and understand the database model or has been trained by 1282 vendor published model 1284 L-Data-REQ-03: I2RS should use a pub-sub model which allows 1285 scaling plus push or pull of data. 1287 L-Data-REQ-04: I2RS should support capability negotiation to 1288 inform a subscriber of the options for publication of data. The 1289 options include transport, security, and error handling. 1291 L-Data-REQ-05: The I2RS data tansfer should be format agnostic. 1292 This means the publisher and subscriber may agree upon XML, JSON, 1293 MTL, protobufs or any other format. 1295 L-Data-REQ-06: I2RS Transports must be able to be chosen by a I2RS 1296 Client-I2RS Agent pair. An I2RS Client-I2RS Agent pair should be 1297 allowed to negotiate the transport options from a list of options. 1299 L-DATA-REQ-07: The I2RS interface (protocol and IMs) should allow 1300 a subscribe to select portions of the data model. 1302 L-Data-REQ-08: The I2RS interface (protocol and IMs) should allow 1303 for multiple publish subscriptions at a time. 1305 L-Data-REQ-09: Timestaps should be associated with data that 1306 requires it. Not all data will require a time stamp. Additional 1307 time stamps may be added. 1309 L-Data-REQ-10: The I2RS should support the query and 1310 "introspection" of the data model. The Introspections provides 1311 support for data verification, easier inclusion in legacy data, 1312 and easier merging with data streams. 1314 L-Data-REQ-11: After the I2rs Client-Agent have exchanged 1315 capabilities, a database model, and filters used to select 1316 elements of the model to subscribe to, the framework should 1317 support a standard way to register for all the data desired, using 1318 whatever capabilities were advertised by the node. Once 1319 registration is complete, the control channel can be closed. 1320 Ensuring subscriptions are correct, complete, and replicated or 1321 not, is up to the overall system and not the agent on the network 1322 node. 1324 L-Data-REQ-12: The I2RS interface should support user 1325 subscriptions to data with the following parameters: 1327 * push of data synchronously or asynchronously via registered 1328 subscriptions 1330 * pull data off in a one-shot pull or in multiple sequences 1332 * provide dynamic subscriptions that can be setup via IPFIX feed 1334 * support of subscriber and consumer I2RS Client-agent pairs 1336 * allow remapping of a node's databases 1338 L-Data-REQ-13: The I2RS interface must handle and report errors 1339 that occur with data subscription, stale data, repeated transport 1340 failures, and other (yet unknown) errors 1342 14. CDNI 1344 The requirements from the Large Data Collection Systems Use cases 1345 described in [I-D.shin-i2rs-usecases-cdni-request-routing] are: 1347 o CDNI-REQ-01: The I2RS interface should support two CDNI 1348 functionalities [I-D.ietf-cdni-framework]: 1350 * Request Routing Interface - Footprint and Capabilities 1351 Advertisement; the asynchronous advertisement of footprint and 1352 capabilities by a dCDN that allows a uCDN to decide whether to 1353 redirect particular user requests to that dCDN via the ALTO 1354 protocol; and 1356 * Request Routing Interface - Redirection; the synchronous 1357 operation of actually redirecting a user request via I2RS 1358 manipulation of the routing plane. 1360 o CDNI-REQ-02: The I2RS (Protocol and IM) should provide facilities 1361 to enable the query/response of information from an ALTO services 1362 in a node routing functions so that the upstream CDN provider can 1363 select a proper downstream CDN provider for a given end user 1364 request. 1366 o CDNI-REQ-03: I2RS (protocol and IM) should provide facilties to 1367 enable I2RS can help the upstream CDN provider to redirect a 1368 content request message to a downstream CDN provider for a given 1369 end user request as with the following features: 1371 * The uCDN relays this message between I2RS Clients and I2RS 1372 agents with content distribution metadata, and queries the dCDN 1373 whether user request message can be delivered. This query can 1374 have multiple dDCN that the user message can be delivered to. 1376 * the I2RS agent associated with the dCDN delivery requests 1377 indicating which dCDN (if any) the user message can be 1378 delivered to. 1380 * Allow dCDN to be managed to deliver content by having the 1381 messages to signal back to the uCDN the (destination (?)) iP 1382 address for the content, on the dCDN, and the pathway between 1383 the uCDN for surrogate deliver via the dCDN of user data. Part 1384 of this management is the passing of URL of the surrogate in 1385 dCDN (for HTTP Redirection to be transmitting) back from the 1386 dCDN to the uCDN so the uCDN can inform the end user. 1388 15. IANA Considerations 1390 This document makes no request of IANA. 1392 16. Security Considerations 1394 Routing information is very critical and sensitive information for 1395 the operators. I2RS should provide strong security mechanism to 1396 protect the routing information that it could not be accessed by the 1397 un-authorised users. It should also protect the security and 1398 integrity protection of the routing data. 1400 17. References 1402 17.1. Normative References 1404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1405 Requirement Levels", BCP 14, RFC 2119, March 1997. 1407 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1408 "Forwarding and Control Element Separation (ForCES) 1409 Framework", RFC 3746, April 2004. 1411 17.2. Informative References 1413 [I-D.amante-i2rs-topology-use-cases] 1414 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1415 "Topology API Use Cases", draft-amante-i2rs-topology-use- 1416 cases-01 (work in progress), October 2013. 1418 [I-D.bitar-i2rs-service-chaining] 1419 Bitar, N., Heron, G., Fang, L., ramki, r., Leymann, N., 1420 Shah, H., and W. Haddad, "Interface to the Routing System 1421 (I2RS) for Service Chaining: Use Cases and Requirements", 1422 draft-bitar-i2rs-service-chaining-01 (work in progress), 1423 February 2014. 1425 [I-D.chen-i2rs-mpls-ldp-usecases] 1426 Chen, X. and Z. Li, "Use Cases for an Interface to LDP 1427 Protocol", draft-chen-i2rs-mpls-ldp-usecases-00 (work in 1428 progress), October 2013. 1430 [I-D.chen-i2rs-ts-use-case] 1431 Chen, M. and S. Hares, "I2RS Traffic Steering Use Case", 1432 draft-chen-i2rs-ts-use-case-00 (work in progress), 1433 February 2014. 1435 [I-D.hares-i2rs-use-case-vn-vc] 1436 Hares, S. and M. Chen, "Use Cases for Virtual Connections 1437 on Demand (VCoD) and Virtual Network on Demand (VNoD) 1438 using Interface to Routing System", draft-hares-i2rs-use- 1439 case-vn-vc-02 (work in progress), February 2014. 1441 [I-D.huang-i2rs-mpls-te-usecases] 1442 Huang, T., Li, Z., and S. Hares, "Use Cases for an 1443 Interface to MPLS TE", draft-huang-i2rs-mpls-te- 1444 usecases-01 (work in progress), February 2014. 1446 [I-D.ietf-i2rs-architecture] 1447 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1448 Nadeau, "An Architecture for the Interface to the Routing 1449 System", draft-ietf-i2rs-architecture-04 (work in 1450 progress), June 2014. 1452 [I-D.ietf-i2rs-problem-statement] 1453 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1454 Routing System Problem Statement", draft-ietf-i2rs- 1455 problem-statement-04 (work in progress), June 2014. 1457 [I-D.ietf-i2rs-rib-info-model] 1458 Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing 1459 Information Base Info Model", draft-ietf-i2rs-rib-info- 1460 model-03 (work in progress), May 2014. 1462 [I-D.ietf-sfc-problem-statement] 1463 Quinn, P. and T. Nadeau, "Service Function Chaining 1464 Problem Statement", draft-ietf-sfc-problem-statement-07 1465 (work in progress), June 2014. 1467 [I-D.ji-i2rs-usecases-ccne-service] 1468 Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use 1469 Cases for Control of Forwarding Path by Central Control 1470 Network Element (CCNE)", draft-ji-i2rs-usecases-ccne- 1471 service-01 (work in progress), February 2014. 1473 [I-D.keyupate-i2rs-bgp-usecases] 1474 Patel, K., Fernando, R., Gredler, H., Amante, S., White, 1475 R., and S. Hares, "Use Cases for an Interface to BGP 1476 Protocol", draft-keyupate-i2rs-bgp-usecases-03 (work in 1477 progress), June 2014. 1479 [I-D.krishnan-i2rs-large-flow-use-case] 1480 ramki, r., Ghanwani, A., Kini, S., McDysan, D., and D. 1481 Lopez, "Large Flow Use Cases for I2RS PBR and QoS", draft- 1482 krishnan-i2rs-large-flow-use-case-04 (work in progress), 1483 April 2014. 1485 [I-D.lapukhov-bgp-routing-large-dc] 1486 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 1487 routing in large-scale data centers", draft-lapukhov-bgp- 1488 routing-large-dc-06 (work in progress), August 2013. 1490 [I-D.medved-i2rs-topology-requirements] 1491 Medved, J., Previdi, S., Gredler, H., Nadeau, T., and S. 1492 Amante, "Topology API Requirements", draft-medved-i2rs- 1493 topology-requirements-00 (work in progress), February 1494 2013. 1496 [I-D.shin-i2rs-usecases-cdni-request-routing] 1497 Shin, M. and S. Lee, "CDNI Request Routing with I2RS", 1498 draft-shin-i2rs-usecases-cdni-request-routing-00 (work in 1499 progress), July 2014. 1501 [I-D.swhyte-i2rs-data-collection-system] 1502 Whyte, S., Hines, M., and W. Kumari, "Bulk Network Data 1503 Collection System", draft-swhyte-i2rs-data-collection- 1504 system-00 (work in progress), October 2013. 1506 [I-D.white-i2rs-use-case] 1507 White, R., Hares, S., and A. Retana, "Protocol Independent 1508 Use Cases for an Interface to the Routing System", draft- 1509 white-i2rs-use-case-05 (work in progress), June 2014. 1511 [I-D.zhang-i2rs-mbb-usecases] 1512 Zhang, L., Li, Z., Liu, D., and S. Hares, "Use Cases of 1513 I2RS in Mobile Backhaul Network", draft-zhang-i2rs-mbb- 1514 usecases-01 (work in progress), February 2014. 1516 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1517 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1519 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1520 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 1521 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 1522 2008. 1524 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 1525 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 1527 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 1528 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 1529 Traffic Engineering", RFC 5623, September 2009. 1531 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1532 Optimization (ALTO) Problem Statement", RFC 5693, October 1533 2009. 1535 Author's Address 1537 Susan Hares 1538 Huawei 1540 Email: shares@ndzh.com