idnits 2.17.1 draft-ietf-i2rs-usecase-reqs-summary-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (March 15, 2016) is 2936 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: 'I-D.ietf-cdni-framework' is mentioned on line 1393, but not defined == Unused Reference: 'RFC2119' is defined on line 1449, but no explicit reference was found in the text == Unused Reference: 'RFC3746' is defined on line 1454, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-problem-statement' is defined on line 1500, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1505, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-problem-statement' is defined on line 1510, but no explicit reference was found in the text == Unused Reference: 'I-D.lapukhov-bgp-routing-large-dc' is defined on line 1533, but no explicit reference was found in the text == Unused Reference: 'RFC5212' is defined on line 1569, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-13 == Outdated reference: A later version (-11) exists of draft-ietf-i2rs-problem-statement-10 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-08 == Outdated reference: A later version (-07) exists of draft-lapukhov-bgp-routing-large-dc-06 Summary: 0 errors (**), 0 flaws (~~), 14 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 M. Chen 5 Expires: September 16, 2016 Huawei Technologies 6 March 15, 2016 8 Summary of I2RS Use Case Requirements 9 draft-ietf-i2rs-usecase-reqs-summary-02 11 Abstract 13 The I2RS Working Group (WG) has described a set of use cases that the 14 I2RS systems could fulfil. This document summarizes these use cases. 15 It is designed to provide requirements that will aid the design of 16 the I2RS architecture, Information Models, Data Models, Security, and 17 protocols. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 16, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Protocol Independent Use Case Requirements . . . . . . . . . 4 55 3. BGP Use Case Requirements . . . . . . . . . . . . . . . . . . 6 56 4. IGP Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 57 5. CCNE Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10 58 6. Topology Related Use Cases . . . . . . . . . . . . . . . . . 11 59 6.1. Virtual Connection Use Case Requirements . . . . . . . . 11 60 6.2. Virtual Network Use Case Requirements . . . . . . . . . . 11 61 6.3. Topology Use Case . . . . . . . . . . . . . . . . . . . . 13 62 6.4. Virtual Topology Data Model . . . . . . . . . . . . . . . 17 63 6.5. Virtual Topology IP Data Model . . . . . . . . . . . . . 19 64 6.6. Virtual Topology Network Element . . . . . . . . . . . . 19 65 7. Requirements from SFC Use Cases . . . . . . . . . . . . . . . 20 66 8. Requirements from Traffic Steering Use Cases . . . . . . . . 22 67 9. Requirements from MPLS TE Networks Use Cases . . . . . . . . 22 68 10. Requirements from MPLS LDP Networks Use Cases . . . . . . . . 24 69 11. Requirements from Mobile Backhaul Ues Cases . . . . . . . . . 25 70 12. Requirements from Large Data Flows are . . . . . . . . . . . 27 71 13. Large Data Collection Systems . . . . . . . . . . . . . . . . 28 72 14. CDNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 73 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 74 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 75 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 76 17.1. Normative References . . . . . . . . . . . . . . . . . . 31 77 17.2. Informative References . . . . . . . . . . . . . . . . . 31 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 80 1. Introduction 82 The Architecture for the Interface to the Routing System 83 [I-D.ietf-i2rs-architecture] allows for a mechanism where the 84 distributed control plane can be augmented by an outside control 85 plane through an open, accessible interface. This document 86 summarizes the use case requirements for theI2RS client-I2RS Agent 87 exchange found in the following documents: 89 o Protocol Independent described in [I-D.white-i2rs-use-case] 91 o BGP described in [I-D.keyupate-i2rs-bgp-usecases] 93 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 141 o VT-TMD - Virtual Topology: Topology Data Model 143 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 Each use case is also augmented with a notation signifying whether it 162 is in or out of scope with regard to the current I2RS charter: 164 o IC: In charter 166 o OC: Out of charter 168 o NA: not applicable to I2RS protocol, agent, client or models. 169 Usually related to specific client-side app requirements. 171 o ??: indicates this item needs additional classification aid from 172 the WG. 174 In some cases a specific draft may be out of charter, but 175 (sub)components of it's requirement set may be in charter. In 176 charter. As such, (IC|OC|NA) designations may appear at the draft 177 level, at the requirement level, or at the sub requirement level. In 178 instances where designations do not appear at more specific level, 179 the designation at the parent level should be considered to be 180 inherited. 182 2. Protocol Independent Use Case Requirements 184 This is a summary of the I2RS requirements found in the Protocol 185 Independent Use Cases described in: [I-D.white-i2rs-use-case] (IC): 187 o PI-REQ01 (IC): The ability to monitor the available routes 188 installed in the RIB of each forwarding device, including near 189 real time notification of route installation and removal. This 190 information must include the destination prefix (NLRI), a table 191 identifier (if the forwarding device has multiple forwarding 192 instances), the metric of the installed route, and an identifier 193 indicating the installing process. 195 o PI-REQ02 (IC): The ability to install source and destination based 196 routes in the local RIB of each forwarding device. This must 197 include the ability to supply the destination prefix (NLRI), the 198 source prefix (NLRI), a table identifier (if the forwarding device 199 has multiple forwarding instances), a route preference, a route 200 metric, a next hop, an outbound interface, and a route process 201 identifier. 203 o PI-REQ03 (IC): The ability to install a route to a null 204 destination, effectively filtering traffic to this destination. 206 o PI-REQ04(??): The ability to interact with various policies 207 configured on the forwarding devices, in order to inform the 208 policies implemented by the dynamic routing processes. This 209 interaction should be through existing configuration mechanisms, 210 such as NETCONF, and should be recorded in the configuration of 211 the local device so operators are aware of the full policy 212 implemented in the network from the running configuration. 214 o PI-REQ05 (OC): The ability to interact with traffic flow and other 215 network traffic level measurement protocols and systems, in order 216 to determine path performance, top talkers, and other information 217 required to make an informed path decision based on locally 218 configured policy. 220 o PI-REQ06 (IC): The ability to install destination based routes in 221 the local RIB of each forwarding device. This must include the 222 ability to supply the destination prefix (NLRI), a table 223 identifier (if the forwarding device has multiple forwarding 224 instances), a route preference, a route metric, a next hop, an 225 outbound interface, and a route process identifier. 227 o PI-REQ07 (IC): The ability to read the local RIB of each 228 forwarding device, including the destination prefix (NLRI), a 229 table identifier (if the forwarding device has multiple forwarding 230 instances), the metric of each installed route, a route 231 preference, and an identifier indicating the installing process. 233 o PI-REQ08 (IC): The ability to read the tables of other local 234 protocol processes running on the device. This reading action 235 should be supported through an import/export interface which can 236 present the information in a consistent manner across all protocol 237 implementations, rather than using a protocol specific model for 238 each type of available process. 240 o PI-REQ09 (OC for some protocols): The ability to inject 241 information directly into the local tables of other protocol 242 processes running on the forwarding device. This injection should 243 be supported through an import/export interface which can inject 244 routing information in a consistent manner across all protocol 245 implementations, rather than using a protocol specific model for 246 each type of available process. 248 o PI-REQ10 (OC): The ability to interact with policies and 249 configurations on the forwarding devices using time based 250 processing, either through timed auto-rollback or some other 251 mechanism. This interaction should be through existing 252 configuration mechanisms, such as NETCONF, and should be recorded 253 in the configuration of the local device so operators are aware of 254 the full policy implemented in the network from the running 255 configuration. 257 o PI-REQ-11 (IC) The ability to update the Local RIB with varying 258 levels of checks on the route. These checks can be simply minimal 259 reception checks (TLVs align corrrectly), all non-referential 260 checks (do not do leafref, MUST, instance identifiers), do 261 referential checks. 263 3. BGP Use Case Requirements 265 This is a summary of the requirements listed in 266 [I-D.keyupate-i2rs-bgp-usecases] are (IC): 268 o BGP-REQ01 (IC): I2RS client/agent exchange SHOULD support the 269 read, write and quick notification of status of the BGP peer 270 operational state on each router within a given Autonomous System 271 (AS). This operational status includes the quick notification of 272 protocol events that proceed a destructive tear-down of BGP 273 session 275 o BGP-REQ02 (IC): I2RS client SHOULD be able to push BGP routes with 276 custom cost communities to specific I2RS agents on BGP routers for 277 insertion in specific BGP Peer(s) to aid Traffic engineering of 278 data paths. These routes SHOULD be tracked by the I2RS Agent as 279 specific BGP routes with customer cost communities. These routes 280 (will/will not) installed via the RIB-Info. 282 o BGP-REQ03 (IC): I2RS client SHOULD be able to track via read/ 283 notifications all Traffic engineering changes applied via I2RS 284 agents to BGP route processes in all routers in a network. 286 o BGP-REQ04 (IC): I2RS Agents SHOULD support identification of 287 routers as BGP ASBRs, PE routers, and IBGP routers. 289 o BGP-REQ05 (IC): I2RS client-agent SHOULD support writing traffic 290 flow specifications to I2RS Agents that will install them in 291 associated BGP ASBRs and the PE routers. 293 o BGP-REQ06 (IC): I2RS Client SHOULD be able to track flow 294 specifications installed within a IBGP Cloud within an AS via 295 reads of BGP Flow Specification information in I2RS Agent, or via 296 notifications from I2RS agent 298 o BGP-REQ07 (IC): I2RS client-agent exchange SHOULD support the I2RS 299 client being able to prioritize and control BGP's announcement of 300 flow specifications after status information reading BGP ASBR and 301 PE router's capacity. BGP ASBRs and PE routers functions within a 302 router MAY forward traffic flow specifications received from EBGP 303 speakers to I2RS agents, so the I2RS Agent SHOULD be able to send 304 these flow specifications from EBGP sources to a client in 305 response to a read or notification. 307 o BGP-REQ08 (IC): I2RS Client SHOULD be able to read BGP route 308 filter information from I2RS Agents associated with legacy BGP 309 routers, and write filter information via the I2RS agent to be 310 installed in BGP RR. The I2RS Agent SHOULD be able to install 311 these routes in the BGP RR, and engage a BGP protocol action to 312 push these routers to ASBR and PE routers. 314 o BGP-REQ09 (IC): I2RS client(s) SHOULD be able to request the I2RS 315 agent to read BGP routes with all BGP parameters that influence 316 BGP best path decision, and write appropriate changes to the BGP 317 Routes to BGP and to the RIB-Info in order to manipulate BGP 318 routes 320 o BGP-REQ10 (IC): I2RS client SHOULD be able instruct the I2RS 321 agent(s) to notify the I2RS client when the BGP processes on an 322 associated routing system observe a route change to a specific set 323 of IP Prefixes and associated prefixes. Route changes include: 1) 324 prefixes being announced or withdrawn, 2) prefixes being 325 suppressed due to flap damping, or 3) prefixes using an alternate 326 best-path for a given IP Prefix. The I2RS agent should be able to 327 notify the client via publish or subscribe mechanism. 329 o BGP-REQ11 (IC): I2RS client SHOULD be able to read BGP route 330 information from BGP routers on routes in received but rejected 331 from ADJ-RIB-IN due to policy, on routes installed in ADJ-RIB-IN, 332 but not selected as best path, and on route not sent to IBGP peers 333 (due to non-selection). 335 o BGP-REQ12 (IC): I2RS client SHOULD be able to request the I2RS 336 agent to read installed BGP Policies. 338 o BGP-REQ13 (IC): I2RS client SHOULD be able to instruct the I2RS 339 Agent to write BGP Policies into the running BGP protocols and 340 into the BGP configurations. 342 o BGP-REQ14 (IC): I2RS client-agent SHOULD be able to read BGP 343 statistics associated with Peer, and to receive notifications when 344 certain statistics have exceeded limits. An example of one of 345 these protocol statistics is the max-prefix limit. 347 o BGP-REQ15 (IC): The I2RS client via the I2RS agent MUST have the 348 ability to read the loc-RIB-In BGP table that gets all the routes 349 that the CE has provided to a PE router. 351 o BGP-REQ16 (IC): The I2RS client via the I2RS agent MUST have the 352 ability to install destination based routes in the local RIB of 353 the PE devices. This must include the ability to supply the 354 destination prefix (NLRI), a table identifier, a route preference, 355 a route metric, a next-hop tunnel through which traffic would be 356 carried 358 o BGP-REQ17 (IC): The I2RS client via the I2RS agent SHOULD have the 359 the ability to read the loc-RIB-in BGP table to discover 360 overlapping routes, and determine which may be safely marked for 361 removal. 363 o BGP-REQ18 (IC): The I2RS client via the I2RS Agent SHOULD have the 364 ability to modify filtering rules and initiate a re-computation of 365 the local BGP table through those policies to cause specific 366 routes to be marked for removal at the outbound eBGP edge. 368 4. IGP Use Cases 370 This is a summary of the requirements listed in (ietf-draft-wu-ir2s- 371 igp-usecases-00.txt) (OC): 373 o IGP-REQ-01 (OC): I2RS Client/Agent SHOULD Be able to read/write 374 the the unique IGP identification for router within an AS (router- 375 id, system-id, or others). I2RS agents may notify the I2RS client 376 of the detection of another router with the same unique ID. 378 o IGP-REQ-02 (OC): I2RS Client SHOULD BE able to aid in IGP table 379 reduction by actively monitoring IGP tables and by allowing 380 changes to the IGP configuration in order to partition the IGPS 381 and place ABRs and ASBRs. The I2RS Client/Agent exchange must 382 allow for a rapid cycle of querying of IGP topology information 383 and downloading of a new protocol configuration or updating of IGP 384 nexthops in RIBs and FIBs to rapidly switch to new temporary IGP 385 topologies. These alternate topologies may be calculated by a 386 application attached to the i2rs client and updated to the i2rs 387 agent, or determined at the i2rs agent. 389 o IGP-REQ-03 (OC): I2RS protocol and models should support Loop-Free 390 Alternative (LFAs) [RFC5286] deployments in in pure IP and MPLS/ 391 LDP networks to provide single-point-failure protection for 392 unicast traffic. This includes the configuration, monitoring of 393 LFA changes, and letting off-line pre-computed paths for LFA 394 backup of all links and prefixes in the network and calculating 395 the protection coverage and recognizing optimization to be 396 downloaded to appropriate devices via the I2RS interface (Client- 397 Agent). Again, it is important to have deployment of changes 398 followed by real-time feedback. 400 o IGP-REQ-04 (OC): The I2RS programmatic interface SHOULD allow the 401 balancing of both ECMP traffic flows and end-to-end traffic flows 402 in the IGP. The I2RS SHOULD support monitoring of the dynamic 403 traffic flow in the network, and the query of the maximum capacity 404 of the network. This include the I2RS client's transmission to 405 the I2RS agent of updated configuration after an off-line 406 optimization to either spread traffic (across ECMP pathways) or 407 aggregation of traffic onto a single path so the rest of the 408 devices may power off saving power (and money. 410 o IGP-REQ-05 (OC): The I2RS interface (protocol and data models) 411 SHOULD use the subscription mechanism to filter the topology 412 changes to interested events and use the publish mechanism to 413 control the pace these events are notified. This filtering should 414 protect the I2RS Client or even applications who depend on 415 topology data from being drowned by massive original events or 416 duplicate events from different sources 418 o IGP-REQ-06 (OC): Since IGP protocol is essential to the whole 419 network, the I2RS Clients SHOULD monitor about the protocol's 420 running status before forwarding is impacted. Performance data 421 can be collected through collecting static configuration and 422 observing dynamic status. Static data includes the number of 423 instances, interfaces, nodes in the network and etc. Dynamic data 424 includes adjacency status, the number of entries in link-state 425 database and in the routing table, the calculation status, the 426 overload status, the graceful switch-over status, and others 428 o IGP-REQ-07 (OC): The I2RS interface (protocol and IMs) should 429 support a mechanism where the I2RS Clients can subscribe to the 430 I2RS Agent's notification of critical node IGP events. For 431 example, link-state database or routing table is under the status 432 of overflow or the overflow status is released, the calculation 433 continues for a long time, the system is under graceful reboot. 435 o IGP-REQ-08 (OC): The I2RS interface (protocol and IMs) should 436 support the reporting of IGP statistic such as dropped packet 437 statistics. These statistics will aid detection of network 438 failures or secruity attacks. 440 5. CCNE Use Cases 442 The use cases in I2RS Use Cases for Control of the Forwarding Path by 443 a Central Control Network Element (CCNE) 444 [I-D.ji-i2rs-usecases-ccne-service] indicate the following 445 requirements for I2RS (OC): 447 o CCNE-REQ-01 (IC): I2RS interface should support I2RS client 448 running on a CCNE to be able to pull information from both the BGP 449 RR and the PCE. This information can include: BGP topology 450 information, BGP routes, BGP statistics, BGP Peer topologies, PCE 451 topology information, and PCE state information. The I2RS 452 Client's request for reading of the RR and PCE topology 453 information needs to have timely and rapid response from the I2RS 454 Agent. 456 o CCNE-REQ-02 (IC for some constraints): I2RS client should be able 457 to set resource constraints at the I2RS Agent, and receive status 458 information on the setting of resource constraints. 460 o CCNE-REQ-03 (IC for some constraints): I2RS interface should be 461 able to set service goal value to CCNE. 463 o CCNE-REQ-04 (OC): I2RS client should be able support information 464 models that allow re-optimization traffic model at at CCNE . 466 o CCNE-REQ-05 (IC): I2RS client should be able to receive 467 notification at the CCNE, and be able to send status to the I2RS 468 agent. 470 o CCNE-REQ-06 (NA): I2RS client should work in parallel with 471 traditional network management or OAM protocols sent to the 472 general NE. 474 o CCNE-REQ-07 (NA): I2RS clients should be able to to be light 475 weight enough to be able to support running on a variety of 476 devices (routers, centralized servers, or devices doing both). 478 6. Topology Related Use Cases 480 This section describes Topology or Virtual Topology related 481 requirements the I2RS interface (protocol and information model (IM) 482 included in the following types of use cases: 484 o Virtual Connections on Demand: VCoD-REQ 486 o Virtual Networks on Demand: VNoD-REQ 488 o Virtual Topology Information Topo-REQ 490 o Virtual Topology Data Model: VT-TDM-REQ 492 o Virtual Topology IP Data Model: VT-TDMIP-REQ 494 o Virtual Topology Network Element: VT-NE-REQ (TMF-GEN-1) 496 6.1. Virtual Connection Use Case Requirements 498 o VCoD-REQ01 (OC): I2RS Agents SHOULD provide the ability to read 499 the virtual network topology database for the technology 500 supported. For optical, these are the optical connections and 501 what node they connect to, and the topologies created. For MPLS, 502 this is virtual circuit available, what nodes they connect to, and 503 the network topologies created. For IP technologies, this could 504 include the GRE tunnels, what interface it connects to, and the 505 topologies created. For Ethernet circuits this should involve 506 circuit type (e.g, point-to-point (p2p) or point-to-multipoint 507 (p2mp)) and what nodes it can reach, and the topologies created. 509 o VCoD-REQ02 (OC): I2RS Agent SHOULD provide the ability to 510 influence the configuration of a virtual circuit in a node. 512 o VCoD-REQ03 (OC): I2RS Agent SHOULD provide monitor and provide 513 statistics on the virtual connection to the I2RS client via a Read 514 request or status Notification. The I2RS client can then 515 determine if the connection falls below a quality level the 516 application has requested. If the I2RS client does determine the 517 circuit is below the required quality, it could create another 518 circuit. The I2RS may choose to create the second virtual 519 circuit, transfer flows, and then break the first circuit. 521 6.2. Virtual Network Use Case Requirements 523 The requirements for the Virtual Networks on Demand (VCoD) are: 525 o VT-VN-REQ01 (IC): I2RS Agents SHOULD provide the ability to read 526 the virtual network topology database for the technology supported 527 to determine nodes and connections. For optical, these are the 528 optical connections and what node they connect to, and the 529 topologies created. For MPLS, this is virtual circuit available, 530 what nodes they connect to, and the network topologies created. 531 For IP technologies, this could include the GRE tunnels, what 532 interface it connects to, and the topologies created. For 533 Ethernet circuits this should involve circuit type (e.g, point-to- 534 point (p2p) or point-to-multipoint (p2mp)) and what nodes it can 535 reach, and the topologies created. 537 o VNoD-REQ02 (IC): I2RS Agent SHOULD provide the ability to 538 influence the configuration of a virtual circuit in a node. 540 o VNoD-REQ03 (IC): I2RS Agent SHOULD provide monitor and provide 541 statistics on the virtual connection to the I2RS client via a Read 542 request or status Notification. The I2RS client can then 543 determine if the connection falls below a quality level the 544 application has requested. If the I2RS client does determine the 545 circuit is below the required quality, it could create another 546 circuit. The I2RS may choose to create the second virtual 547 circuit, transfer flows, and then break the first circuit. 549 o VNoD-REQ04 (IC): I2RS Agent SHOULD provide the ability to 550 influence the configuration of a virtual network in a node. 552 o VNoD-REQ05 (OC): I2RS Agent SHOULD provide the ability to report 553 statistics on the network nodes and end-to-end traffic flows via 554 read of status data or via notifications of status. 556 o VNoD-REQ06 (IC): The I2RS protocol and RIB Informational Model 557 (IM) must support logical tunnels of type MPLS as well as IP, GRE, 558 VxLAN and GRE. Large Carrier networks utilize MPLS in a variety 559 of forms (LDP, static MPLS TE, or dynamic TE LSPS created by RSVP- 560 TE or CR-LDP). 562 o VNoD-REQ07 (IC): I2RS SHOULD support Informational Models and 563 features to allow MPLS technologies to create Hub-spoke topology 564 and service routing in networks in Carriers, Enterprise, and Data 565 Centers. 567 o VNoD-REQ08 (IC): I2RS protocols, Information Models, and Data 568 Models must be able to support Carriers using these MPLS 569 technologies to support networks for Mobile BackHaul, on-demand 570 MPLS overlays, and on-demand video conferencing networkings. 572 6.3. Topology Use Case 574 The requirements in [I-D.amante-i2rs-topology-use-cases] topology use 575 cases focus around the architecture of topology manager, 576 orchestration manager, and policy in the figure below (IC): 578 +---------------+ 579 +----------------+ | 580 | Applications |-+ 581 +----------------+ 582 ^ Websockets, ReST, XMPP... 583 +------------------------+-------------------------+ 584 | | | 585 +------------+ +------------------------+ +-------------+ 586 | Policy |<----| Topology Manager |---->|Orchestration| 587 | Manager | | +--------------------+ | | Manager | 588 +------------+ | |Topology Information| | +-------------+ 589 | | Model | | 590 | +--------------------+ | 591 +------------------------+ 592 ^ ^ ^ 593 Websockets, ReST, XMPP # | * Websockets, ReST, XMPP 594 ####################### | ************************ 595 # | * 596 +------------+ | +------------+ 597 | Statistics | | | Inventory | 598 | Collection | | | Collection | 599 +------------+ | +------------+ 600 ^ | I2RS, NETCONF, SNMP, ^ 601 | | TL1 ... | 602 +------------------------+------------------------+ 603 | | | 604 +---------------+ +---------------+ +---------------+ 605 |Network Element| |Network Element| |Network Element| 606 | +-----------+ | | +-----------+ | | +-----------+ | 607 | |Information| |<-LLDP->| |Information| |<-LMP-->| |Information| | 608 | | Model | | | | Model | | | | Model | | 609 | +-----------+ | | +-----------+ | | +-----------+ | 610 +---------------+ +---------------+ +---------------+ 612 o Topo-REQ-01 (IC): The Topology Manager Should be able to collect 613 topological information via the I2RS Client-Exchange exchange from 614 a variety of sources in a normalized topological model. These 615 sources can be: 617 * Live Layer IGP IGPs with information about the active topology 618 such as the LSDB database or IGP updates, 620 * The I2RS must enable the inventory system information to query 621 for information about network components which are not not 622 visible to active L3. These systems can be active or simply 623 invisible to the L3. Examples of this are L2 Ethernet switches 624 or ROADMS. 626 * Statistic Collection systems that provide traffic information, 627 such as traffic demands or link utilizations. 629 (from section 3.2) 631 o Topo-REQ-02 (OC): Topology information is provided from Clients to 632 high-layer applications via a northbound interface (such as ReST, 633 Websockts, or XMPP. 635 o Topo-REQ-03 (IC): Topology Manager should be able to collect and 636 keep current topology information for multiple layers of the 637 network: Transport, Ethernet and IP/MPLS, as well as information 638 for multiple Layer 3 IGP areas and multiple Autonomous Systems 639 (ASes). This information must contain cross-layer unerlying 640 Shared Risk Link Groups (SRLG) within transport or Ethernet 641 layers. (from section 3.2) 643 o Topo-REQ-04 (OC): Topology manager be able to use I2RS Client- 644 Agent protocol to to collect dynamic inventory information from 645 network elements. An example of these protocols are the Link 646 Layer discovery protocols (LLDP, LMP, etc.) which automatically 647 identify remote nodes and ports. (from section 3.2) 649 o Topo-REQ-05 (IC):I2RS Should enable the Policy manager to query 650 and store the following types of policies: 652 * Policies that contain Logical identifier Numbering in order to 653 correlate IP Prefixes to 655 + link based on link type (P-P, P-PE, or PE-CE), 657 + IGP Area 659 + L2 VLAN assignments 661 * Routing Configuration policies that correlate: 663 + OSPF area/ISIS Net-ID to Node (type) 665 + BGP node related policies (aggregation routes at node, max- 666 prefix (per node), or AFI/SAFI per node 668 + Security policies - with ACLs or rate-limits 670 + Network Component access policies (for management 672 (from section 3.3) 674 o Topo-REQ-06 (OC): I2RS should enable a orchestration manager 675 attached to an I2RS client to communicate with I2RS agents into 676 order to stitch together End-to-end services for network bandwidth 677 optimization, load balancing, and Class-of-Service with point 678 services (Firewall or NAT) within the end-to-end service). The 679 orchestration manager should also be able to immediately schedule 680 any of these resources via the I2RS-Client I2RS agent exchange. 681 (from section 3.4) 683 o Topp-REQ-07 (OC): The I2RS exchange should enable a statistics 684 collector to collect statistics from the routing function of the 685 network nodes and archive and aggregate the statistics into a 686 statistics warehouse. Statistics must be given and stored in an 687 normalized form. Metadata must be stored with the statistics. 688 (from section 4.1.1.2) (Editor: there is some suggestion of 689 periodic reports) 691 o Topo-REQ-08 (IC): I2RS Client-I2RS agent exchange must be provide 692 enough interoperability that the Topology manager, Policy manager, 693 and inventory systems can be available from different vendors 695 o Topo-REQ-09 (IC): TE tunnels must be able to be created by the 696 exchange between the I2RS client and the I2RS agent. (from section 697 4.1.1) 699 o Topo-Req-10 (NA): I2RS must provide a common and up-to-date 700 normalized view of the topologies that that support security 701 auditing, and IP/MPLS Provisioning (L2/L3) which includes: 703 * Identifying Service PE's in all markets/cities where the 704 customer has identified they want service, 706 * Identifying one or more existing Servies PE's in each city with 707 connectivity to the access network(s) ( e.g.: SONET/TDM) used 708 to deliver the PE-CE tail circuits to the Service's PE), 710 * Obtain via query/notification the available capacity on 711 Services PE in both the PE-CE access interface and its uplinks 712 to terminate the tail circuit 714 * Providing the context in I2RS for an iterative query mechanism 715 needed by I2RS client attached to the the Topology to narrow 716 down the scope of resources to the set of Services PEs with the 717 appropriate uplink bandwidth and access circuit capability plus 718 capacity to realize the requested VPN service. 720 (from section 4.1.2) 722 o Topo-REQ-11 (NA): The VPN application attached to the I2RS client 723 should be able to hand the I2RS Client a candidate list of Service 724 PE's and associated access circuits to set up a Customer's VPN 725 service into the network. (from section 4.1.3) [Editor's note 726 This request shares requirements with VCoD-REQ-01.] 728 o Topo-REQ-12 (NA): The Topology Manager associated with the I2RS 729 client must be able to use the normalized view of the network to 730 set up additional queries (or notification publications) to 731 provide an accurate and comprehensive picture in order a) diagnose 732 faults/failures, and b) augment the network with additional 733 services, and c) provide network topology maps for different 734 purposes. (from section 4.1.3) 736 o Topo-REQ-13 (IC):The I2RS client-agent exchange and informational 737 models should support a Virtual Network Topology (VNT) comprise of 738 one or more LSPS and lower layer resources. The VNT of MPLS must 739 be able to link lower layer resources with the higher layer, and 740 present a normalize form the the PCE as defined [RFC5623]. 742 o Topo-REQ-14 (OC): The I2RS client-agent protocol and models should 743 support the use of a PCE to compute MPLS-TE paths within an 744 "domain" (IGP area), or across multiple "domains" (multi-area AS, 745 multiple ASes") as specified in [RFC4655]. This means the PCE 746 Informational model should support: 748 * enhanced computation in the single IGP domain 750 * cross-AS path computation based on the multiple entrance of 751 exit points from an AS, 753 * linking multiple PEs in multiple domains together, and 755 * synchronization of TED associated with the PCE to the topology 756 manager (via I2RS client/messages), and 758 * sending read/writes to the head-end-nodes 760 (section 4.3) 762 o Topo-REQ-15 (OC): the I2RS protocol and Information models should 763 support the ALTO ([RFC5693]) generation of abstract network 764 topology models and the APIs it support over web-service API. The 765 ALTO abstract network topology comes in two forms: Network Map 766 (based prefix-to PID mapping), and Cost map. The ALTO map is 767 automatically generated from BGP and IGP data which the ALTO 768 server queries from the network and makes available to 769 applications via web-service API. (from section 4.4) 771 6.4. Virtual Topology Data Model 773 The [I-D.medved-i2rs-topology-requirements] specifies the following 774 Topology Data Model requirements (IC): 776 VT-TDM-REQ1 (IC): The topology data model MAY be able to describe 777 topology and characteristics of the following layers: 779 * Optical DWDM (optional) (OC), 781 * Optical OTN (optional) (OC), 783 * L2 (Aggregated links, L2 topologies) (IC), 785 * IP/MPLS (IC), 787 * VPNs (IC), and 789 * Services (such as cloud services, or CDNs). 791 VT-TDM-REQ2 (IC): The topology data model MUST support multiple 792 Autonomous System deployments. 794 VT-TDM-REQ3 (IC): The I2RS topology data model must support 795 include topology information from multiple Administrative Domains 796 or multiple elements into a single common format. 798 VT-TDM-REQ4 (IC): The I2RS topology data model MUST be able to 799 convey enough information so that an I2RS client can correlate 800 topologies in different layers and multiple Autonomous Systems. 802 VT-TDM-REQ5 (NA): The topology data model MUST support multi-layer 803 group of elements as a means of coalescing different SFF Nodes and 804 links into a network layers from various layers. For example, 805 links with IPv4 addresses might represent Layer 3 of the network 806 topology while links with Ethernet MAC addresses might represent 807 Layer 2. 809 VT-TDM-REQ6 (IC): The topology model should allow association 810 between components of different layers. For example, Layer 2 port 811 may have several IPv4/IPv6 interfaces. The Layer-2 port and the 812 IPv4/IPv6 interfaces would have an association. 814 VT-TDM-REQ7 (NA): The topology model MUST represent both inactive 815 and active topologies in the topology Data base. Inactive 816 topologies may include new line cards, ports in down state, etc. 818 VT-TMF-DM-REQ8 (NA): The topology data model MUST be hierarchical 819 and MUST support summarization of sub-topologies. Topology 820 summarization and creation of abstract topologies can be provided 821 by either by the application associated with the I2RS client, or 822 by the I2RS Agent prior to transmission to the I2RS client. 824 VT-TDM-REQ9 (IC): The topology data model MUST be able to describe 825 abstract topologies. Abstract topologies can contain real and 826 abstract nodes and real and abstract links. An abstract topology 827 MAY be used by a provider to describe characteristics of a transit 828 network (bandwidth, delay, protection, etc.) 830 VT-TDM-REQ10 (OC): The topology data model MUST support dynamic 831 data, such as link and node utilizations (perhaps as optional 832 attributes). 834 VT-TDM-REQ11a (??): The topology data model MUST allow I2RS 835 client-agent to be able to identify and query for the path between 836 two nodes. 838 VT-TDM-REQ11b (OC): The topology data model should support the 839 I2RS Client requesting the I2RS Agent to trace the path at all 840 network layers that participate in the delivery of packets between 841 two nodes. This trace MAY involve either an I2RS Agent 842 information trace or the I2RS Agent requesting the routing 843 function trace the path at multiple levels (L3/L2.5/L2/L1) 845 VT-TDM-REQ12 (IC): The topology data model MUST support multiple 846 BGP Autonomous Systems and multiple IGP areas. Support for 847 multiple administrative domains is for further study. 849 VT-TDM-REQ13 (IC): The topology data model MUST be human-friendly, 850 i.e. not SNMP MIBs, but something much more analogous to YANG 851 models. 853 VT-TDM-REQ14 (IC): The data model SHOULD support topology 854 abstraction, allowing clients that consume topology information in 855 a constrained manner. For example, a client wishing to view only 856 interfaces and nodes present in a sub-graph of the Layer 3 857 topology should be able to specify an interest in this subset of 858 information rather than having to read out and parse through the 859 entire set of links and nodes. 861 6.5. Virtual Topology IP Data Model 863 The [I-D.medved-i2rs-topology-requirements] specifies the following 864 requirements for the Virtual Topology IP Data Model's IP/MPLS links 865 and topologies (IC): 867 o VT-TDM-IP-REQ1 (IC): The I2RS topology data model for the IP/MPLS 868 layer MUST support both link topology and prefixes, 870 o VT-TDM-IP-REQ2 (IC): The I2RS agent may import topology 871 information from the routing processes, IGP process, BGP-LS 872 information, or management processes. 874 o TM-DM-IP-REQ3 (IC): The I2RS SFC Data model must support links 875 that are IP/MPLS with the following attributes: 877 * local and Remote anchor node IDs (Router ID, AS#, Area ID, MT 878 topology), 880 * metrics, 882 * admin group, 884 * max bandwidth links 886 * unreserved/utilized bandwidth 888 * link-protection type 890 * MPLS protocol mask 892 * link prefix 894 * link characteristics (BW, Delay, error rate) 896 * Link Description, and 898 * Link-specific timers (Hello and Holddown). 900 6.6. Virtual Topology Network Element 902 The [I-D.medved-i2rs-topology-requirements] specifies the following 903 requirements (IC): 905 o VT-NE-01 (IC): Each network element should contain an inventory 906 data base which should be a definitive source of information with 907 respect to the physical HW and Logical, logically significant 908 identifiers (E.g. VLANs). The I2RS client should be able to 909 import data from this DB into the I2RS Node IM or SFC IM. 911 o VT-NE-02 (IC): The inventory DB of the network element should be 912 augmented with the physical properties associated with the ports/ 913 interfaces that are directly connected to the device (BW, media 914 type). The I2RS client should be able to import data from this 915 augmented DB into the I2RS Node IM or SFC IM. 917 o NE-3 (NA): The I2RS client may write information into the NE 918 inventory data base via the Network-element Data Model that the 919 network element may not be able to learn on its own. This 920 information may include the physical location (address), rack/bay 921 information. 923 7. Requirements from SFC Use Cases 925 The SFC use case document in [I-D.bitar-i2rs-service-chaining] 926 suggests that the following requirements (OC): 928 SFC-Use-REQ01 (IC):Address 930 has the following address requirements: 932 * IP address 934 * service-node tuple (service node IP address, Host system 935 address) 937 * host-node tuple (hosting system IP-address, system internal 938 identifier) 940 SFC-Use-REQ02 (IC):Supported Service Types 942 SHOULD include: NAT, IP Firewall, Load balancer, DPI, and others 944 SFC-Use-REQ03 (IC):Virtual contexts 946 SHOULD include: 948 * Maximum Number of virtual contexts supported 950 * Current number of virtual contexts in use 952 * Number of virtual contexts available 953 * Supported Context (VRF) 955 SFC-Use-REQ04 (IC): Customers currently on node 957 SFC-Use-REQ05 (IC): Customer Support Table (per customer ID) 959 * Customer-id 961 * List of supported Virtual Contexts 963 SFC-Use-REQ06 (OC): Service Resource table 965 which includes: 967 * index: Comprised of service node, virtual context, service type 969 * service bandwidth capacity 971 * supported packet rate (packets/second) 973 * supported bandwidth (kps) 975 * IP Forwarding support: specified as routing-instance(s), RIBs, 976 Address-families supported 978 * Maximum RIB-size (WG Note: problematic) 980 * Maximum Forward Data Base size (WG Note: problematic) 982 * Maximum Number of 64 bit statistics counters for policy 983 accounting 985 * Maximum number of supported flows for services (WG Note: 986 problematic) 988 SFC-Use-REQ07 (IC): Virtual Network Topology (VNT) 990 which includes: 992 * number of access points to which service topology applies 994 * topology of access points 996 8. Requirements from Traffic Steering Use Cases 998 The requirements from the Traffic Steering use case described in 999 [I-D.chen-i2rs-ts-use-case] are (OC): 1001 o TS-REQ01 (IC): The I2RS Client-Agent must be able to collect the 1002 topology (especially the exit links) and the traffic load of each 1003 link; 1005 o TS-REQ02 (IC): The I2RS Client-Agent must be able to read the 1006 local rib of each DC/Metro gateway and the policies deployed on 1007 each gateway; 1009 o TS-REQ03 (IC): The I2RS Client-Agent must be able to add or delete 1010 or modify the relevant rib items and relevant polices to steer the 1011 traffic as expected; and adjust traffic placement. 1013 o TS-REQ-04 (IC): The I2RS Client-Agent must have the ability to 1014 collect the LSP information either from the PCE or directly from 1015 network devices; 1017 o TS-REQ-05 (OC): The I2RS Client-Agent must have the ability to 1018 collect the traffic matrix of the network, this is used to help 1019 the I2RS client to determine how to adjust the traffic placement; 1021 o TS-REQ-06 (IC): The I2RS Client-Agent must have the ability to 1022 read the rib information and relevant policies of each network 1023 node; 1025 o TS-REQ-07 (OC):collect the topology and segment information needed 1026 to help the I2RS client to compute the end-to-end path; 1028 o TS-REQ-08 (OC):read rib (especially the segment routing rib) 1029 information; 1031 o TS-REQ-09 (??): add/delete/modify the segment rib, this finally 1032 determines how the traffic is forwarded. 1034 9. Requirements from MPLS TE Networks Use Cases 1036 Theses are the requirements from the Traffic Steering use case 1037 described in [I-D.huang-i2rs-mpls-te-usecases] (OC): 1039 o MPLS-TE-REQ-01 (OC): Network programming software managing the 1040 static CR-LSP devices may incorporate an I2RS Client along with a 1041 path calculation entity, a label management entity, and a 1042 bandwidth management entity. The I2RS Client should be abl to 1043 communicate the static configuration to the network nodes, and 1044 monitor the status of the CR-LSPs. 1046 o MPLS-TE-REQ-02 (OC): The I2Client should be able to synchronously 1047 send the configuration for all of the network nodes from egress 1048 node to ingress node via the I2RS Agents attached to each node, 1049 and be able to delay the final ingress node configuration until 1050 all the I2RS AGents on all other nodes toward the egress have 1051 denoted a successful path set-up. 1053 o MPLS-TE-REQ-03 (OC): MPLS TE defines abundant constraints such as 1054 explicit path, bandwidth, affinity, SRLG, priority, hop limit, and 1055 others. The I2RS Client Agent exchange should be able to signal 1056 concurrent local path calculation could obtain an optimized result 1057 and allow more services to be held in a TE network. The I2RS 1058 Agent should be able to trigger a global concurrent re- 1059 optimization at a specific time on multiple nodes by communicating 1060 with each node's I2RS agent. 1062 o MPLS-TE-REQ-04 (NA): The I2RS client should be able to manually 1063 calculate a re-optimization of the the MPLS TE network and send 1064 the new constraints including the calculated path to each node via 1065 the I2RS agent with an indication to re-signal the TE LSPs with 1066 make-before-break method. 1068 o MPLS-TE-REQ-05 (OC): With I2RS, the node's I2RS agent should be 1069 able to send to an I2RS client a status notification that not 1070 enough resources exist for a back up LSP and TE tunnel. Upon 1071 receiving this notification the I2RS client should be able to 1072 trigger concurrent calculation for the failed path calculation of 1073 the backup LSP or TE tunnel and send the updated paths to I2RS 1074 agents with a command to re-signal the TE LSPS with make-before- 1075 break Method. 1077 o MPLS-TE-REQ-06 (NA): With I2RS, upon receipt the failure 1078 notification from an I2RS Agent, the I2RS client would create a 1079 global concurrent optimization to handle the failure event. This 1080 would occur by the I2RS client signalling the I2RS agents on all 1081 nodes to: a) trigger a new concurrent calculation of the backup 1082 LSP or TE tunnel via failed path calculation, and b) re-signal 1083 updates to the TE LSPs process with a make-before-break method. 1085 o MPLS-TE-REQ-07 (NA): Upon receiving a signal an upgrade event 1086 signal (from operator), the I2RS client could calculate another 1087 path for the affected TE tunnels to deviate traffic away from the 1088 resource being upgraded, and then send the request to I2RS agents 1089 on the appropriate nodes to move the traffic. After the upgrade 1090 completes, the I2RS client can simply remove I2RS configurations 1091 causing the traffic to revert to the original path. Or, the I2RS 1092 can re-optimize the TE tunnels for another pathways (E.g. as a 1093 part of a sequence of upgrades). 1095 o MPLS-TE-REQ-08 (OC): I2RS agents can notify I2RS Clients of 1096 impending or existing MPLS TE overload conditions that might cause 1097 TE LSP rejections. This overload conditions include: due to CPU, 1098 memory, LSP label space, or LSP numbers. 1100 o MPLS-TE-09 (IC): Automatic bandwidth adjustment applications can 1101 also be linked to the I2RS clients need to monitor the traffic on 1102 TE tunnels in order to provide traffic analysis. The I2RS client 1103 should be able to read the TE Tunnel topology and the bandwidth 1104 analysis in order to automatically calculate a new path for the TE 1105 tunnel if it is needed. The I2RS Client also needs to be able to 1106 the I2RS agents in the nodes to install the new TE Tunnels with 1107 the make-before-break option. 1109 o MPLS-TE-REQ-10 (IC): With I2RS, the node failure or link failure 1110 can be part of the notification stream sent by an I2RS Agent to an 1111 I2RS Client on a centralized server gathering information. 1113 o MPLS-TE-REQ-11 (IC): The I2RS client can notify the I2RS agents on 1114 specific nodes (or devices) to re-signal TE LSPs one by one if 1115 there is a resource dependency. 1117 o MPLS-TE-REQ-12 (IC): The I2RS Client can gather the TE LSPs' state 1118 from I2RS Agents on all nodes in order to coordinate such handling 1119 of LSP resources. 1121 o MPLS-TE-REQ-13 (OC): The I2RS Clients collecting information from 1122 I2RS Agents can be arranged in a hierarchy to provide scaling of 1123 collections. An application hosting an I2RS client collecting 1124 information from I2RS Agents on nodes can have an I2RS Agent that 1125 reports combined information to a single location. 1127 10. Requirements from MPLS LDP Networks Use Cases 1129 These are the I2RS requirements for the MPLS LDP use case described 1130 in [I-D.chen-i2rs-mpls-ldp-usecases]: 1132 o MPLS-LDP-REQ-01 (IC): The I2RS Client-agent exchange should allow 1133 the distribution of the configuration for PWE3, MPLS LDP and 1134 associated protocols to be distributed from a central location 1135 where the global PWE3 provisioning information could be stored. 1136 The I2RS Client-Agent exchange should also be able to push the 1137 configuration of the local LDP LSR ID and peer addresses to set up 1138 the targeted session to the pseudowire endpoints. 1140 o MPLS-LDP-REQ-02 (IC): When an the end-user wants to disable 1141 IPoMPLS (IP over MPLS) application on a L2VPN/PW Targeted LDP 1142 session, the I2RS Client-I2RS agent should be able to set type of 1143 application over the established LDP session. In this way LDP 1144 speaker can only advertise to its peer the application data which 1145 the user is interested in. 1147 o MPLS-LDP-REQ-03 (OC): The I2RS Agent notifications should allow an 1148 I2RS client to subscribe to a stream of state changes regarding 1149 the LDP sessions or LDP LSPs from the I2RS Agent. Specifically it 1150 is important that LDP session is tract for sessions state coming 1151 up or going down. The I2RS Client-I2RS Agent exchange should 1152 allow additional queries to the AGent to determine a) why the 1153 service is invalid, b) calculating whether an alternate path 1154 should be switched to, and c) determining how to switch to other 1155 links or nodes in order to recover from the link failure or node 1156 failure. 1158 o MPLS-LDP-REQ04 (IC): The I2RS interface provides way to monitor 1159 and control the limited resources on these access devices. The 1160 I2RS client should be able to instruct the I2RS agent in each of 1161 these devices to set the maximum number of LDP LSPs in each device 1162 prior to enabling LDP on the devices. The I2RS client should also 1163 be able to enable a notification service on each device with a 1164 with a warning threshold. Once the number of LDP LSPs reaches the 1165 threshold, the I2RS agent will send a notification message to the 1166 I2RS client. Often the I2RS client will be associated a network 1167 management agent that can determine what next steps need to be 1168 done based on policy or operator input. 1170 11. Requirements from Mobile Backhaul Ues Cases 1172 Mobile BackHaul Use cases described in [draft-ietf-zhang-mbb- 1173 usecases-01] are: 1175 o MBH-REQ-01 (OC): The I2RS client-agent communication can 1176 distribute position-critical changes to IGP nodes using this 1177 global knowledge to quicken changes to support traffic during 1178 failures or traffic overloads. To enable this feature, the I2RS 1179 Clients-Agent communication needs to pass information on which IGP 1180 process or Level or Area the given node and links belong to. 1182 o MBH-REQ-02 (OC): I2RS must allow operators to use of I2RS clients 1183 to distribute time-critical changes in configuration to I2RS 1184 agents associated with each routing node. This feature will 1185 simplify and automate configuration and monitoring of a mobile 1186 backhaul network to allow it to readily adapt to changing network 1187 sizes (and scales) and radio applications. 1189 o MBB-REQ-03 (OC): I2RS Clients-Agent communication needs to pass 1190 information on: 1192 * T-LDP configurations and status; 1194 * BGP peer configurations, peer topologies and status; 1196 * BGP-based LSP topologies and status; 1198 * Reset VPN topologies, and per node configurations; 1200 o MBB-REQ04 (IC): Route policy enforcement in mobile backhaul 1201 networks needs to be more dynamic and flexible than the current 1202 methods take hours (or even days) to configure route policy across 1203 a network. The I2RS interface must provide a programmatic way to 1204 configure (both policy and device) and monitor thousands of 1205 devices individually whose configuration is based on the devices 1206 role (such as ASRSs in one AS, ASBRs between ASs and other 1207 service-touch nodes). 1209 o MBB-REQ-05 (NA): I2RS clients should be able to contact I2RS 1210 agents on nodes to query role-based information from the network 1211 status. After collecting the status, the I2RS client can develop 1212 the BGP policies based on role information and push the BGP 1213 policies to the I2RS agents that would load the alternate policies 1214 into the network device. The I2RS Agents loading the alternate 1215 policies could then send status back to the I2RS Client. 1217 o MBH-REQ06 (??): I2RS clients can provide centralized control of 1218 many network devices via the I2RS Client-Agent communication. The 1219 I2RS programmatic interface can automate the collection and 1220 analysis of each device's capability so that the centralized I2RS 1221 client could calculate the optimal LSP path and distribute the 1222 configuration to individual devices. Automation of the collection 1223 of device capability should be available as query, notification, 1224 or a published stream. 1226 o MBH-REQ07 (NA): While the I2RS RIB Information Model 1227 [[I-D.ietf-i2rs-rib-info-model]] provides for routes with tunnels 1228 or MPLS LSP, the features defined in this model are not sufficient 1229 to configure both types of LSPs needed for the VPN technology in 1230 mobile backhaul networks. Additional I2RS Informational models 1231 need to be created to support these features. 1233 o MBH-REQ08 (NA): The hierarchical protection architecture in mobile 1234 backhaul network offer high network reliability and more 1235 flexibility to meet the various needs of the tunnels and services. 1236 The I2RS interface in this use case is needed to automate the 1237 configuration and monitoring so that tunnel protection and service 1238 protection interwork in a flexible and reliable manner. 1240 o MBB-REQ09 (OC): The I2RS architecture (client-agent) should allow 1241 the two features for network monitoring naturally in its basic 1242 modes: 1244 * allow a combination of multi-layer network monitor tools with 1245 exact detection parameters to be configured on the network 1246 device 1248 * Facilitate the reporting the detection result as notification 1249 or publication stream 1251 It is important the result of these features allow the outages and 1252 traffic congestion or discards to be detected real-time with I2RS 1253 Client(s) in each node, and the detection result will be reported 1254 to the I2RS agents to get the exact status of the network. 1256 12. Requirements from Large Data Flows are 1258 Each of these requirements has been given an an ID number of L-Flow- 1259 nn for ease of reference. 1261 The requirements from the Large Data Flows use case described in 1262 [I-D.krishnan-i2rs-large-flow-use-case] are (IC): 1264 L-Flow-REQ-01 (IC): For redirecting large flows to a specific 1265 component, a PBR entry should be programmable for the flow with 1266 its nexthop that identifies the specific LAG or ECMP component. 1268 L-Flow-REQ-02 (IC): For adjusting the weights used to distribute 1269 traffic across components of the LAG or ECMP, I2RS should provide 1270 a programmable mechanism should be provided that identifies ECMP 1271 entries and is able to associate weights that can be programmed 1272 for each of the components. To do this in a scalable fashion, it 1273 would be useful to have the notion of an ECMP nexthop that is used 1274 by multiple routes 1276 L-Flow-REQ-03 (IC): The I2RS interface (protocol/IMs) should allow 1277 for a globally optimal path is programmed in the IP network using 1278 hop-by-hop PBR rules. These PBR rules may include: 1280 * Being able to adjust the weights of the ECMP table for 1281 different nexthops should be adjusted to factor the large flows 1283 * Being able to address an ECMP group, so that all routes sharing 1284 an ECMP group are addressed together. 1286 * the ability to program PBR entries at the edge LSR, and 1288 * the ability to program new LSPs in the network. 1290 L-Flow-REQ-04 (OC): The I2RS protocol should be able to invoke the 1291 link aggregation IEEE 802.1AX Marker Protocol via the I2RS 1292 protocol. This is useful during a period of rebalancing occurs 1293 before flows are moved. 1295 L-Flow-REQ-05 (IC): The I2rs protocol should allow Quality of 1296 Service (QoS) actions such as rate-limiting, re-marking, or 1297 discarding can be performed on the flows based on configured 1298 policies and nexthop redirection actions to be programmed, and to 1299 be programmed independently of of each other. 1301 L-Flow-REQ-06 (IC): Once a large flow has been detected, I2RS must 1302 be used to modify the forwarding tables in the router to: 1304 * In the case of large flow load balancing, be able to 1305 redirecting the large flow to a particular member with the LAG 1306 or ECMP group and readjusting the weights of the other members 1307 to account for the large flow 1309 * In the case of DDoS mitigation, the action involves rate 1310 limiting, remarking or potentially discarding the large flow in 1311 question. 1313 13. Large Data Collection Systems 1315 The requirements from the Large Data Collection Systems Use cases 1316 described in [draft-swhyte-i2rs-data-collection-system] are (OC): 1318 L-Data-REQ-01 (OC): I2rs must be able to collect large data set 1319 from the network with high frequency and resolution with minimal 1320 impact to the device's CPU and memory. 1322 L-Data-REQ-02 (IC): I2RS must be able to use a database model 1323 where the data on the network node must be able to be described in 1324 the I2RS exchange as the data plus the structure of the data. The 1325 I2RS management system consumes and understand the data only after 1326 it consumes and understand the database model or has been trained 1327 by vendor published model 1329 L-Data-REQ-03 (IC): I2RS should use a pub-sub model which allows 1330 scaling plus push or pull of data. 1332 L-Data-REQ-04 (IC): I2RS should support capability negotiation to 1333 inform a subscriber of the options for publication of data. The 1334 options include transport, security, and error handling. 1336 L-Data-REQ-05 (IC): The I2RS data tansfer should be format 1337 agnostic. This means the publisher and subscriber may agree upon 1338 XML, JSON, MTL, protobufs or any other format. 1340 L-Data-REQ-06 (IC): I2RS Transports must be able to be chosen by a 1341 I2RS Client-I2RS Agent pair. An I2RS Client-I2RS Agent pair 1342 should be allowed to negotiate the transport options from a list 1343 of options. 1345 L-DATA-REQ-07 (IC): The I2RS interface (protocol and IMs) should 1346 allow a subscribe to select portions of the data model. 1348 L-Data-REQ-08 (IC): The I2RS interface (protocol and IMs) should 1349 allow for multiple publish subscriptions at a time. 1351 L-Data-REQ-09 (IC): Timestaps should be associated with data that 1352 requires it. Not all data will require a time stamp. Additional 1353 time stamps may be added. 1355 L-Data-REQ-10 (IC): The I2RS should support the query and 1356 "introspection" of the data model. The Introspections provides 1357 support for data verification, easier inclusion in legacy data, 1358 and easier merging with data streams. 1360 L-Data-REQ-11 (IC): After the I2rs Client-Agent have exchanged 1361 capabilities, a database model, and filters used to select 1362 elements of the model to subscribe to, the framework should 1363 support a standard way to register for all the data desired, using 1364 whatever capabilities were advertised by the node. Once 1365 registration is complete, the control channel can be closed. 1366 Ensuring subscriptions are correct, complete, and replicated or 1367 not, is up to the overall system and not the agent on the network 1368 node. 1370 L-Data-REQ-12 (IC): The I2RS interface should support user 1371 subscriptions to data with the following parameters: 1373 * push of data synchronously or asynchronously via registered 1374 subscriptions 1376 * pull data off in a one-shot pull or in multiple sequences 1378 * provide dynamic subscriptions that can be setup via IPFIX feed 1379 * support of subscriber and consumer I2RS Client-agent pairs 1381 * allow remapping of a node's databases 1383 L-Data-REQ-13 (IC): The I2RS interface must handle and report 1384 errors that occur with data subscription, stale data, repeated 1385 transport failures, and other (yet unknown) errors 1387 14. CDNI 1389 The requirements from the Content Delivery Network Interaction 1390 described in [I-D.shin-i2rs-usecases-cdni-request-routing] are (OC): 1392 o CDNI-REQ-01 (OC): The I2RS interface should support two CDNI 1393 functionalities [I-D.ietf-cdni-framework]: 1395 * Request Routing Interface - Footprint and Capabilities 1396 Advertisement; the asynchronous advertisement of footprint and 1397 capabilities by a dCDN that allows a uCDN to decide whether to 1398 redirect particular user requests to that dCDN via the ALTO 1399 protocol; and 1401 * Request Routing Interface - Redirection; the synchronous 1402 operation of actually redirecting a user request via I2RS 1403 manipulation of the routing plane. 1405 o CDNI-REQ-02 (OC): The I2RS (Protocol and IM) should provide 1406 facilities to enable the query/response of information from an 1407 ALTO services in a node routing functions so that the upstream CDN 1408 provider can select a proper downstream CDN provider for a given 1409 end user request. 1411 o CDNI-REQ-03 (OC): I2RS (protocol and IM) should provide facilties 1412 to enable I2RS can help the upstream CDN provider to redirect a 1413 content request message to a downstream CDN provider for a given 1414 end user request as with the following features: 1416 * The uCDN relays this message between I2RS Clients and I2RS 1417 agents with content distribution metadata, and queries the dCDN 1418 whether user request message can be delivered. This query can 1419 have multiple dDCN that the user message can be delivered to. 1421 * the I2RS agent associated with the dCDN delivery requests 1422 indicating which dCDN (if any) the user message can be 1423 delivered to. 1425 * Allow dCDN to be managed to deliver content by having the 1426 messages to signal back to the uCDN the (destination (?)) iP 1427 address for the content, on the dCDN, and the pathway between 1428 the uCDN for surrogate deliver via the dCDN of user data. Part 1429 of this management is the passing of URL of the surrogate in 1430 dCDN (for HTTP Redirection to be transmitting) back from the 1431 dCDN to the uCDN so the uCDN can inform the end user. 1433 15. IANA Considerations 1435 This document makes no request of IANA. 1437 16. Security Considerations 1439 Routing information is very critical and sensitive information for 1440 the operators. I2RS should provide strong security mechanism to 1441 protect the routing information that it could not be accessed by the 1442 un-authorised users. It should also protect the security and 1443 integrity protection of the routing data. 1445 17. References 1447 17.1. Normative References 1449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1450 Requirement Levels", BCP 14, RFC 2119, 1451 DOI 10.17487/RFC2119, March 1997, 1452 . 1454 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1455 "Forwarding and Control Element Separation (ForCES) 1456 Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, 1457 . 1459 17.2. Informative References 1461 [I-D.amante-i2rs-topology-use-cases] 1462 Medved, J., Previdi, S., Lopez, V., and S. Amante, 1463 "Topology API Use Cases", draft-amante-i2rs-topology-use- 1464 cases-01 (work in progress), October 2013. 1466 [I-D.bitar-i2rs-service-chaining] 1467 Bitar, N., Heron, G., Fang, L., ramki, r., Leymann, N., 1468 Shah, H., and W. Haddad, "Interface to the Routing System 1469 (I2RS) for Service Chaining: Use Cases and Requirements", 1470 draft-bitar-i2rs-service-chaining-01 (work in progress), 1471 February 2014. 1473 [I-D.chen-i2rs-mpls-ldp-usecases] 1474 Chen, X. and Z. Li, "Use Cases for an Interface to LDP 1475 Protocol", draft-chen-i2rs-mpls-ldp-usecases-00 (work in 1476 progress), October 2013. 1478 [I-D.chen-i2rs-ts-use-case] 1479 Chen, M. and S. Hares, "I2RS Traffic Steering Use Case", 1480 draft-chen-i2rs-ts-use-case-01 (work in progress), July 1481 2014. 1483 [I-D.hares-i2rs-use-case-vn-vc] 1484 Hares, S. and M. Chen, "Use Cases for Virtual Connections 1485 on Demand (VCoD) and Virtual Network on Demand (VNoD) 1486 using Interface to Routing System", draft-hares-i2rs-use- 1487 case-vn-vc-03 (work in progress), July 2014. 1489 [I-D.huang-i2rs-mpls-te-usecases] 1490 Huang, T., Li, Z., and S. Hares, "Use Cases for an 1491 Interface to MPLS TE", draft-huang-i2rs-mpls-te- 1492 usecases-02 (work in progress), July 2014. 1494 [I-D.ietf-i2rs-architecture] 1495 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1496 Nadeau, "An Architecture for the Interface to the Routing 1497 System", draft-ietf-i2rs-architecture-13 (work in 1498 progress), February 2016. 1500 [I-D.ietf-i2rs-problem-statement] 1501 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 1502 Routing System Problem Statement", draft-ietf-i2rs- 1503 problem-statement-10 (work in progress), February 2016. 1505 [I-D.ietf-i2rs-rib-info-model] 1506 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1507 Base Info Model", draft-ietf-i2rs-rib-info-model-08 (work 1508 in progress), October 2015. 1510 [I-D.ietf-sfc-problem-statement] 1511 Quinn, P. and T. Nadeau, "Service Function Chaining 1512 Problem Statement", draft-ietf-sfc-problem-statement-13 1513 (work in progress), February 2015. 1515 [I-D.ji-i2rs-usecases-ccne-service] 1516 Ji, X., Zhuang, S., Huang, T., and S. Hares, "I2RS Use 1517 Cases for Control of Forwarding Path by Central Control 1518 Network Element (CCNE)", draft-ji-i2rs-usecases-ccne- 1519 service-02 (work in progress), July 2014. 1521 [I-D.keyupate-i2rs-bgp-usecases] 1522 Patel, K., Fernando, R., Gredler, H., Amante, S., White, 1523 R., and S. Hares, "Use Cases for an Interface to BGP 1524 Protocol", draft-keyupate-i2rs-bgp-usecases-04 (work in 1525 progress), July 2014. 1527 [I-D.krishnan-i2rs-large-flow-use-case] 1528 ramki, r., Ghanwani, A., Kini, S., McDysan, D., and D. 1529 Lopez, "Large Flow Use Cases for I2RS PBR and QoS", draft- 1530 krishnan-i2rs-large-flow-use-case-04 (work in progress), 1531 April 2014. 1533 [I-D.lapukhov-bgp-routing-large-dc] 1534 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 1535 routing in large-scale data centers", draft-lapukhov-bgp- 1536 routing-large-dc-06 (work in progress), August 2013. 1538 [I-D.medved-i2rs-topology-requirements] 1539 Medved, J., Previdi, S., Gredler, H., Nadeau, T., and S. 1540 Amante, "Topology API Requirements", draft-medved-i2rs- 1541 topology-requirements-00 (work in progress), February 1542 2013. 1544 [I-D.shin-i2rs-usecases-cdni-request-routing] 1545 Shin, M. and S. Lee, "CDNI Request Routing with I2RS", 1546 draft-shin-i2rs-usecases-cdni-request-routing-00 (work in 1547 progress), July 2014. 1549 [I-D.swhyte-i2rs-data-collection-system] 1550 Whyte, S., Hines, M., and W. Kumari, "Bulk Network Data 1551 Collection System", draft-swhyte-i2rs-data-collection- 1552 system-00 (work in progress), October 2013. 1554 [I-D.white-i2rs-use-case] 1555 White, R., Hares, S., and A. Retana, "Protocol Independent 1556 Use Cases for an Interface to the Routing System", draft- 1557 white-i2rs-use-case-06 (work in progress), July 2014. 1559 [I-D.zhang-i2rs-mbb-usecases] 1560 Zhang, L., Li, Z., Liu, D., and S. Hares, "Use Cases of 1561 I2RS in Mobile Backhaul Network", draft-zhang-i2rs-mbb- 1562 usecases-01 (work in progress), February 2014. 1564 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1565 Element (PCE)-Based Architecture", RFC 4655, 1566 DOI 10.17487/RFC4655, August 2006, 1567 . 1569 [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, 1570 M., and D. Brungard, "Requirements for GMPLS-Based Multi- 1571 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, 1572 DOI 10.17487/RFC5212, July 2008, 1573 . 1575 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 1576 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 1577 DOI 10.17487/RFC5286, September 2008, 1578 . 1580 [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, 1581 "Framework for PCE-Based Inter-Layer MPLS and GMPLS 1582 Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, 1583 September 2009, . 1585 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 1586 Optimization (ALTO) Problem Statement", RFC 5693, 1587 DOI 10.17487/RFC5693, October 2009, 1588 . 1590 Authors' Addresses 1592 Susan Hares 1593 Huawei 1595 Email: shares@ndzh.com 1597 Mach Chen 1598 Huawei Technologies 1599 Huawei Bld., No.156 Beiqing Rd. 1600 Beijing 100095 1601 China 1603 Email: mach.chen@huawei.com