idnits 2.17.1 draft-li-teas-hierarchy-ip-controllers-01.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 date (September 3, 2018) is 2060 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 ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-02 == Outdated reference: A later version (-12) exists of draft-ietf-pce-applicability-actn-06 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-16 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-18 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-05 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-02 == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-yang-05 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-08 == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-03 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-11 == Outdated reference: A later version (-13) exists of draft-lee-teas-te-service-mapping-yang-10 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-01 == Outdated reference: A later version (-04) exists of draft-ietf-idr-rtc-hierarchical-rr-03 == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-03 Summary: 0 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Z. Li 3 Internet-Draft D. Dhody 4 Intended status: Informational H. Chen 5 Expires: March 7, 2019 Huawei Technologies 6 September 3, 2018 8 Hierarchy of IP Controllers (HIC) 9 draft-li-teas-hierarchy-ip-controllers-01 11 Abstract 13 This document describes the interactions between various IP 14 controllers in a hierarchical fashion to provide various IP services. 15 It describes how the Abstraction and Control of Traffic Engineered 16 Networks (ACTN) framework is applied to the Hierarchy of IP 17 controllers (HIC) as well as document the interactions with other 18 protocols like BGP, Path Computation Element Communication Protocol 19 (PCEP) to provide end to end dynamic services spanning multiple 20 domains and controllers (e.g. Layer 3 Virtual Private Network 21 (L3VPN), Seamless MPLS etc). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 7, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Mapping to ACTN . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Interface between Super Controller and Domain Controller 61 in HIC . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Path Computation/Path instantiation . . . . . . . . . . . 7 65 3.3. BGP considerations . . . . . . . . . . . . . . . . . . . 8 66 4. VPN Service . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Seamless MPLS . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2. L3VPN . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.3. L2VPN and EVPN service . . . . . . . . . . . . . . . . . 11 70 5. Possible Features/Extensions . . . . . . . . . . . . . . . . 11 71 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 12 72 6.1. Control Plane . . . . . . . . . . . . . . . . . . . . . . 12 73 6.1.1. PCE / PCEP . . . . . . . . . . . . . . . . . . . . . 12 74 6.1.2. BGP . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6.2. Management Plane . . . . . . . . . . . . . . . . . . . . 15 76 6.2.1. YANG Models . . . . . . . . . . . . . . . . . . . . . 15 77 6.2.2. Protocol Considerations . . . . . . . . . . . . . . . 16 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 11.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 Software-Defined Networking (SDN) refers to a separation between the 90 control elements and the forwarding components so that software 91 running in a centralized system called a controller, can act to 92 program the devices in the network to behave in specific ways. A 93 required element in an SDN architecture is a component that plans how 94 the network resources will be used and how the devices will be 95 programmed. It is possible to view this component as performing 96 specific computations to place flows within the network given 97 knowledge of the availability of network resources, how other 98 forwarding devices are programmed, and the way that other flows are 99 routed. The Application-Based Network Operation (ABNO) [RFC7491] 100 describes how various components and technologies fit together. 102 A domain [RFC4655] is any collection of network elements within a 103 common sphere of address management or path computation 104 responsibility. Specifically within this document we mean a part of 105 an operator's network that is under common management. Network 106 elements will often be grouped into domains based on technology 107 types, vendor profiles, and geographic proximity and under a domain 108 controller. 110 Multiple such domains in the network are interconnected, and a path 111 is established through a series of connected domains to form an end- 112 to-end path over which various services are offered. Each domain is 113 under the control of the domain controller (or lower-level 114 controller), and a "super controller" (or high-level controller) 115 takes responsibility for a high-level view of the network before 116 distributing tasks to domain controllers (or lower-level 117 controllers). It is possible for each of the domain to use a 118 different tunneling mechanism (eg RSVP-TE, Segment Routing (SR) etc). 120 [RFC8453] describes the framework for Abstraction and Control of 121 Traffic Engineered Networks (ACTN) as well as a set of management and 122 control functions used to operate multiple TE networks. This 123 documents would apply the ACTN principles to Hierarchy of IP 124 controllers (HIC) and focus on the applicability and interactions 125 with other protocol and technologies (specific to IP packet domains). 127 Sometimes, service (such as Layer 3 Virtual Private Network (L3VPN), 128 Layer 2 Virtual Private Network (L2VPN), Ethernet VPN (EVPN), 129 Seamless MPLS) require sites attached to different domains (under the 130 control of different domain controller) to be interconnected as part 131 of the VPN service. This require multi-domain coordination between 132 domain controllers to compute and setup E2E path for the VPN service. 134 This document describes the interactions between various IP 135 controllers in a hierarchical fashion to provide various IP services. 136 It describes how the Abstraction and Control of Traffic Engineered 137 Networks (ACTN) framework is applied to the Hierarchy of IP 138 controllers (HIC) as well as document the interactions with control 139 plane protocols (like BGP, Path Computation Element Communication 140 Protocol (PCEP)) and management plane aspects (Yang models) to 141 provide end to end dynamic services spanning multiple domains and 142 controllers (e.g. L3VPN, Seamless MPLS etc). 144 2. Overview 146 Figure 1 show examples of multi-domain IP domains under hierarchy of 147 IP controllers. 149 | 150 +------------+ 151 | SuperCo | 152 +------------+ 153 | 154 ---------------------------------- 155 | | | 156 +------------+ +------------+ +------------+ 157 | DoCo#1 | | DoCo#2 | | DoCo#3 | 158 +------------+ +------------+ +------------+ 160 +--Domain#1--+ +--Domain#2--+ +--Domain#3--+ 161 | | | | | | 162 | B------+---+---D-----E--+---+------J | 163 | / | | \ / | | \ | 164 | / | | \ / | | \ | 165 | A | | H | | L | 166 | \ | | / \ | | / | 167 | \ | | / \ | | / | 168 | C------+---+---F-----G--+---+------K | 169 | | | | | | 170 +------------+ +------------+ +------------+ 172 Figure 1: Example: Hierarchy of IP controllers (HIC) 174 The IP "Super Controller" receives request from the network/service 175 orchestrator to setup dynamic services spanning multiple domains. 176 The IP "Super Controller" breaks down and assigns tasks to the domain 177 controllers, responsible for communicating to network devices in the 178 domain. It further coordinates between the controller to provide a 179 unified view of the multi-domain network. 181 2.1. Mapping to ACTN 183 As per [RFC8453], ACTN has following main functions - 185 o Multi-domain coordination 187 o Virtualization/Abstraction 188 o Customer mapping/translation 190 o Virtual service coordination 192 These functions are part of Multi Domain Service Coordinator (MDSC) 193 and/or Provisioning Network Controller (PNC). Further these 194 functions are part of the controller / orchestrator. 196 The HIC is an instantiation of ACTN framework for IP packet network. 197 The IP domain (lower-level) controllers implements the PNC 198 functionalities for configuring, controlling and monitoring the IP 199 domain. The "super controller" (high-level controller) implements 200 the MDSC functionalities for coordination between multiple domains as 201 well as maintaining an abstracted view of multiple domains. It also 202 takes care of the service related functionalities of customer 203 mapping/translation and virtual service coordination. 205 The ACTN functions are part of the IP controllers and responsible for 206 the TE topology and E2E path computation/setup. There are other 207 functions along with ACTN that are needed to manage multiple IP 208 domain networks. 210 2.2. Interface between Super Controller and Domain Controller in HIC 212 The interaction between super controller and domain controller in HIC 213 is a combination of Control Plane and Management Plane interface as 214 shown in Figure 2. BGP [RFC4271] and PCEP [RFC5440] are example of 215 the control plane interface; where as NETCONF [RFC6241] and RESTCONF 216 [RFC8040] are example of management plane interface. 218 +----------------------------------------------+ 219 | Super Controller | 220 | | 221 | | 222 +------------------*------#---------------------+ 223 * # 224 * # 225 ************************* 226 * # * 227 ######*############### * 228 # * # * 229 +---------#-----*--+ +--#--------*------+ 230 | Domain | | Domain | 231 | Controller | | Controller | 232 +--#------------*--+ +--#------------*--+ 233 # * # * 234 # * # * 236 * -> Control Plane Interface 237 # -> Management Plane Interface 239 Figure 2: Interface between Super Controller and Domain Controller 241 Note that ACTN's MDSC-PNC Interface (MPI) could be implemented via 242 management plane interface using Yang models 243 [I-D.ietf-teas-actn-yang] or via PCEP control plane interface 244 [I-D.ietf-pce-applicability-actn]. 246 3. Key Concepts 248 3.1. Topology 250 The Domain Controller is expected to be aware of the topology of the 251 network devices in its domain. The domain controller could 252 participate in the IGP ([RFC3630] and [RFC5305]) or use BGP-LS 253 [RFC7752] by which link-state and TE information is collected and 254 shared with domain controller using the BGP routing protocol. 256 An alternate approach would be to rely on the management plane 257 interface which uses the YANG model for network/TE Topology as per 258 [RFC8345] and [I-D.ietf-teas-yang-te-topo]. 260 The domain controller is expected to share the domain topology to the 261 Super Controller as aligned to ACTN (where PNC abstract the topology 262 towards MDSC). A level of abstraction is usually applied while 263 presenting the topology to a higher level controller. Topology 264 abstraction is described in [RFC7926] as well as [RFC8453]. BGP-LS, 265 PCEP-LS [I-D.dhodylee-pce-pcep-ls] or management plane interface 266 based on the abstracted network/TE Topology could be used to carry 267 the abstract topology to the super-controller. At minimum the border 268 nodes and inter-domain links are exposed to the super-controller. 270 Further [RFC8453] defines three types of topology abstraction - (1) 271 Native/White Topology; (2) Black Topology; and (3) Grey Topology. 272 Based on the local policy, the domain controller would share the 273 domain topology to the Super Controller based on the abstraction 274 type. Note that any of the control plane or management plane 275 mechanism could be used to carry abstracted domain topology. The 276 Super Controller's MDSC function is expected to manage a E2E topology 277 by coordinating the abstracted domain topology received from the 278 domain controllers. 280 3.2. Path Computation/Path instantiation 282 The Domain Controller is responsible for computing and setup of path 283 when the source and destination is in the same domain, otherwise the 284 Super Controller coordinates the multi-domain path computation and 285 setup with the help of the domain controller. This is aligned to 286 ACTN. 288 PCEP [RFC5440] provides mechanisms for Path Computation Elements 289 (PCEs) [RFC4655] to perform path computations in response to Path 290 Computation Clients (PCCs) requests. Since then, the role and 291 function of the PCE has grown to allow delegated control [RFC8231] 292 and PCE-initiated use of network resources [RFC8281]. 294 Further, [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a 295 hierarchy of PCE with Parent PCE coordinating multi-domain path 296 computation function between Child PCE(s). This fits well with HIC 297 as described in this document. 299 Note that a management plane interface which uses the YANG model for 300 path computation/setup ([I-D.ietf-teas-yang-path-computation] and 301 [I-D.ietf-teas-yang-te]) could be used in place of PCEP. 303 In case there is a need to stitch per domain tunnels into an E2E 304 tunnel, mechanism are described in [I-D.lee-pce-lsp-stitching-hpce] 305 and [I-D.dugeon-pce-stateful-interdomain]. 307 3.3. BGP considerations 309 [RFC4456] describes the concept of route-reflection where a "route 310 reflector" (RR) reflects the routes to avoid full mesh connection 311 between Internal BGP (IBGP) peers. The IP domain controller can play 312 the role of RR in its domain. The super controller can further act 313 as RR to towards the domain controller. 315 BGP can provide routing policies for the traffic management, like 316 route preference, AS-path filter policy, IP-prefix filter policy and 317 route aggregation. The controller can distribute these BGP Policy 318 into the routers in a single IP domain. For the scenario of multiple 319 domains, the super controller can distribute per BGP Policy into each 320 IP domain controller. Then the IP domain controller trickles down 321 the BGP Policy to the network devices. 323 [RFC5575] describes the concept of BGP Flowspec that can be used to 324 distribute traffic flow specifications. A flow specification is an 325 n-tuple consisting of several matching criteria that can be applied 326 to IP traffic. The controller can originate the flow specifications 327 and disseminate to the routers. The flow action includes the 328 redirection to a specific TE tunnel. Also, the IP domain controller 329 could be responsible for collecting the flow sample in its domain and 330 the super controller can act as the Flow Analysis Server. 332 [RFC7854] describes the BGP Monitoring Protocol (BMP) to monitor BGP 333 sessions. BMP is used to obtain the route views with a flexible way. 334 In the fashion of hierarchical architecture, the IP domain controller 335 can be used as the domain Monitoring Station. Meanwhile, the super 336 controller is responsible for a high-level view of the global network 337 state. 339 4. VPN Service 341 4.1. Seamless MPLS 343 Seamless MPLS [I-D.ietf-mpls-seamless-mpls] describes an architecture 344 which can be used to extend MPLS networks to integrate access and 345 core/aggregation networks into a single MPLS domain.In the seamless 346 MPLS for mobile backhaul, since there are multiple domains including 347 the core network and multiple mobile backhaul networks, for each 348 domain there is a domain controller. In order to implement the end- 349 to-end network service provision, there should be coordination among 350 multiple domain controllers. 352 | 353 | 354 | 355 +----------+ 356 |--------------|Super |---------| 357 | |Controller| | 358 | +----------+ | 359 | | | 360 | | | 361 | | | 362 +------+ +------+ +------+ 363 |----|DoCo |----| |---|DoCo |--| |----|DoCo |---| 364 | |#X1 | | | |#Y | | | |#X2 | | 365 | +------+ | | +------+ | | +------+ | 366 | | | | | | 367 | | | | | | 368 | | | | | | 369 | +----+ +----+ | 370 | ....|ABR1|...........|ABR3|.... | 371 +----+ ..... +----+ +----+ ..... +----+ 372 | PE |... ...| PE | 373 +----+ ..... +----+ 374 ....+----+ +----+ ..... 375 |ABR2|...........|ABR4|.... 376 +----+ +----+ 378 | IGP-X1 | IGP-Y | IGP-X2 | 379 | (MBH) | (Core) | (MBH) | 380 | | | | 381 |-----BGP LSP-----|-----BGP LSP----|------BGP LSP-----| 382 | | | | 383 |---LDP/TE LSP----|----LDP/TE LSP--|-----LDP/TE LSP---| 384 | | | | 386 Figure 3: Seamless MPLS 388 Super Controller is responsible for setting the seamless MPLS 389 service. It should break down the service model to network 390 configuration model [RFC8309] and the domain controller further break 391 it to the device configuration model to the PE/ASBR to make the E2E 392 seamless MPLS service. The selection of appropriate ASBRs and 393 handling of intra-domain tunnels is coordinated by the Super 394 Controller in the similar fashion as shown in Section 4.2. 396 By enabling BGP sessions between Domain Controller and Super 397 Controller, BGP labeled routes can also be learned at Super 398 Controller. As Super Controller is aware of the (abstract) topology, 399 it could make intelligent decisions regarding E2E BGP LSP to optimize 400 based on the overall traffic information. 402 4.2. L3VPN 404 A Layer 3 IP VPN service is a collection of sites that are authorized 405 to exchange traffic between each other over a shared IP 406 infrastructure. [RFC4110] provides a framework for Layer 3 Provider- 407 Provisioned Virtual Private Networks (PPVPNs). [RFC8299] provides a 408 L3VPN service delivery YANG model for PE-based VPNs. The Super 409 controller is expected to implement the L3SM model and translate it 410 to network models towards the domain controller, which in turn 411 translate it to the device model. See [RFC8309] for more details. 413 | L3SM 414 V 415 +--------------------+ 416 | Super Controller | 417 +--------------------+ 418 | 419 +-------------------------------+ 420 | | 421 V V 422 +--------+ +--------+ 423 | DoCo#1 | | DoCo#2 | 424 | | | | 425 +--------+ +--------+ 427 CE CE 428 \ AS 100 AS 200 / 429 \ / 430 A----B----C----ASBR1------ASBR2----D----E----F 431 / / / / / / / / 432 / / / / / / / / 433 CE----G----H----I----ASBR3------ASBR4----J----K----L------CE 435 Figure 4: L3VPN 437 Based on the user data in L3SM model, the network configurations need 438 to be trickle down to the network device to setup the L3VPN. 440 Based on the QoS or Policy requirement for the L3VPN service, the 441 Super Controller may - 443 o Set the tunnel selection policy at the PE/ASBR routers so that 444 they could select the existing tunnels 446 o Select an existing tunnels at the controller level and bind it to 447 the VPN service 449 o Initiate the process of creating a new tunnel based on the QoS 450 requirement and bind it the VPN service 452 o Initiate the process of creating a new tunnel based on the the 453 policy 455 Refer [I-D.lee-teas-te-service-mapping-yang] for more details from 456 ACTN perspective. 458 Apart from the Management plane interface based on respective YANG 459 models, the control plane interface PCEP could be used for path 460 computation and setup. 462 4.3. L2VPN and EVPN service 464 There are two fundamentally different kinds of Layer 2 VPN service 465 that a service provider could offer to a customer: Virtual Private 466 Wire Service (VPWS) and Virtual Private LAN Service (VPLS) [RFC4664]. 467 A VPWS is a VPN service that supplies an L2 point-to-point service. 468 A VPLS is an L2 service that emulates LAN service across a Wide Area 469 Network (WAN). A BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] 470 addresses some of the limitations when it comes to multihoming and 471 redundancy, multicast optimization, provisioning simplicity, flow- 472 based load balancing, and multipathing etc. 474 The handling of L2VPN/EVPN service is done in a similar fashion as 475 shown in Section 4.2. 477 5. Possible Features/Extensions 479 This sections list some of the possible features or protocol 480 extensions that could be worked on to deploy HIC in a multi-domain 481 packet network. 483 1. Simplify the initial configurations needed to setup the 484 relationship between the super controller and the domain 485 controllers. Note that this could be done via exchanges during 486 initial session establishment, discovery via other protocols, 487 service discovery (such as DNS) etc. 489 2. The (higher-level controller, lower-level controller) 490 relationship or the the role of the controller. 492 3. The learning and handling of various capabilities of the Super 493 Controller and Domain Controller. 495 4. Handling of multiple instances of controller at each level for 496 high availability. 498 [Editor's Note - This list is expected to be updated in next version 499 with more details] 501 6. Other Considerations 503 6.1. Control Plane 505 6.1.1. PCE / PCEP 507 The Path Computation Element communication Protocol (PCEP) [RFC5440] 508 provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to 509 perform path computations in response to Path Computation Clients 510 (PCCs) requests. 512 The ability to compute shortest constrained TE LSPs in Multiprotocol 513 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 514 multiple domains has been identified as a key motivation for PCE 515 development. 517 A stateful PCE [RFC8231] is capable of considering, for the purposes 518 of path computation, not only the network state in terms of links and 519 nodes (referred to as the Traffic Engineering Database or TED) but 520 also the status of active services (previously computed paths, and 521 currently reserved resources, stored in the Label Switched Paths 522 Database (LSPDB). 524 [RFC8051] describes general considerations for a stateful PCE 525 deployment and examines its applicability and benefits, as well as 526 its challenges and limitations through a number of use cases. 528 [RFC8231] describes a set of extensions to PCEP to provide stateful 529 control. A stateful PCE has access to not only the information 530 carried by the network's Interior Gateway Protocol (IGP), but also 531 the set of active paths and their reserved resources for its 532 computations. The additional state allows the PCE to compute 533 constrained paths while considering individual LSPs and their 534 interactions. [RFC8281] describes the setup, maintenance and 535 teardown of PCE-initiated LSPs under the stateful PCE model. 537 [RFC8231] also describes the active stateful PCE. The active PCE 538 functionality allows a PCE to reroute an existing LSP or make changes 539 to the attributes of an existing LSP, or a PCC to delegate control of 540 specific LSPs to a new PCE. 542 Computing paths across large multi-domain environments require 543 special computational components and cooperation between entities in 544 different domains capable of complex path computation. The PCE 545 provides an architecture and a set of functional components to 546 address this problem space. A PCE may be used to compute end-to-end 547 paths across multi-domain environments using a per-domain path 548 computation technique [RFC5152]. The Backward recursive PCE based 549 path computation (BRPC) mechanism [RFC5441] defines a PCE-based path 550 computation procedure to compute inter-domain constrained MPLS and 551 GMPLS TE networks. However, both per-domain and BRPC techniques 552 assume that the sequence of domains to be crossed from source to 553 destination is known, either fixed by the network operator or 554 obtained by other means. 556 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 557 be used for computing end-to-end paths for inter-domain MPLS Traffic 558 Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the 559 domain sequence is not known. Within the Hierarchical PCE (H-PCE) 560 architecture, the Parent PCE (P-PCE) is used to compute a multi- 561 domain path based on the domain connectivity information. A Child 562 PCE (C-PCE) may be responsible for a single domain or multiple 563 domains, it is used to compute the intra-domain path based on its 564 domain topology information. 566 [I-D.ietf-pce-stateful-hpce] state the considerations for stateful 567 PCE(s) in hierarchical PCE architecture. In particular, the behavior 568 changes and additions to the existing stateful PCE mechanisms 569 (including PCE- initiated LSP setup and active PCE usage) in the 570 context of networks using the H-PCE architecture. 572 [I-D.ietf-pce-applicability-actn] examines the applicability of PCE/ 573 PCEP to the ACTN framework in detail. 575 6.1.2. BGP 577 [RFC7752] describes a mechanism by which link-state and TE 578 information can be collected from networks and shared with external 579 components using the BGP routing protocol. This is achieved using a 580 new BGP Network Layer Reachability Information (NLRI) encoding format 581 and a new BGP path attribute (BGP-LS attribute) that carries link, 582 node, and prefix parameters and attributes. 584 BGP-LS is a new approach to collect the network topology information. 585 It is an extension to BGP for distribution the network's link-state 586 (LS) topology to external entities, such as the SDN controller. 587 Network's link-state topology consists of nodes and links and a set 588 of attributes. The link-state topology is distributed among the IGP 589 domain. The specific protocol used in an IGP domain could be OSPF 591 [RFC2238] or IS-IS [ISO10589]. Note that, the detailed link-state 592 models of these two protocols are not identical. Therefore, BGP-LS 593 can provide a more abstract topology model which can map the IGP 594 models. 596 The domain controller acts as a consumer to collect the domain's 597 link-state and TE information via BGP-LS. The domain controller 598 would usually abstract the domain information towards the super- 599 controller and further send it via BGP-LS. 601 BGP-Flowspec is a solution devised for preventing distributed Denial- 602 of-service (DDoS) attack. BGP-Flowspec distributes specification 603 rules into neighbors. [RFC5575] defines a new BGP NLRI encoding 604 format that can be used to distribute traffic flow specifications. 605 Additionally, it defines two applications of that encoding format: 606 one that can be used to automate inter-domain coordination of traffic 607 filtering, such as what is required in order to mitigate DDoS 608 attacks; and a second application to provide traffic filtering in the 609 context of BGP/MPLS VPN service. 611 The IP domain controller can act as the traffic sampling node. The 612 super controller can act as the traffic analysis server. When the 613 super controller finds the attack happened, the super controller 614 should distribute the flow rules to associated IP domain controllers. 615 And each IP domain controller should distribute the flow rules into 616 the ingress routers. Additionally one of the actions taken could be 617 "redirect" where flow could be redirected to the TE tunnels created 618 by the controller. 620 [I-D.luo-grow-bgp-controller-based-ts] describes the traffic steering 621 based on BGP controller. The traditional method for traffic steering 622 depends on static configuration which is time consuming and 623 inefficient. With the hierarchical IP controller, the IP domain 624 controller can have the domain network topology view and routing 625 information while the super controller can have the global network 626 topology view and routing information. The super controller can 627 compute the end-to-end paths to satisfy the differentiated service 628 requirement. The IP domain controller may be used to distribute the 629 routing policy into the routers. BGP policy varies in many aspects. 630 Its goal is to meet the customer application and connectivity 631 requirement, and specific service transport needs. So the super BGP 632 controller is responsible for the coordination of multiple domain BGP 633 Policy. And then distribute Policy to related IP domain controller. 634 The IP domain controller is responsible for distributing the policy 635 to its network nodes. 637 [I-D.ietf-idr-rtc-hierarchical-rr] describes the route target (RT) 638 constrain mechanism in the hierarchical route reflection (RR) 639 scenario. [RFC4684] describes the route target constrain mechanism 640 to build a route distribution graph in order to restrict the 641 propagation of Virtual Private Network (VPN) routes. 642 [I-D.ietf-idr-rtc-hierarchical-rr] proposes a solution to address the 643 RT constrain issue in the hierarchical RR scenarios. The super 644 controller corresponding to higher level RR can receive the RT- 645 constrain routes from the lower level RR, which is acted by the IP 646 domain controller. The higher level RR will select one of the 647 received routes as the best route. then it should advertise the best 648 route to all the lower level RR to build the route distribution 649 graph. This fits well with the HIC as described in this document. 651 6.2. Management Plane 653 6.2.1. YANG Models 655 This is an non-exhaustive list of possible yang models developed or 656 in-development that could be used for HIC. 658 Topology: [RFC8345] defines a generic YANG data model for network 659 topology. [I-D.ietf-teas-yang-te-topo] defines a YANG data model 660 for representing, retrieving and manipulating Traffic Engineering 661 (TE) Topologies. 663 Tunnel: [I-D.ietf-teas-yang-te] defines a YANG data model for the 664 configuration and management of Traffic Engineering (TE) 665 interfaces, tunnels and Label Switched Paths (LSPs). 667 L3VPN: The Layer 3 service model (L3SM) is defined in [RFC8299], 668 which is a YANG data model that can be used for communication 669 between customers and network operators and to deliver a Layer 3 670 provider-provisioned VPN service. [I-D.ietf-bess-l3vpn-yang] 671 defines a YANG data model that can be used to configure and manage 672 BGP Layer 3 VPNs at the device. Note that a network configuration 673 model at the Domain Controller level needs to be developed. 675 L2VPN/EVPN: [I-D.ietf-l2sm-l2vpn-service-model] defines a YANG 676 data model that can be used to configure a Layer 2 Provider 677 Provisioned VPN service. This model is intended to be 678 instantiated at management system to deliver the overall service. 679 [I-D.ietf-bess-l2vpn-yang] and [I-D.ietf-bess-evpn-yang] defines a 680 YANG data model to configure and manage L2VPN and EVPN service 681 respectively. Note that a network configuration model at the 682 Domain Controller level needs to be developed. 684 OAM: TBD 685 BGP Policy: [I-D.ietf-idr-bgp-model] defines a YANG data model 686 that can be used to configure BGP Policy based on data center, 687 carrier and content provider operational requirements. The model 688 is intended to be vendor-neutral, in order to allow operators to 689 manage BGP configuration in heterogeneous environments with 690 routers supplied by multiple vendors. Note that a network 691 configuration model at the Domain Controller level needs to be 692 developed. 694 BGP Flowspec: [I-D.wu-idr-flowspec-yang-cfg] defines a YANG data 695 model for Flow Specification implementations. The configuration 696 data is described as flow specification rules that can be 697 distributed as BGP NLRI to a network element. The rules can be 698 used to filter Distributed Denial of Service attacks (DDoS) 699 besides other use cases. Note that a network configuration model 700 at the Domain Controller level needs to be developed. 702 [Editor's Note - the above list should be extended.] 704 6.2.2. Protocol Considerations 706 The Network Configuration Protocol (NETCONF) [RFC6241] provides 707 mechanisms to install, manipulate, and delete the configuration of 708 network devices. The RESTCONF [RFC8040] describes an HTTP-based 709 protocol that provides a programmatic interface for accessing data 710 defined in YANG, using the data-store concepts defined in NETCONF. 712 Some other mechanism like gRPC/gNMI could also be used between 713 controllers using the same YANG data models. 715 7. IANA Considerations 717 There are no IANA concerns in this document. 719 8. Security Considerations 721 There are no new security concerns in this document. 723 9. Acknowledgments 725 10. Contributing Authors 727 Dailongfei (Larry) 728 Huawei Technologies, 729 Beijing, China 731 Email: larry.dai@huawei.com 733 11. References 735 11.1. Normative References 737 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 738 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 739 DOI 10.17487/RFC8453, August 2018, 740 . 742 11.2. Informative References 744 [RFC2238] Clouston, B., Ed. and B. Moore, Ed., "Definitions of 745 Managed Objects for HPR using SMIv2", RFC 2238, 746 DOI 10.17487/RFC2238, November 1997, 747 . 749 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 750 (TE) Extensions to OSPF Version 2", RFC 3630, 751 DOI 10.17487/RFC3630, September 2003, 752 . 754 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 755 Provider-Provisioned Virtual Private Networks (PPVPNs)", 756 RFC 4110, DOI 10.17487/RFC4110, July 2005, 757 . 759 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 760 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 761 DOI 10.17487/RFC4271, January 2006, 762 . 764 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 765 Reflection: An Alternative to Full Mesh Internal BGP 766 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 767 . 769 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 770 Element (PCE)-Based Architecture", RFC 4655, 771 DOI 10.17487/RFC4655, August 2006, 772 . 774 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 775 2 Virtual Private Networks (L2VPNs)", RFC 4664, 776 DOI 10.17487/RFC4664, September 2006, 777 . 779 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 780 R., Patel, K., and J. Guichard, "Constrained Route 781 Distribution for Border Gateway Protocol/MultiProtocol 782 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 783 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 784 November 2006, . 786 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 787 Per-Domain Path Computation Method for Establishing Inter- 788 Domain Traffic Engineering (TE) Label Switched Paths 789 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 790 . 792 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 793 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 794 2008, . 796 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 797 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 798 DOI 10.17487/RFC5440, March 2009, 799 . 801 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 802 "A Backward-Recursive PCE-Based Computation (BRPC) 803 Procedure to Compute Shortest Constrained Inter-Domain 804 Traffic Engineering Label Switched Paths", RFC 5441, 805 DOI 10.17487/RFC5441, April 2009, 806 . 808 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 809 and D. McPherson, "Dissemination of Flow Specification 810 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 811 . 813 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 814 and A. Bierman, Ed., "Network Configuration Protocol 815 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 816 . 818 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 819 Path Computation Element Architecture to the Determination 820 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 821 DOI 10.17487/RFC6805, November 2012, 822 . 824 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 825 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 826 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 827 2015, . 829 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 830 Application-Based Network Operations", RFC 7491, 831 DOI 10.17487/RFC7491, March 2015, 832 . 834 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 835 S. Ray, "North-Bound Distribution of Link-State and 836 Traffic Engineering (TE) Information Using BGP", RFC 7752, 837 DOI 10.17487/RFC7752, March 2016, 838 . 840 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 841 Monitoring Protocol (BMP)", RFC 7854, 842 DOI 10.17487/RFC7854, June 2016, 843 . 845 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 846 Ceccarelli, D., and X. Zhang, "Problem Statement and 847 Architecture for Information Exchange between 848 Interconnected Traffic-Engineered Networks", BCP 206, 849 RFC 7926, DOI 10.17487/RFC7926, July 2016, 850 . 852 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 853 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 854 . 856 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 857 Stateful Path Computation Element (PCE)", RFC 8051, 858 DOI 10.17487/RFC8051, January 2017, 859 . 861 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 862 Computation Element Communication Protocol (PCEP) 863 Extensions for Stateful PCE", RFC 8231, 864 DOI 10.17487/RFC8231, September 2017, 865 . 867 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 868 Computation Element Communication Protocol (PCEP) 869 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 870 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 871 . 873 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 874 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 875 DOI 10.17487/RFC8299, January 2018, 876 . 878 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 879 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 880 . 882 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 883 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 884 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 885 2018, . 887 [I-D.ietf-teas-actn-yang] 888 Lee, Y., zhenghaomian@huawei.com, z., Ceccarelli, D., 889 Yoon, B., Dios, O., Shin, J., and S. Belotti, 890 "Applicability of YANG models for Abstraction and Control 891 of Traffic Engineered Networks", draft-ietf-teas-actn- 892 yang-02 (work in progress), August 2018. 894 [I-D.ietf-pce-applicability-actn] 895 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 896 Path Computation Element (PCE) for Abstraction and Control 897 of TE Networks (ACTN)", draft-ietf-pce-applicability- 898 actn-06 (work in progress), June 2018. 900 [I-D.ietf-teas-yang-te] 901 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and 902 I. Bryskin, "A YANG Data Model for Traffic Engineering 903 Tunnels and Interfaces", draft-ietf-teas-yang-te-16 (work 904 in progress), July 2018. 906 [I-D.ietf-teas-yang-te-topo] 907 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 908 O. Dios, "YANG Data Model for Traffic Engineering (TE) 909 Topologies", draft-ietf-teas-yang-te-topo-18 (work in 910 progress), June 2018. 912 [I-D.ietf-pce-stateful-hpce] 913 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 914 and O. Dios, "Hierarchical Stateful Path Computation 915 Element (PCE).", draft-ietf-pce-stateful-hpce-05 (work in 916 progress), June 2018. 918 [I-D.ietf-teas-yang-path-computation] 919 Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, 920 A., Shi, Y., Vilata, R., and K. Sethuraman, "Yang model 921 for requesting Path Computation", draft-ietf-teas-yang- 922 path-computation-02 (work in progress), June 2018. 924 [I-D.ietf-mpls-seamless-mpls] 925 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 926 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 927 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 929 [I-D.ietf-bess-evpn-yang] 930 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 931 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 932 bess-evpn-yang-05 (work in progress), February 2018. 934 [I-D.ietf-bess-l2vpn-yang] 935 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 936 and K. Tiruveedhula, "YANG Data Model for MPLS-based 937 L2VPN", draft-ietf-bess-l2vpn-yang-08 (work in progress), 938 February 2018. 940 [I-D.ietf-bess-l3vpn-yang] 941 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 942 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 943 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-03 (work 944 in progress), April 2018. 946 [I-D.ietf-l2sm-l2vpn-service-model] 947 Wen, B., Fioccola, G., Xie, C., and L. Jalil, "A YANG Data 948 Model for L2VPN Service Delivery", draft-ietf-l2sm-l2vpn- 949 service-model-10 (work in progress), April 2018. 951 [I-D.dhodylee-pce-pcep-ls] 952 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 953 Distribution of Link-State and TE Information.", draft- 954 dhodylee-pce-pcep-ls-11 (work in progress), June 2018. 956 [I-D.lee-teas-te-service-mapping-yang] 957 Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J., 958 Fioccola, G., and Q. Wu, "Traffic Engineering and Service 959 Mapping Yang Model", draft-lee-teas-te-service-mapping- 960 yang-10 (work in progress), August 2018. 962 [I-D.lee-pce-lsp-stitching-hpce] 963 Lee, Y., Dhody, D., and D. Ceccarelli, "PCEP Extensions 964 for Stitching LSPs in Hierarchical Stateful PCE Model", 965 draft-lee-pce-lsp-stitching-hpce-01 (work in progress), 966 December 2017. 968 [I-D.dugeon-pce-stateful-interdomain] 969 Dugeon, O., Meuric, J., Lee, Y., Dhody, D., and D. 970 Ceccarelli, "PCEP Extension for Stateful Inter-Domain 971 Tunnels", draft-dugeon-pce-stateful-interdomain-01 (work 972 in progress), July 2018. 974 [I-D.luo-grow-bgp-controller-based-ts] 975 Luo, Y., Ou, L., Huang, X., Zhuang, S., and Z. Li, 976 "Traffic Steering Based on BGP Controller", draft-luo- 977 grow-bgp-controller-based-ts-00 (work in progress), March 978 2018. 980 [I-D.ietf-idr-rtc-hierarchical-rr] 981 Dong, J., Chen, M., and R. Raszuk, "Extensions to RT- 982 Constrain in Hierarchical Route Reflection Scenarios", 983 draft-ietf-idr-rtc-hierarchical-rr-03 (work in progress), 984 July 2017. 986 [I-D.ietf-idr-bgp-model] 987 Patel, K., Jethanandani, M., and S. Hares, "BGP Model for 988 Service Provider Networks", draft-ietf-idr-bgp-model-03 989 (work in progress), May 2018. 991 [I-D.wu-idr-flowspec-yang-cfg] 992 Wu, N., Zhuang, S., and A. Choudhary, "A YANG Data Model 993 for Flow Specification", draft-wu-idr-flowspec-yang-cfg-02 994 (work in progress), October 2015. 996 [ISO10589] 997 ISO, "Intermediate system to Intermediate system routing 998 information exchange protocol for use in conjunction with 999 the Protocol for providing the Connectionless-mode Network 1000 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 1002 Authors' Addresses 1003 Zhenbin Li 1004 Huawei Technologies 1005 Huawei Bld., No.156 Beiqing Rd. 1006 Beijing 100095 1007 China 1009 EMail: lizhenbin@huawei.com 1011 Dhruv Dhody 1012 Huawei Technologies 1013 Divyashree Techno Park, Whitefield 1014 Bangalore, Karnataka 560066 1015 India 1017 EMail: dhruv.ietf@gmail.com 1019 Huaimo Chen 1020 Huawei Technologies 1021 Boston, MA 1022 USA 1024 EMail: huaimo.chen@huawei.com