idnits 2.17.1 draft-pentikousis-supa-mapping-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (May 11, 2015) is 3273 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.lhotka-netmod-routing-cfg' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'I-D.strassner-supa-generic-policy-info-model' is defined on line 626, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-bi-supa-policy-model-01 == Outdated reference: A later version (-03) exists of draft-contreras-supa-yang-network-topo-02 == Outdated reference: A later version (-05) exists of draft-strassner-supa-generic-policy-info-model-00 == Outdated reference: A later version (-02) exists of draft-zhou-supa-framework-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Pentikousis 3 Internet-Draft EICT GmbH 4 Intended status: Informational D. Zhang 5 Expires: November 12, 2015 May 11, 2015 7 Simplified Use of Policy Abstractions (SUPA): Configuration and Policy 8 Mapping 9 draft-pentikousis-supa-mapping-05 11 Abstract 13 Nowadays, the underlying network infrastructure grows in scale and 14 complexity, which make it challenging for network operators to manage 15 and configure the network. Deploying policy or configuration based 16 on an abstract view of the underlying network is much better than 17 manipulating each individual network element, however, in this case, 18 the policy and configuration cannot be recognized by the network 19 elements. This document describes guidelines for mapping said 20 abstract configuration and policy into device-level configuration and 21 the way in which such models will be processed by software to produce 22 configuration details for actual devices. The Simplified Use of 23 Policy Abstractions (SUPA) framework overview, exemplary mechanism 24 for exchanging service polices among the different elements 25 participating in their deployment and enforcement, and primary 26 procedures of mapping are described. Moreover, an exemplary mapping 27 scenario is provided to illustrate the defined mechanism. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 12, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Configuration and Policy Mapping . . . . . . . . . . . . . . 3 67 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4.2. Mapping Procedure . . . . . . . . . . . . . . . . . . . . 5 69 4.3. SUPA Mapping Example . . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 8.2. informative References . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 As the underlying network infrastructure grows, new services are 81 introduced, and traffic volumes increase rapidly, it becomes 82 significantly more challenging and complicated to maintain the 83 network and deploy new services than in the past. Configuration 84 automation can provide significant benefits in deployment agility. 85 Simplified Use of Policy Abstractions (SUPA) 86 [I-D.zhou-supa-framework] aims to improve configuration automation by 87 introducing multi-level abstractions. In SUPA, a generic policy 88 information model [I-D.strassner-supa-generic-policy-info-model]is 89 defined, which defines a generic framework for representing policy 90 rules of any type, with this model, SUPA is capable to define a 91 common framework for representing different types of policies, 92 although the syntax and semantics of these policies are very 93 different. Based on the generic policy model, several policy data 94 models are defined to express different manners of policy 95 enforcement, such as ECA and intent-based polices. The information 96 models of various network services is also utilized in SUPA to allow 97 network operators to manipulate their infrastructure as a whole 98 rather than individual devices. Well-designed abstractions are able 99 to provide a wide range of granularity for various applications 100 needs. However, these information models cannot be directly utilized 101 by network elements, thus a mapping mechanism is necessary to bridge 102 the gap between these information models and network element- 103 recognized configuration. 105 SUPA employs Network Manager/Controller. Network Manager/Controllers 106 represent one or more entities that are able to control the operation 107 and management of a network infrastructure and mediate between the 108 Service Management and the network elements to provide, maintain and 109 deploy network services and policies. Each Network Manager/ 110 Controller supports the SUPA interface/protocol and is a software 111 repository, which stores the information associated with each network 112 element. The mapping mechanism could be part of the Network Manager/ 113 Controller implementation in order to map the SUPA model(s) into 114 specified configuration models (or so-called southbound interfaces), 115 which can be recognized by the network element(s). 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "Network Manager/Controller", 121 and "OPTIONAL" in this document are to be interpreted as described in 122 [RFC2119]. 124 3. Terminology 126 This document uses the following terms: 128 Network element (NE): a physical or virtual entity that can be 129 locally managed and operated 131 SUPA: Simplified Use of Policy Abstractions 133 4. Configuration and Policy Mapping 135 This section introduces a framework for mapping configuration and 136 policy in the context of a network with several network elements and 137 one or more Service Managements. 139 4.1. Overview 141 The SUPA framework for mapping network-level configuration into 142 specific network management and controlling policies is illustrated 143 in Figure 1. It consists of i) Service Management, ii) Network 144 Manager/Controller and iii) NEs. 146 +------------------------+ ------------------------- 147 | Service Management | | 148 | +--------------------+ | | 149 | | Policy | | | 150 | +--------------------+ | | 151 | +--------------------+ | | 152 | | Service Management | | | 153 | | | | | 154 | +--------------------+ | | 155 +------------------------+ | 156 | NetConf/RestConf | 157 | Network 158 +-----------------v--------------+ Level 159 | +------------------------+ | | 160 | | Network Resource | | | 161 | | | | | 162 | +------------------------+ | | 163 | Network | | 164 | Management/Controller ------------------------- 165 | +-----------------+ | | 166 | |protocol-specific| | | 167 | | configuration | | | 168 | +-----------------+ | | 169 +-----------------^--------------+ Device 170 | Level 171 +-----------------+--------------------+ | 172 CLI/I2RS | | CLI/I2RS | 173 | | | 174 | | | 175 +---------------+ +---------------+ | 176 | | | | | 177 | NE | ... | NE | | 178 | | | | | 179 +---------------+ +---------------+---------- 181 Figure 1: SUPA configuration and policy mapping overview 183 Service Management manages and programs the underlying network 184 elements indirectly based on the abstract view of the network 185 infrastructure. In practice, this means that Service Management can, 186 among others, configure the underlying network as a whole rather than 187 as a set of individual network elements. As a result, the diversity 188 of the actual network elements in active operation is abstracted, 189 which allows Service Management to manage and program the network in 190 a simpler, more maintainable and efficient manner. On the other end 191 of the spectrum, the NEs can continue their regular operation without 192 having to become cognizant of the fact that configuration is applied 193 at the network level. 195 In order to bridge the gap between configuration set by Service 196 Management and that required by the NEs, the Network Management and 197 Network Manager/Controller has to provide a mapping mechanism which 198 translates the configuration settings with high level of abstractions 199 to device-level configurations. This document considers three 200 modules in the SUPA framework to support such a mapping mechanism, as 201 follows. 203 First, a network resource module maintains the resource of the 204 infrastructure, such as topology of the network. It provides the 205 information of the resource, which maybe with high level of 206 abstraction to Service Management for management, and it also 207 provides the necessary information of each network element, which 208 with low level of abstraction, when mapping configuration from the 209 network-level to device-level. Second, the service management and 210 policy module, which is responsible for transmitting (send/receive) 211 and process the network-level configuration. Third, the protocol- 212 specific configuration produces the output of the mapping mechanism 213 and is responsible for distributing the device- level configuration 214 to the corresponding network elements. 216 In this framework, one would expect the introduction and use of 217 algorithms/strategies for specific network services which can 218 automatically generate device-level configuration based on the 219 Service Management policies/configurations. Note, however, that said 220 algorithms and strategies are out of the scope of this document. 222 4.2. Mapping Procedure 224 From the view point of Service Management: 226 Firstly, the operators or network administrators use a policy editor 227 GUI to generates a set of policies based on application requirements, 228 and sends these policies to the service management. It should be 229 noted that, the policies here maybe generated with different views, 230 such as business view and system view, for different users, however, 231 these polices and the interfaces between the application and the 232 Service Management are out of the scope of SUPA. 234 Secondly, in the Service Management, based on the generic policy 235 information model the policies generated in the previous step are 236 translated into the policy data models defined in SUPA. And then, 237 policy conflict analysis may be processed to verify the new policy 238 won't conflict the predefined policies. 240 Thirdly, if the new policy is valid, Service Management begin to 241 enforce this policy, in this step, it needs some context of the 242 underlying network if necessary, especially the infrastructure 243 (physical or logical) of the network, before it deploys a policy/ 244 service to the network. For example, if Service Management attempts 245 to steer traffic from one path to another, it should have the 246 information of the existing paths first. Service Management requests 247 this context information from the network resource block of Network 248 Manager/Controller. This procedure does not have to be processed 249 every time Service Management deploys a policy/service. 251 Fourthly, service Management can obtain the current status of the 252 service, which will be affected by the new policy, for reference 253 before it deploys a new policy. In such a case, Service Management 254 sends a "GET" request to the Network Manager/Controller, and the 255 Network Manager/Controller encapsulates this information with the 256 models specified by SUPA network service models. 258 Thirdly, Based on the service and policy configuration, and also 259 service/network status if necessary, Service Management deploys the 260 action of the policy by sending a "POST" request to the Network 261 Manager/Controller. 263 From the view point of Network Manager/Controller: 265 Firstly, the Network Manager/Controller is responsible for 266 maintaining the infrastructure information, and it provides 267 information to Service Managements with the network resource models, 268 such as topology information model. 270 Secondly, once the Network Manager/Controller receives actions of a 271 policy from Service Managements, it maps these actions to protocol- 272 specific models. The intelligence/algorithms of how to do the 273 mapping is implementation-specific and out of the scope of this 274 specification, as are the protocol-specific models. 276 Thirdly, with the protocol-specific models, the device-level 277 configurations for heterogeneous devices can be generated and 278 conveyed by the Network Manager/Controller using, for example, 280 [RFC6020], [I-D.bierman-netconf-restconf], 281 [I-D.atlas-i2rs-architecture] and CLI, to the corresponding NEs. 283 4.3. SUPA Mapping Example 285 +-----------------------+ 286 | +---------+ | 287 | |TE Policy| | 288 | +---------+ | 289 | Service Management | 290 +----------^------------+ 291 | 292 | NETCONF/RESTCONF 293 | 294 +--------------v---------------+ 295 | | 296 | Network Manager/Controller | 297 | | 298 +--------------^---- ----------+ 299 | CLI/I2RS/NETCONF 300 | 301 +----------------v--------------------+ 302 | | 304 192.0.2.1 192.0.2.2 305 +------+ +------+ +------+ 306 | A +----------+ C +------------+ B +-----+ 307 +-+--+-+ +------+ +---+--+ | 308 | | 192.0.2.3 | | 309 ++ | | | 310 | | | +---+--+ 311 | | | | G | 312 +---+--+| | +---+--+ 313 | F || | | 314 +------+| +--+---+ +---+--+ | 315 +-------+ D +-----------------+ E +-----+ 316 +------+ +------+ 317 192.0.2.4 192.0.2.5 319 Figure 2: Bandwidth use optimization for DC Interconnection 321 Figure 2 illustrates a simple example in which interoperability 322 between Service Management and Network Manager/Controller in an 323 inter-data center (inter-DC) environment is considered. 325 For the purposes of this example, let us focus on the dynamic 326 configuration of the IP path between the seven illustrated DCs, 327 labeled A, B, C, D, E, F and G, based on the policies. First of all, 328 we would like the IP path to be created based on certain constraints. 329 Secondly, we would like to map it to the device-level connections. 330 In this scenario, there are two paths from DC A to DC B. Typical IP 331 shortest-path routing would choose path A(192.0.2.1)-C(192.0.2.3) > 332 B(192.0.2.2). However, under certain conditions, such as, for 333 instance, when the bandwidth utiliaztion between A and B is beyond 80 334 percents, the Service Management can decide that is better to steer 335 traffic from path (A, C, B) to a new path which goes through a 336 specific node. This is a policy from business view, and it can be 337 expressed by the ECA policy data model defined in 338 [I-D.bi-supa-policy-model] but in this example, how this policy 339 translated into the ECA policy is not provided, because it is too 340 dependant on the implementation. 342 Figure 2 depicts the layer 3 topology of the underlying network. 344 First, Service Management needs some information about A, B, C, D and 345 the links between them. This information can be obtained from 346 Network Manager/Controller, and it is listed in the fragment below. 347 This information is derived from the Topology YANG model described in 348 [I-D.contreras-supa-yang-network-topo]. 350 351 352 1111111100000000 353 mapping_topo 354 ip 355 356 357 358 192.0.2.1 359 A 360 physical 361 adminUp 362 up 363 1111111100000000 364 365 366 192.0.2.2 367 B 368 physical 369 adminUp 370 up 371 1111111100000000 372 374 ... skip ... 376 377 192.0.2.3 378 C 379 physical 380 adminUp 381 up 382 1111111100000000 383 384 385 386 387 1 388 A2C 389 telink 390 bidrectional 391 adminUp 392 up 393 192.0.2.1 394 192.0.2.3 395 1111111100000000 396 397 2000 398 399 401 ... skip ... 403 404 2 405 C2B 406 telink 407 bidrectional 408 adminUp 409 up 410 192.0.2.3 411 192.0.2.2 412 1111111100000000 413 414 50000 415 416 417 418 420 Figure 3: Information of the underlying network 422 Secondly, Service Management defines the policy using policy policy 423 models defined in SUPA, and then sends the steering information 424 derived from service and policy information to Network Manager/ 425 Controller using a protocol such as [RFC6020], and 426 [I-D.bierman-netconf-restconf]. Figure 4 presents the policy for 427 traffic steering: the traffic (supaflow) with destination IP address 428 192.0.2.11/24 needs to be steered to DC B, the new path must go 429 through DC D. This configuration is derived from the YANG model 430 described in [I-D.bi-supa-policy-model]. An example of the steering 431 information is list in Figure 5, it specfies the traffic flow which 432 will be steered, and the constrains of the new path. 434 435 436 437 supa_vpn 438 L3VPN 439 supa_flow 440 441 442 4 443 444 445 3 446 447 448 449 bandwidth 450 451 452 453 454 utilization 455 456 457 above 458 459 460 80 461 462 463 464 465 466 192.0.2.4 467 468 pass 469 470 471 472 473 474 475 476 478 Figure 4: Example traffic steering policy 480 481 supa_flow 482 10000 483 484 485 192.0.2.0 486 24 487 488 489 490 491 path_1 492 auto 493 494 495 192.0.2.1 496 ingress 497 1 498 499 500 192.0.2.5 501 transit 502 2 503 504 505 192.0.2.2 506 egress 507 3 508 509 510 511 512 514 Figure 5: Example traffic steering information 516 Based on the steering information, the Network Manager/Controller 517 generates a path which meets the requirements: in this example, the 518 computed path is (A, D, E, B). Network Manager/Controller also has 519 to configure each device on the new path, not only the devices 520 specified by the configuration such as node D, but also the devices 521 in the underlying network which must be reconfigured, such as node E. 522 The topology information is also necessary when Network Manager/ 523 Controller decides which device ought to be configured. 525 With the assistance of other information in Network Manager/ 526 Controller, such as topology information, service/policy 527 configuration can be translated into protocol-specific yang models 528 (or southbound interface) first. Taking node D as an example, the 529 configuration expressed in the YANG model defined in 530 [I-D.lhotka-netmod-routing-cfg]could be as follows: 532 533 534 rtr0 535 Router D 536 537 538 rt:static 539 st0 540 541 Static routing is used for the internal network. 542 543 544 545 546 547 192.0.2.0/24 548 549 550 551 192.0.2.5 552 553 554 555 556 557 558 559 560 562 Figure 6: Example traffic steering requirements 564 The configuration of other nodes is similar. Based on this vendor- 565 neutral device-level configuration and the features of each NE, the 566 NE-specific configuration can be generated. Once nodes A, C, D and E 567 have received their respective NE-specific configurations, the 568 device-level configuration could be deployed and then, the traffic is 569 steered as Service Management specified. 571 5. Security Considerations 573 Security considerations will be discussed in an upcoming revision of 574 this document. 576 6. IANA Considerations 578 TBD 580 7. Acknowledgements 582 This document has benefited comments, suggestions, and proposed text 583 provided by Cathy Zhou and Will Liu (listed in alphabetical order). 584 Junru Lin and Zhayiyong contributed to an earlier version of this 585 draft. 587 8. References 589 8.1. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 595 Network Configuration Protocol (NETCONF)", RFC 6020, 596 October 2010. 598 8.2. informative References 600 [I-D.atlas-i2rs-architecture] 601 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 602 Nadeau, "An Architecture for the Interface to the Routing 603 System", draft-atlas-i2rs-architecture-02 (work in 604 progress), August 2013. 606 [I-D.bi-supa-policy-model] 607 Bi, J., Tadepalli, R., and M. Hayashi, "DDC Service Policy 608 YANG Data Model", draft-bi-supa-policy-model-01 (work in 609 progress), March 2015. 611 [I-D.bierman-netconf-restconf] 612 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 613 "RESTCONF Protocol", draft-bierman-netconf-restconf-04 614 (work in progress), February 2014. 616 [I-D.contreras-supa-yang-network-topo] 617 Contreras, L., Qu, A., and Y. Zha, "A YANG Data Model for 618 Network Topologies", draft-contreras-supa-yang-network- 619 topo-02 (work in progress), January 2015. 621 [I-D.lhotka-netmod-routing-cfg] 622 Lhotka, L., "A YANG Data Model for Routing Configuration", 623 draft-lhotka-netmod-routing-cfg-00 (work in progress), 624 March 2011. 626 [I-D.strassner-supa-generic-policy-info-model] 627 Strassner, J., "Generic Policy Model for Simplified Use of 628 Policy Abstractions (SUPA)", draft-strassner-supa-generic- 629 policy-info-model-00 (work in progress), April 2015. 631 [I-D.zhou-supa-framework] 632 Zhou, C., Contreras, L., Qiong, Q., and P. Yegani, "The 633 Framework of Shared Unified Policy Automation (SUPA)", 634 draft-zhou-supa-framework-00 (work in progress), January 635 2015. 637 Authors' Addresses 639 Kostas Pentikousis 640 EICT GmbH 641 Torgauer Strasse 12-15 642 Berlin 10829 643 Germany 645 Email: k.pentikousis@eict.de 647 Dacheng Zhang 648 Chaoyang Dist 649 Beijing 100000 650 P.R. China 652 Email: Dacheng.zhang@gmail.com