idnits 2.17.1 draft-li-teas-hierarchy-ip-controllers-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 date (March 5, 2019) is 1872 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-03 == Outdated reference: A later version (-12) exists of draft-ietf-pce-applicability-actn-08 == Outdated reference: A later version (-36) exists of draft-ietf-teas-yang-te-19 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-19 == Outdated reference: A later version (-15) exists of draft-ietf-pce-stateful-hpce-06 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-path-computation-04 == Outdated reference: A later version (-07) exists of draft-ietf-bess-evpn-yang-06 == Outdated reference: A later version (-10) exists of draft-ietf-bess-l2vpn-yang-09 == Outdated reference: A later version (-05) exists of draft-ietf-bess-l3vpn-yang-04 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-13 == Outdated reference: A later version (-04) exists of draft-dugeon-pce-stateful-interdomain-02 == 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-04 Summary: 0 errors (**), 0 flaws (~~), 14 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: September 6, 2019 Huawei Technologies 6 March 5, 2019 8 Hierarchy of IP Controllers (HIC) 9 draft-li-teas-hierarchy-ip-controllers-02 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 September 6, 2019. 40 Copyright Notice 42 Copyright (c) 2019 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 tunnelling mechanism (eg RSVP-TE, Segment Routing (SR) 119 etc). 121 [RFC8453] describes the framework for Abstraction and Control of 122 Traffic Engineered Networks (ACTN) as well as a set of management and 123 control functions used to operate multiple TE networks. This 124 documents would apply the ACTN principles to Hierarchy of IP 125 controllers (HIC) and focus on the applicability and interactions 126 with other protocol and technologies (specific to IP packet domains). 128 Sometimes, service (such as Layer 3 Virtual Private Network (L3VPN), 129 Layer 2 Virtual Private Network (L2VPN), Ethernet VPN (EVPN), 130 Seamless MPLS) require sites attached to different domains (under the 131 control of different domain controller) to be interconnected as part 132 of the VPN service. This require multi-domain coordination between 133 domain controllers to compute and set-up E2E path for the VPN 134 service. 136 This document describes the interactions between various IP 137 controllers in a hierarchical fashion to provide various IP services. 138 It describes how the Abstraction and Control of Traffic Engineered 139 Networks (ACTN) framework is applied to the Hierarchy of IP 140 controllers (HIC) as well as document the interactions with control 141 plane protocols (like BGP, Path Computation Element Communication 142 Protocol (PCEP)) and management plane aspects (Yang models) to 143 provide end to end dynamic services spanning multiple domains and 144 controllers (e.g. L3VPN, Seamless MPLS etc.). 146 2. Overview 148 Figure 1 show examples of multi-domain IP domains under hierarchy of 149 IP controllers. 151 | 152 +------------+ 153 | SuperCo | 154 +------------+ 155 | 156 ---------------------------------- 157 | | | 158 +------------+ +------------+ +------------+ 159 | DoCo#1 | | DoCo#2 | | DoCo#3 | 160 +------------+ +------------+ +------------+ 162 +--Domain#1--+ +--Domain#2--+ +--Domain#3--+ 163 | | | | | | 164 | B------+---+---D-----E--+---+------J | 165 | / | | \ / | | \ | 166 | / | | \ / | | \ | 167 | A | | H | | L | 168 | \ | | / \ | | / | 169 | \ | | / \ | | / | 170 | C------+---+---F-----G--+---+------K | 171 | | | | | | 172 +------------+ +------------+ +------------+ 174 Figure 1: Example: Hierarchy of IP controllers (HIC) 176 The IP "Super Controller" receives request from the network/service 177 orchestrator to set-up dynamic services spanning multiple domains. 178 The IP "Super Controller" breaks down and assigns tasks to the domain 179 controllers, responsible for communicating to network devices in the 180 domain. It further coordinates between the controller to provide a 181 unified view of the multi-domain network. 183 2.1. Mapping to ACTN 185 As per [RFC8453], ACTN has following main functions - 187 o Multi-domain coordination 189 o Virtualization/Abstraction 190 o Customer mapping/translation 192 o Virtual service coordination 194 These functions are part of Multi Domain Service Coordinator (MDSC) 195 and/or Provisioning Network Controller (PNC). Further these 196 functions are part of the controller / orchestrator. 198 The HIC is an instantiation of ACTN framework for IP packet network. 199 The IP domain (lower-level) controllers implements the PNC 200 functionalities for configuring, controlling and monitoring the IP 201 domain. The "super controller" (high-level controller) implements 202 the MDSC functionalities for coordination between multiple domains as 203 well as maintaining an abstracted view of multiple domains. It also 204 takes care of the service related functionalities of customer 205 mapping/translation and virtual service coordination. 207 The ACTN functions are part of the IP controllers and responsible for 208 the TE topology and E2E path computation/set-up. There are other 209 functions along with ACTN that are needed to manage multiple IP 210 domain networks. 212 2.2. Interface between Super Controller and Domain Controller in HIC 214 The interaction between super controller and domain controller in HIC 215 is a combination of Control Plane and Management Plane interface as 216 shown in Figure 2. BGP [RFC4271] and PCEP [RFC5440] are example of 217 the control plane interface; where as NETCONF [RFC6241] and RESTCONF 218 [RFC8040] are example of management plane interface. 220 +----------------------------------------------+ 221 | Super Controller | 222 | | 223 | | 224 +------------------*------#---------------------+ 225 * # 226 * # 227 ************************* 228 * # * 229 ######*############### * 230 # * # * 231 +---------#-----*--+ +--#--------*------+ 232 | Domain | | Domain | 233 | Controller | | Controller | 234 +--#------------*--+ +--#------------*--+ 235 # * # * 236 # * # * 238 * -> Control Plane Interface 239 # -> Management Plane Interface 241 Figure 2: Interface between Super Controller and Domain Controller 243 Note that ACTN's MDSC-PNC Interface (MPI) could be implemented via 244 management plane interface using Yang models 245 [I-D.ietf-teas-actn-yang] or via PCEP control plane interface 246 [I-D.ietf-pce-applicability-actn]. 248 3. Key Concepts 250 3.1. Topology 252 The Domain Controller is expected to be aware of the topology of the 253 network devices in its domain. The domain controller could 254 participate in the IGP ([RFC3630] and [RFC5305]) or use BGP-LS 255 [RFC7752] by which link-state and TE information is collected and 256 shared with domain controller using the BGP routing protocol. 258 An alternate approach would be to rely on the management plane 259 interface which uses the YANG model for network/TE Topology as per 260 [RFC8345] and [I-D.ietf-teas-yang-te-topo]. 262 The domain controller is expected to share the domain topology to the 263 Super Controller as aligned to ACTN (where PNC abstract the topology 264 towards MDSC). A level of abstraction is usually applied while 265 presenting the topology to a higher level controller. Topology 266 abstraction is described in [RFC7926] as well as [RFC8453]. BGP-LS, 267 PCEP-LS [I-D.dhodylee-pce-pcep-ls] or management plane interface 268 based on the abstracted network/TE Topology could be used to carry 269 the abstract topology to the super-controller. At minimum the border 270 nodes and inter-domain links are exposed to the super-controller. 272 Further [RFC8453] defines three types of topology abstraction - (1) 273 Native/White Topology; (2) Black Topology; and (3) Grey Topology. 274 Based on the local policy, the domain controller would share the 275 domain topology to the Super Controller based on the abstraction 276 type. Note that any of the control plane or management plane 277 mechanism could be used to carry abstracted domain topology. The 278 Super Controller's MDSC function is expected to manage a E2E topology 279 by coordinating the abstracted domain topology received from the 280 domain controllers. 282 3.2. Path Computation/Path instantiation 284 The Domain Controller is responsible for computing and setup of path 285 when the source and destination is in the same domain, otherwise the 286 Super Controller coordinates the multi-domain path computation and 287 setup with the help of the domain controller. This is aligned to 288 ACTN. 290 PCEP [RFC5440] provides mechanisms for Path Computation Elements 291 (PCEs) [RFC4655] to perform path computations in response to Path 292 Computation Clients (PCCs) requests. Since then, the role and 293 function of the PCE has grown to allow delegated control [RFC8231] 294 and PCE-initiated use of network resources [RFC8281]. 296 Further, [RFC6805] and [I-D.ietf-pce-stateful-hpce] describes a 297 hierarchy of PCE with Parent PCE coordinating multi-domain path 298 computation function between Child PCE(s). This fits well with HIC 299 as described in this document. 301 Note that a management plane interface which uses the YANG model for 302 path computation/setup ([I-D.ietf-teas-yang-path-computation] and 303 [I-D.ietf-teas-yang-te]) could be used in place of PCEP. 305 In case there is a need to stitch per domain tunnels into an E2E 306 tunnel, mechanism are described in 307 [I-D.dugeon-pce-stateful-interdomain]. 309 3.3. BGP considerations 311 [RFC4456] describes the concept of route-reflection where a "route 312 reflector" (RR) reflects the routes to avoid full mesh connection 313 between Internal BGP (IBGP) peers. The IP domain controller can play 314 the role of RR in its domain. The super controller can further act 315 as RR to towards the domain controller. 317 BGP can provide routing policies for the traffic management, like 318 route preference, AS-path filter policy, IP-prefix filter policy and 319 route aggregation. The controller can distribute these BGP Policy 320 into the routers in a single IP domain. For the scenario of multiple 321 domains, the super controller can distribute per BGP Policy into each 322 IP domain controller. Then the IP domain controller trickles down 323 the BGP Policy to the network devices. 325 [RFC5575] describes the concept of BGP Flowspec that can be used to 326 distribute traffic flow specifications. A flow specification is an 327 n-tuple consisting of several matching criteria that can be applied 328 to IP traffic. The controller can originate the flow specifications 329 and disseminate to the routers. The flow action includes the 330 redirection to a specific TE tunnel. Also, the IP domain controller 331 could be responsible for collecting the flow sample in its domain and 332 the super controller can act as the Flow Analysis Server. 334 [RFC7854] describes the BGP Monitoring Protocol (BMP) to monitor BGP 335 sessions. BMP is used to obtain the route views with a flexible way. 336 In the fashion of hierarchical architecture, the IP domain controller 337 can be used as the domain Monitoring Station. Meanwhile, the super 338 controller is responsible for a high-level view of the global network 339 state. 341 4. VPN Service 343 4.1. Seamless MPLS 345 Seamless MPLS [I-D.ietf-mpls-seamless-mpls] describes an architecture 346 which can be used to extend MPLS networks to integrate access and 347 core/aggregation networks into a single MPLS domain.In the seamless 348 MPLS for mobile backhaul, since there are multiple domains including 349 the core network and multiple mobile backhaul networks, for each 350 domain there is a domain controller. In order to implement the end- 351 to-end network service provision, there should be coordination among 352 multiple domain controllers. 354 | 355 | 356 | 357 +----------+ 358 |--------------|Super |---------| 359 | |Controller| | 360 | +----------+ | 361 | | | 362 | | | 363 | | | 364 +------+ +------+ +------+ 365 |----|DoCo |----| |---|DoCo |--| |----|DoCo |---| 366 | |#X1 | | | |#Y | | | |#X2 | | 367 | +------+ | | +------+ | | +------+ | 368 | | | | | | 369 | | | | | | 370 | | | | | | 371 | +----+ +----+ | 372 | ....|ABR1|...........|ABR3|.... | 373 +----+ ..... +----+ +----+ ..... +----+ 374 | PE |... ...| PE | 375 +----+ ..... +----+ 376 ....+----+ +----+ ..... 377 |ABR2|...........|ABR4|.... 378 +----+ +----+ 380 | IGP-X1 | IGP-Y | IGP-X2 | 381 | (MBH) | (Core) | (MBH) | 382 | | | | 383 |-----BGP LSP-----|-----BGP LSP----|------BGP LSP-----| 384 | | | | 385 |---LDP/TE LSP----|----LDP/TE LSP--|-----LDP/TE LSP---| 386 | | | | 388 Figure 3: Seamless MPLS 390 Super Controller is responsible for setting the seamless MPLS 391 service. It should break down the service model to network 392 configuration model [RFC8309] and the domain controller further break 393 it to the device configuration model to the PE/ASBR to make the E2E 394 seamless MPLS service. The selection of appropriate ASBRs and 395 handling of intra-domain tunnels is coordinated by the Super 396 Controller in the similar fashion as shown in Section 4.2. 398 By enabling BGP sessions between Domain Controller and Super 399 Controller, BGP labeled routes can also be learned at Super 400 Controller. As Super Controller is aware of the (abstract) topology, 401 it could make intelligent decisions regarding E2E BGP LSP to optimize 402 based on the overall traffic information. 404 4.2. L3VPN 406 A Layer 3 IP VPN service is a collection of sites that are authorized 407 to exchange traffic between each other over a shared IP 408 infrastructure. [RFC4110] provides a framework for Layer 3 Provider- 409 Provisioned Virtual Private Networks (PPVPNs). [RFC8299] provides a 410 L3VPN service delivery YANG model for PE-based VPNs. The Super 411 controller is expected to implement the L3SM model and translate it 412 to network models towards the domain controller, which in turn 413 translate it to the device model. See [RFC8309] for more details. 415 | L3SM 416 V 417 +--------------------+ 418 | Super Controller | 419 +--------------------+ 420 | 421 +-------------------------------+ 422 | | 423 V V 424 +--------+ +--------+ 425 | DoCo#1 | | DoCo#2 | 426 | | | | 427 +--------+ +--------+ 429 CE CE 430 \ AS 100 AS 200 / 431 \ / 432 A----B----C----ASBR1------ASBR2----D----E----F 433 / / / / / / / / 434 / / / / / / / / 435 CE----G----H----I----ASBR3------ASBR4----J----K----L------CE 437 Figure 4: L3VPN 439 Based on the user data in L3SM model, the network configurations need 440 to be trickle down to the network device to setup the L3VPN. 442 Based on the QoS or Policy requirement for the L3VPN service, the 443 Super Controller may - 445 o Set the tunnel selection policy at the PE/ASBR routers so that 446 they could select the existing tunnels 448 o Select an existing tunnels at the controller level and bind it to 449 the VPN service 451 o Initiate the process of creating a new tunnel based on the QoS 452 requirement and bind it the VPN service 454 o Initiate the process of creating a new tunnel based on the the 455 policy 457 Refer [I-D.lee-teas-te-service-mapping-yang] for more details from 458 ACTN perspective. 460 Apart from the Management plane interface based on respective YANG 461 models, the control plane interface PCEP could be used for path 462 computation and setup. 464 4.3. L2VPN and EVPN service 466 There are two fundamentally different kinds of Layer 2 VPN service 467 that a service provider could offer to a customer: Virtual Private 468 Wire Service (VPWS) and Virtual Private LAN Service (VPLS) [RFC4664]. 469 A VPWS is a VPN service that supplies an L2 point-to-point service. 470 A VPLS is an L2 service that emulates LAN service across a Wide Area 471 Network (WAN). A BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] 472 addresses some of the limitations when it comes to multihoming and 473 redundancy, multicast optimization, provisioning simplicity, flow- 474 based load balancing, and multipathing etc. 476 The handling of L2VPN/EVPN service is done in a similar fashion as 477 shown in Section 4.2. 479 5. Possible Features/Extensions 481 This sections list some of the possible features or protocol 482 extensions that could be worked on to deploy HIC in a multi-domain 483 packet network. 485 1. Simplify the initial configurations needed to set-up the 486 relationship between the super controller and the domain 487 controllers. Note that this could be done via exchanges during 488 initial session establishment, discovery via other protocols, 489 service discovery (such as DNS etc.). 491 2. The (higher-level controller, lower-level controller) 492 relationship or the the role of the controller. 494 3. The learning and handling of various capabilities of the Super 495 Controller and Domain Controller. 497 4. Handling of multiple instances of controller at each level for 498 high availability. 500 [Editor's Note - This list is expected to be updated in next version 501 with more details] 503 6. Other Considerations 505 6.1. Control Plane 507 6.1.1. PCE / PCEP 509 The Path Computation Element communication Protocol (PCEP) [RFC5440] 510 provides mechanisms for Path Computation Elements (PCEs) [RFC4655] to 511 perform path computations in response to Path Computation Clients 512 (PCCs) requests. 514 The ability to compute shortest constrained TE LSPs in Multiprotocol 515 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across 516 multiple domains has been identified as a key motivation for PCE 517 development. 519 A stateful PCE [RFC8231] is capable of considering, for the purposes 520 of path computation, not only the network state in terms of links and 521 nodes (referred to as the Traffic Engineering Database or TED) but 522 also the status of active services (previously computed paths, and 523 currently reserved resources, stored in the Label Switched Paths 524 Database (LSPDB). 526 [RFC8051] describes general considerations for a stateful PCE 527 deployment and examines its applicability and benefits, as well as 528 its challenges and limitations through a number of use cases. 530 [RFC8231] describes a set of extensions to PCEP to provide stateful 531 control. A stateful PCE has access to not only the information 532 carried by the network's Interior Gateway Protocol (IGP), but also 533 the set of active paths and their reserved resources for its 534 computations. The additional state allows the PCE to compute 535 constrained paths while considering individual LSPs and their 536 interactions. [RFC8281] describes the setup, maintenance and 537 teardown of PCE-initiated LSPs under the stateful PCE model. 539 [RFC8231] also describes the active stateful PCE. The active PCE 540 functionality allows a PCE to reroute an existing LSP or make changes 541 to the attributes of an existing LSP, or a PCC to delegate control of 542 specific LSPs to a new PCE. 544 Computing paths across large multi-domain environments require 545 special computational components and cooperation between entities in 546 different domains capable of complex path computation. The PCE 547 provides an architecture and a set of functional components to 548 address this problem space. A PCE may be used to compute end-to-end 549 paths across multi-domain environments using a per-domain path 550 computation technique [RFC5152]. The Backward recursive PCE based 551 path computation (BRPC) mechanism [RFC5441] defines a PCE-based path 552 computation procedure to compute inter-domain constrained MPLS and 553 GMPLS TE networks. However, both per-domain and BRPC techniques 554 assume that the sequence of domains to be crossed from source to 555 destination is known, either fixed by the network operator or 556 obtained by other means. 558 [RFC6805] describes a Hierarchical PCE (H-PCE) architecture which can 559 be used for computing end-to-end paths for inter-domain MPLS Traffic 560 Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the 561 domain sequence is not known. Within the Hierarchical PCE (H-PCE) 562 architecture, the Parent PCE (P-PCE) is used to compute a multi- 563 domain path based on the domain connectivity information. A Child 564 PCE (C-PCE) may be responsible for a single domain or multiple 565 domains, it is used to compute the intra-domain path based on its 566 domain topology information. 568 [I-D.ietf-pce-stateful-hpce] state the considerations for stateful 569 PCE(s) in hierarchical PCE architecture. In particular, the 570 behaviour changes and additions to the existing stateful PCE 571 mechanisms (including PCE- initiated LSP set-up and active PCE usage) 572 in the context of networks using the H-PCE architecture. 574 [I-D.ietf-pce-applicability-actn] examines the applicability of PCE/ 575 PCEP to the ACTN framework in detail. 577 6.1.2. BGP 579 [RFC7752] describes a mechanism by which link-state and TE 580 information can be collected from networks and shared with external 581 components using the BGP routing protocol. This is achieved using a 582 new BGP Network Layer Reachability Information (NLRI) encoding format 583 and a new BGP path attribute (BGP-LS attribute) that carries link, 584 node, and prefix parameters and attributes. 586 BGP-LS is a new approach to collect the network topology information. 587 It is an extension to BGP for distribution the network's link-state 588 (LS) topology to external entities, such as the SDN controller. 589 Network's link-state topology consists of nodes and links and a set 590 of attributes. The link-state topology is distributed among the IGP 591 domain. The specific protocol used in an IGP domain could be OSPF 593 [RFC2238] or IS-IS [ISO10589]. Note that, the detailed link-state 594 models of these two protocols are not identical. Therefore, BGP-LS 595 can provide a more abstract topology model which can map the IGP 596 models. 598 The domain controller acts as a consumer to collect the domain's 599 link-state and TE information via BGP-LS. The domain controller 600 would usually abstract the domain information towards the super- 601 controller and further send it via BGP-LS. 603 BGP-Flowspec is a solution devised for preventing distributed Denial- 604 of-service (DDoS) attack. BGP-Flowspec distributes specification 605 rules into neighbours. [RFC5575] defines a new BGP NLRI encoding 606 format that can be used to distribute traffic flow specifications. 607 Additionally, it defines two applications of that encoding format: 608 one that can be used to automate inter-domain coordination of traffic 609 filtering, such as what is required in order to mitigate DDoS 610 attacks; and a second application to provide traffic filtering in the 611 context of BGP/MPLS VPN service. 613 The IP domain controller can act as the traffic sampling node. The 614 super controller can act as the traffic analysis server. When the 615 super controller finds the attack happened, the super controller 616 should distribute the flow rules to associated IP domain controllers. 617 And each IP domain controller should distribute the flow rules into 618 the ingress routers. Additionally one of the actions taken could be 619 "redirect" where flow could be redirected to the TE tunnels created 620 by the controller. 622 [I-D.luo-grow-bgp-controller-based-ts] describes the traffic steering 623 based on BGP controller. The traditional method for traffic steering 624 depends on static configuration which is time consuming and 625 inefficient. With the hierarchical IP controller, the IP domain 626 controller can have the domain network topology view and routing 627 information while the super controller can have the global network 628 topology view and routing information. The super controller can 629 compute the end-to-end paths to satisfy the differentiated service 630 requirement. The IP domain controller may be used to distribute the 631 routing policy into the routers. BGP policy varies in many aspects. 632 Its goal is to meet the customer application and connectivity 633 requirement, and specific service transport needs. So the super BGP 634 controller is responsible for the coordination of multiple domain BGP 635 Policy. And then distribute Policy to related IP domain controller. 636 The IP domain controller is responsible for distributing the policy 637 to its network nodes. 639 [I-D.ietf-idr-rtc-hierarchical-rr] describes the route target (RT) 640 constrain mechanism in the hierarchical route reflection (RR) 641 scenario. [RFC4684] describes the route target constrain mechanism 642 to build a route distribution graph in order to restrict the 643 propagation of Virtual Private Network (VPN) routes. 644 [I-D.ietf-idr-rtc-hierarchical-rr] proposes a solution to address the 645 RT constrain issue in the hierarchical RR scenarios. The super 646 controller corresponding to higher level RR can receive the RT- 647 constrain routes from the lower level RR, which is acted by the IP 648 domain controller. The higher level RR will select one of the 649 received routes as the best route. then it should advertise the best 650 route to all the lower level RR to build the route distribution 651 graph. This fits well with the HIC as described in this document. 653 6.2. Management Plane 655 6.2.1. YANG Models 657 This is an non-exhaustive list of possible yang models developed or 658 in-development that could be used for HIC. 660 Topology: [RFC8345] defines a generic YANG data model for network 661 topology. [I-D.ietf-teas-yang-te-topo] defines a YANG data model 662 for representing, retrieving and manipulating Traffic Engineering 663 (TE) Topologies. 665 Tunnel: [I-D.ietf-teas-yang-te] defines a YANG data model for the 666 configuration and management of Traffic Engineering (TE) 667 interfaces, tunnels and Label Switched Paths (LSPs). 669 L3VPN: The Layer 3 service model (L3SM) is defined in [RFC8299], 670 which is a YANG data model that can be used for communication 671 between customers and network operators and to deliver a Layer 3 672 provider-provisioned VPN service. [I-D.ietf-bess-l3vpn-yang] 673 defines a YANG data model that can be used to configure and manage 674 BGP Layer 3 VPNs at the device. Note that a network configuration 675 model at the Domain Controller level needs to be developed. 677 L2VPN/EVPN: [RFC8466] defines a YANG data model that can be used 678 to configure a Layer 2 Provider Provisioned VPN service. This 679 model is intended to be instantiated at management system to 680 deliver the overall service. [I-D.ietf-bess-l2vpn-yang] and 681 [I-D.ietf-bess-evpn-yang] defines a YANG data model to configure 682 and manage L2VPN and EVPN service respectively. Note that a 683 network configuration model at the Domain Controller level needs 684 to be developed. 686 OAM: TBD 687 BGP Policy: [I-D.ietf-idr-bgp-model] defines a YANG data model 688 that can be used to configure BGP Policy based on data centre, 689 carrier and content provider operational requirements. The model 690 is intended to be vendor-neutral, in order to allow operators to 691 manage BGP configuration in heterogeneous environments with 692 routers supplied by multiple vendors. Note that a network 693 configuration model at the Domain Controller level needs to be 694 developed. 696 BGP Flowspec: [I-D.wu-idr-flowspec-yang-cfg] defines a YANG data 697 model for Flow Specification implementations. The configuration 698 data is described as flow specification rules that can be 699 distributed as BGP NLRI to a network element. The rules can be 700 used to filter Distributed Denial of Service attacks (DDoS) 701 besides other use cases. Note that a network configuration model 702 at the Domain Controller level needs to be developed. 704 [Editor's Note - the above list should be extended.] 706 6.2.2. Protocol Considerations 708 The Network Configuration Protocol (NETCONF) [RFC6241] provides 709 mechanisms to install, manipulate, and delete the configuration of 710 network devices. The RESTCONF [RFC8040] describes an HTTP-based 711 protocol that provides a programmatic interface for accessing data 712 defined in YANG, using the data-store concepts defined in NETCONF. 714 Some other mechanism like gRPC/gNMI could also be used between 715 controllers using the same YANG data models. 717 7. IANA Considerations 719 There are no IANA concerns in this document. 721 8. Security Considerations 723 There are no new security concerns in this document. 725 9. Acknowledgments 727 10. Contributing Authors 729 Dailongfei (Larry) 730 Huawei Technologies, 731 Beijing, China 733 Email: larry.dai@huawei.com 735 11. References 737 11.1. Normative References 739 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 740 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 741 DOI 10.17487/RFC8453, August 2018, 742 . 744 11.2. Informative References 746 [RFC2238] Clouston, B., Ed. and B. Moore, Ed., "Definitions of 747 Managed Objects for HPR using SMIv2", RFC 2238, 748 DOI 10.17487/RFC2238, November 1997, 749 . 751 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 752 (TE) Extensions to OSPF Version 2", RFC 3630, 753 DOI 10.17487/RFC3630, September 2003, 754 . 756 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 757 Provider-Provisioned Virtual Private Networks (PPVPNs)", 758 RFC 4110, DOI 10.17487/RFC4110, July 2005, 759 . 761 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 762 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 763 DOI 10.17487/RFC4271, January 2006, 764 . 766 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 767 Reflection: An Alternative to Full Mesh Internal BGP 768 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 769 . 771 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 772 Element (PCE)-Based Architecture", RFC 4655, 773 DOI 10.17487/RFC4655, August 2006, 774 . 776 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 777 2 Virtual Private Networks (L2VPNs)", RFC 4664, 778 DOI 10.17487/RFC4664, September 2006, 779 . 781 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 782 R., Patel, K., and J. Guichard, "Constrained Route 783 Distribution for Border Gateway Protocol/MultiProtocol 784 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 785 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 786 November 2006, . 788 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 789 Per-Domain Path Computation Method for Establishing Inter- 790 Domain Traffic Engineering (TE) Label Switched Paths 791 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 792 . 794 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 795 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 796 2008, . 798 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 799 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 800 DOI 10.17487/RFC5440, March 2009, 801 . 803 [RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, 804 "A Backward-Recursive PCE-Based Computation (BRPC) 805 Procedure to Compute Shortest Constrained Inter-Domain 806 Traffic Engineering Label Switched Paths", RFC 5441, 807 DOI 10.17487/RFC5441, April 2009, 808 . 810 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 811 and D. McPherson, "Dissemination of Flow Specification 812 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 813 . 815 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 816 and A. Bierman, Ed., "Network Configuration Protocol 817 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 818 . 820 [RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the 821 Path Computation Element Architecture to the Determination 822 of a Sequence of Domains in MPLS and GMPLS", RFC 6805, 823 DOI 10.17487/RFC6805, November 2012, 824 . 826 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 827 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 828 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 829 2015, . 831 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 832 Application-Based Network Operations", RFC 7491, 833 DOI 10.17487/RFC7491, March 2015, 834 . 836 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 837 S. Ray, "North-Bound Distribution of Link-State and 838 Traffic Engineering (TE) Information Using BGP", RFC 7752, 839 DOI 10.17487/RFC7752, March 2016, 840 . 842 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 843 Monitoring Protocol (BMP)", RFC 7854, 844 DOI 10.17487/RFC7854, June 2016, 845 . 847 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 848 Ceccarelli, D., and X. Zhang, "Problem Statement and 849 Architecture for Information Exchange between 850 Interconnected Traffic-Engineered Networks", BCP 206, 851 RFC 7926, DOI 10.17487/RFC7926, July 2016, 852 . 854 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 855 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 856 . 858 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 859 Stateful Path Computation Element (PCE)", RFC 8051, 860 DOI 10.17487/RFC8051, January 2017, 861 . 863 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 864 Computation Element Communication Protocol (PCEP) 865 Extensions for Stateful PCE", RFC 8231, 866 DOI 10.17487/RFC8231, September 2017, 867 . 869 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 870 Computation Element Communication Protocol (PCEP) 871 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 872 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 873 . 875 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 876 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 877 DOI 10.17487/RFC8299, January 2018, 878 . 880 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 881 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 882 . 884 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 885 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 886 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 887 2018, . 889 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 890 Data Model for Layer 2 Virtual Private Network (L2VPN) 891 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 892 2018, . 894 [I-D.ietf-teas-actn-yang] 895 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B., Dios, O., 896 Shin, J., and S. Belotti, "Applicability of YANG models 897 for Abstraction and Control of Traffic Engineered 898 Networks", draft-ietf-teas-actn-yang-03 (work in 899 progress), February 2019. 901 [I-D.ietf-pce-applicability-actn] 902 Dhody, D., Lee, Y., and D. Ceccarelli, "Applicability of 903 Path Computation Element (PCE) for Abstraction and Control 904 of TE Networks (ACTN)", draft-ietf-pce-applicability- 905 actn-08 (work in progress), December 2018. 907 [I-D.ietf-teas-yang-te] 908 Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, 909 "A YANG Data Model for Traffic Engineering Tunnels and 910 Interfaces", draft-ietf-teas-yang-te-19 (work in 911 progress), February 2019. 913 [I-D.ietf-teas-yang-te-topo] 914 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 915 O. Dios, "YANG Data Model for Traffic Engineering (TE) 916 Topologies", draft-ietf-teas-yang-te-topo-19 (work in 917 progress), February 2019. 919 [I-D.ietf-pce-stateful-hpce] 920 Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., King, D., 921 and O. Dios, "Hierarchical Stateful Path Computation 922 Element (PCE).", draft-ietf-pce-stateful-hpce-06 (work in 923 progress), October 2018. 925 [I-D.ietf-teas-yang-path-computation] 926 Busi, I., Belotti, S., Lopezalvarez, V., Dios, O., Sharma, 927 A., Shi, Y., Vilata, R., Sethuraman, K., Scharf, M., and 928 D. Ceccarelli, "Yang model for requesting Path 929 Computation", draft-ietf-teas-yang-path-computation-04 930 (work in progress), November 2018. 932 [I-D.ietf-mpls-seamless-mpls] 933 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 934 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 935 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 937 [I-D.ietf-bess-evpn-yang] 938 Brissette, P., Shah, H., Hussain, I., Tiruveedhula, K., 939 and J. Rabadan, "Yang Data Model for EVPN", draft-ietf- 940 bess-evpn-yang-06 (work in progress), October 2018. 942 [I-D.ietf-bess-l2vpn-yang] 943 Shah, H., Brissette, P., Chen, I., Hussain, I., Wen, B., 944 and K. Tiruveedhula, "YANG Data Model for MPLS-based 945 L2VPN", draft-ietf-bess-l2vpn-yang-09 (work in progress), 946 October 2018. 948 [I-D.ietf-bess-l3vpn-yang] 949 Jain, D., Patel, K., Brissette, P., Li, Z., Zhuang, S., 950 Liu, X., Haas, J., Esale, S., and B. Wen, "Yang Data Model 951 for BGP/MPLS L3 VPNs", draft-ietf-bess-l3vpn-yang-04 (work 952 in progress), October 2018. 954 [I-D.dhodylee-pce-pcep-ls] 955 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 956 Distribution of Link-State and TE Information.", draft- 957 dhodylee-pce-pcep-ls-13 (work in progress), February 2019. 959 [I-D.lee-teas-te-service-mapping-yang] 960 Lee, Y., Dhody, D., Ceccarelli, D., Tantsura, J., 961 Fioccola, G., and Q. Wu, "Traffic Engineering and Service 962 Mapping Yang Model", draft-lee-teas-te-service-mapping- 963 yang-13 (work in progress), December 2018. 965 [I-D.dugeon-pce-stateful-interdomain] 966 Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP 967 Extension for Stateful Inter-Domain Tunnels", draft- 968 dugeon-pce-stateful-interdomain-02 (work in progress), 969 March 2019. 971 [I-D.luo-grow-bgp-controller-based-ts] 972 Luo, Y., Ou, L., Huang, X., Zhuang, S., and Z. Li, 973 "Traffic Steering Based on BGP Controller", draft-luo- 974 grow-bgp-controller-based-ts-00 (work in progress), March 975 2018. 977 [I-D.ietf-idr-rtc-hierarchical-rr] 978 Dong, J., Chen, M., and R. Raszuk, "Extensions to RT- 979 Constrain in Hierarchical Route Reflection Scenarios", 980 draft-ietf-idr-rtc-hierarchical-rr-03 (work in progress), 981 July 2017. 983 [I-D.ietf-idr-bgp-model] 984 Patel, K., Jethanandani, M., and S. Hares, "BGP YANG Model 985 for Service Provider Networks", draft-ietf-idr-bgp- 986 model-04 (work in progress), February 2019. 988 [I-D.wu-idr-flowspec-yang-cfg] 989 Wu, N., Zhuang, S., and A. Choudhary, "A YANG Data Model 990 for Flow Specification", draft-wu-idr-flowspec-yang-cfg-02 991 (work in progress), October 2015. 993 [ISO10589] 994 ISO, "Intermediate system to Intermediate system routing 995 information exchange protocol for use in conjunction with 996 the Protocol for providing the Connectionless-mode Network 997 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 999 Authors' Addresses 1001 Zhenbin Li 1002 Huawei Technologies 1003 Huawei Bld., No.156 Beiqing Rd. 1004 Beijing 100095 1005 China 1007 EMail: lizhenbin@huawei.com 1008 Dhruv Dhody 1009 Huawei Technologies 1010 Divyashree Techno Park, Whitefield 1011 Bangalore, Karnataka 560066 1012 India 1014 EMail: dhruv.ietf@gmail.com 1016 Huaimo Chen 1017 Huawei Technologies 1018 Boston, MA 1019 USA 1021 EMail: huaimo.chen@huawei.com