idnits 2.17.1 draft-malis-detnet-controller-plane-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 02, 2019) is 1759 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-detnet-data-plane-framework-01 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-mpls-01 == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-04 == Outdated reference: A later version (-10) exists of draft-dhody-pce-pcep-extension-pce-controller-srv6-01 == Outdated reference: A later version (-13) exists of draft-dong-spring-sr-for-enhanced-vpn-04 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-02 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-ip-over-mpls-01 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-over-tsn-00 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-mpls-over-tsn-00 == Outdated reference: A later version (-08) exists of draft-ietf-detnet-mpls-over-udp-ip-01 == Outdated reference: A later version (-01) exists of draft-ietf-detnet-topology-yang-00 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-tsn-vpn-over-mpls-00 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-yang-02 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-04 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Malis 3 Internet-Draft Futurewei Technologies 4 Intended status: Informational July 02, 2019 5 Expires: January 3, 2020 7 Deterministic Networking (DetNet) Controller Plane Framework 8 draft-malis-detnet-controller-plane-framework-00 10 Abstract 12 This document provides a framework overview for the Deterministic 13 Networking (DetNet) controller plane. It discusses concepts and 14 requirements that will be basis for Detnet controller plane solution 15 documents. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 3, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. DetNet Controller Plane Requirements . . . . . . . . . . . . 3 54 3. DetNet Controller Plane Architecture . . . . . . . . . . . . 5 55 3.1. Distributed Control Plane and Signaling Protocols . . . . 5 56 3.2. SDN/Fully Centralized Control Plane . . . . . . . . . . . 6 57 3.3. Hybrid Control Plane . . . . . . . . . . . . . . . . . . 7 58 4. Control Plane for DetNet Domains . . . . . . . . . . . . . . 8 59 4.1. DetNet in a Traditional MPLS Domain . . . . . . . . . . . 8 60 4.2. IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 4.3. DetNet with Segment Routing (SR) . . . . . . . . . . . . 9 62 5. Management Plane Overview . . . . . . . . . . . . . . . . . . 10 63 5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 10 64 5.2. DetNet Operations, Administration and Maintenance (OAM) . 10 65 5.2.1. OAM for Performance Monitoring (PM) . . . . . . . . . 10 66 5.2.2. OAM for Fault/Defect Management (FM) . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 9.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 75 1. Introduction 77 Deterministic Networking (DetNet) provides the capability to carry 78 specified unicast and/or multicast data flows for real-time 79 applications with extremely low data loss rates and bounded latency 80 within a network domain. As discussed in the Deterministic 81 Networking Architecture [I-D.ietf-detnet-architecture], techniques 82 used to provide this capability include reserving data plane 83 resources for individual (or aggregated) DetNet flows in some or all 84 of the intermediate nodes along the path of the flow, providing 85 explicit routes for DetNet flows that do not immediately change with 86 the network topology, and distributing data from DetNet flow packets 87 over time and/or space to ensure delivery of each packet's data in 88 spite of the loss of a path. 90 The DetNet data plane is defined in a set of documents that are 91 anchored by the DetNet Data Plane Framework 92 [I-D.ietf-detnet-data-plane-framework] and the associated DetNet MPLS 93 [I-D.ietf-detnet-mpls] and IP [I-D.ietf-detnet-ip] data plane 94 specifications, with additional details and subnet mappings provided 95 in [I-D.ietf-detnet-ip-over-mpls], 96 [I-D.ietf-detnet-mpls-over-udp-ip], [I-D.ietf-detnet-mpls-over-tsn], 98 [I-D.ietf-detnet-ip-over-tsn], and 99 [I-D.ietf-detnet-tsn-vpn-over-mpls]. 101 While the Detnet Architecture and Data Plane Framework documents are 102 primarily concerned with data plane operations, they do contain some 103 references and requirements for functions that would be required in 104 order to automate DetNet service provisioning and monitoring via a 105 DetNet controller plane. The purpose of this document is to gather 106 these references and requirements into a single document and discuss 107 how various possible DetNet controller plane architectures could be 108 used to satisfy these requirements, while not providing the actual 109 protocol details for a DetNet controller plane solution. Such 110 controller plane protocol solutions will be the subject of subsequent 111 documents. 113 Note that in the DetNet overall architecture, the controller plane 114 includes what are more traditionally considered separate control and 115 management planes. Traditionally, the management plane is primarily 116 involved with node and network provisioning, operational OAM for 117 performance monitoring, and troubleshooting network behaviors and 118 outages, while the control plane is primarily responsible for the 119 instantiation and maintenance of flows, MPLS label allocation and 120 distribution, and active in-band or out-of-band signaling to support 121 these functions. In the DetNet architecture, all of this 122 functionality is combined into a single Controller Plane. See 123 Section 4.4.2 of [I-D.ietf-detnet-architecture] and the aggregation 124 of Control and Management planes in [RFC7426] for further details. 126 1.1. Terminology 128 This document uses the terminology established in the DetNet 129 Architecture [I-D.ietf-detnet-architecture], and the reader is 130 assumed to be familiar with that document and its terminology. 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 2. DetNet Controller Plane Requirements 140 Other DetNet documents, including [I-D.ietf-detnet-architecture] and 141 [I-D.ietf-detnet-data-plane-framework], contain requirements for the 142 Controller Plane. For convenience, these requirements have been 143 compiled here. The primary requirements of the DetNet Controller 144 Plane are that it must be able to: 146 o Support the dynamic creation, modification, and deletion of DetNet 147 flows. This may include some or all of explicit path 148 determination, link bandwidth reservations, restricting flows to 149 IEEE 802.1 Time-Sensitive Networking (TSN) links, node buffer and 150 other resource reservations, specification of required queuing 151 disciplines along the path, ability to manage bidirectional flows, 152 etc., as needed for a flow. 154 o Support DetNet flow aggregation and de-aggregation via the ability 155 to dynamically create and delete flow aggregates (FAs), and be 156 able to modify existing FAs by adding or deleting members. 158 o Operate in a converged network domain that contains both DetNet 159 and non-DetNet flows. 161 o Allow flow instantiation requests to originate in an end 162 application (via an Application Programming Interface (API), via 163 static provisioning, or via a dynamic control plane, such as a 164 centralized SDN controller or distributed signaling protocols. 165 See Section 3 for further discussion of these options. 167 o In the case of the DetNet MPLS data plane, manage DetNet S-Label 168 and F-Label allocation and distribution. 170 o Also in the case of the DetNet MPLS data plane, support packet 171 replication, duplicate elimination, and packet ordering functions 172 (PREOF), and to be able to place these functions at appropriate 173 places in the network. 175 o Support applications that require the ability to synchronize the 176 clocks in end systems to the extent supported by the DetNet data 177 plane. 179 o Support queue control techniques defined in Section 4.5 of 180 [I-D.ietf-detnet-architecture] and 181 [I-D.finn-detnet-bounded-latency] that require time 182 synchronization among network nodes. 184 o Advertise static and dynamic node and link resources such as 185 capabilities and adjacencies to other network nodes (for dynamic 186 signaling approaches) or to network controllers (for centralized 187 approaches). 189 o Adapt to network topology changes such as links or nodes failures. 191 o Scale to handle the number of DetNet flows expected in a domain 192 (which may require per-flow signaling or provisioning). This is 193 similar to scalability requirements associated with network 194 slicing [I-D.dong-spring-sr-for-enhanced-vpn]. 196 o Provision flow identification information at each of the nodes 197 along the path. Flow identification may differ depending on the 198 location in the network and the DetNet functionality (e.g. transit 199 node vs. relay node). 201 o Monitor the performance of DetNet flows to ensure that they are 202 meeting required objectives. 204 3. DetNet Controller Plane Architecture 206 The following sections define three possible classes of DetNet 207 control plane architectures: a fully distributed control plane 208 utilizing dynamic signaling protocols, a fully centralized SDN-like 209 control plane, and a hybrid control plane. They discuss the various 210 information exchanges between entities in the network in each of 211 these architectures and the advantages and disadvantages of each 212 option. 214 In each of the following sections, examples are used to illustrate 215 possible mechanisms that could be used in each of the architectures. 216 These are not meant to be exhaustive or to preclude any other 217 possible mechanism that could be used in place of those used in the 218 examples. 220 3.1. Distributed Control Plane and Signaling Protocols 222 In a fully distributed configuration model, User-to-Network Interface 223 (UNI) information is transmitted over a (to-be-defined) DetNet UNI 224 protocol from the user side to the network side, and then UNI and 225 network configuration information propagate in the network via 226 distributed control plane signaling protocols. Using an RSVP-TE 227 traffic-engineered MPLS network as an example: 229 1. An IGP collects topology information and DetNet capabilities of 230 the network [draft-geng-detnet-info-distribution]; 232 2. The control plane of the ingress edge node receives a flow 233 establishment request from the UNI and calculates one or more 234 valid path(s); 236 3. Using RSVP-TE [RFC3209], the ingress edge node sends a PATH 237 message with an explicit route. After receiving the PATH 238 message, the egress edge node sends a RESV message with the 239 distributed label and resource reservation request. 241 Current reservation-oriented distributed control plane protocols, 242 e.g. RSVP-TE and Stream Reservation Protocol (SRP) 243 [IEEE.802.1Qcc-2018], can only reserve bandwidth along the path, 244 while the configuration of a fine-grained schedule, e.g., Time Aware 245 Shaping (TAS) [IEEE.802.1QBV_2015], is not supported. If RSVP-TE or 246 SRP were to be used for a DetNet application, it would require 247 extensions in order to support queue and scheduler reservations in 248 addition to bandwidth reservation. 250 As discussed in Section 4.9 of [I-D.ietf-detnet-architecture], 251 scalability is a primary concern for DetNet, given the large number 252 of expected flows in a DetNet domain. This could potentially be much 253 larger than, for example, the number of MPLS traffic tunnels in a 254 network using MPLS traffic engineering, which would typically be 255 N*(N-1) tunnels, where N is the number of edge routers in the domain. 257 Even when flow aggregation is used, DetNet domains can be expected to 258 support a very large number of flows that will need particular 259 queuing disciplines and/or resource allocation, depending on the 260 requirements for each flow. This could require a large amount of 261 dynamic signaling, such as an RSVP-TE session to establish and 262 maintain each flow. Other RSVP-TE scalability concerns are further 263 discussed in [RFC5439]. 265 All of the above tends to argue against a purely distributed control 266 plane for DetNet domains. 268 3.2. SDN/Fully Centralized Control Plane 270 In the fully SDN/centralized configuration model, UNI information is 271 transmitted from a Centralized User Configuration (CUC) or from 272 applications via an API or northbound interface to a Centralized 273 Controller, which is the sole source of routing and forwarding 274 information for the domain. Configurations of nodes for DetNet flows 275 are performed by the controller using a protocol such as NETCONF 276 [RFC6241]/YANG [RFC6020] or PCE-CC [RFC8283]. For example: 278 1. The controller collects topology information and DetNet 279 capabilities of the network via NETCONF/YANG; 281 2. The controller receives a flow establishment request from a UNI 282 and calculates one or more valid path(s) through the network; 284 3. The controller chooses the optimal path and configures the 285 devices along that path for flow transmission via PCE-CC. 287 3.3. Hybrid Control Plane 289 In the hybrid model, a controller and control plane protocols work 290 together to provide DetNet services, and there are a number of 291 possible combinations. For example: 293 1. A Centralized Controller collects topology information and DetNet 294 capabilities of the network via an IGP and/or BGP-LS [RFC7752]; 296 2. The controller receives a flow establishment request from a UNI 297 and calculates one or more valid path(s) through the network; 299 3. Based on the calculation result, the CNC distributes flow path 300 information to the ingress edge node and other information (e.g. 301 replication/duplicate elimination) to the relevant nodes. 303 4. Using RSVP-TE, the ingress edge node sends a PATH message with an 304 explicit route. After receiving the PATH message, the egress 305 edge node sends a RESV message with the distributed label and 306 resource reservation request. 308 or 310 1. The controller collects topology information and DetNet 311 capability of the network via an IGP or BGP-LS; 313 2. The control plane of the ingress edge node receives a flow 314 establishment request via a UNI; 316 3. The Ingress edge node sends the path establishment request to the 317 controller through PCEP [RFC5440]; 319 4. After path calculation, the CNC sends the path information of the 320 flow to the ingress edge node via PCEP; 322 5. Using RSVP-TE, the ingress edge node sends a PATH message with an 323 explicit route. After receiving the PATH message, the egress 324 edge node sends a RESV message with the distributed label and 325 resource reservation request. 327 There are many other variations that could be included in a hybrid 328 control plane. This document cannot discuss all the possible control 329 plane mechanisms that could be used in hybrid configuration models. 330 Every solution has its own mechanisms and corresponding parameters 331 that are required for it to work. 333 4. Control Plane for DetNet Domains 335 This section discusses control plane issues that are unique to the 336 DetNet. 338 4.1. DetNet in a Traditional MPLS Domain 340 For the purposes of this document, "traditional MPLS" is defined as 341 MPLS without the use of segment routing (see Section 4.3 for a 342 discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. 344 In traditional MPLS domains, a dynamic control plane using 345 distributed signaling protocols is typically used for the 346 distribution of MPLS labels used for forwarding MPLS packets. The 347 dynamic signaling protocols most commonly used for label distribution 348 are LDP [RFC5036], RSVP-TE, and BGP [RFC8277] (which enables BGP/ 349 MPLS-based Layer 3 VPNs [RFC4384] and Layer 2 VPNs [RFC7432]). 351 Any of these protocols could be used to distribute DetNet Service 352 Labels (S-Labels) and Aggregation Labels 353 (A-Labels)[I-D.ietf-detnet-mpls]. As discussed in 354 [I-D.ietf-detnet-data-plane-framework], S-Labels are similar to other 355 MPLS service labels, such as pseudowire, L3 VPN, and L2 VPN labels, 356 and could be distributed in a similar manner, such as through the use 357 of targeted LDP or BGP. If these were to be used for DetNet, they 358 would require extensions to support DetNet-specific features such as 359 PREOF, aggregation (A-Labels), node resource allocation, and queue 360 placement. 362 However, as discussed in Section 3.1, distributed signaling protocols 363 may have difficulty meeting DetNet's scalability requirements. MPLS 364 also allows SDN-like centralized label management and distribution as 365 an alternative to distributed signaling protocols, using protocols 366 such as PCEP and OpenFlow [OPENFLOW]. 368 PCEP, particularly when used as a part of PCE-CC, is a possible 369 candidate protocol to use for centralized management of traditional 370 MPLS-based DetNet domains. However, PCE path calculation algorithms 371 would need to be extended to include the location determination for 372 PREOF nodes in a path, and the means to signal the necessary resource 373 reservation and PREOF function placement information to network 374 nodes. See ((?I-D.ietf-pce-pcep-extension-for-pce-controller)) for 375 further discussion of PCE-CC and PCEP for centralized control of an 376 MPLS domain. 378 4.2. IP 380 In a later revision of this document, this section will discuss 381 necessary protocol extensions to existing IP routing protocols such 382 as IS-IS and BGP. It should be noted that a DetNet IP domain is 383 simpler than a DetNet MPLS domain, and doesn't support PREOF, so only 384 one path per flow or flow aggregate is required, with no path 385 merging. 387 4.3. DetNet with Segment Routing (SR) 389 Segment Routing [RFC8402] is a scalable approach to building network 390 domains that utilizes a combination of source routing in packet 391 headers and centralized network control to compute paths through the 392 network and distribute those paths with associated policy to network 393 edge nodes for use in packet headers. It greatly reduces the amount 394 of network signaling associated with distributed signaling protocols 395 such as RSVP-TE, and also greatly reduces the amount of state in core 396 nodes compared with that required for traditional MPLS and IP 397 routing, as the state is now in the packets rather than in the 398 routers. This is especially useful for DetNet, where a very large 399 number of flows through a network domain are expected, which would 400 otherwise require the instantiation of state for each flow traversing 401 each node in the network. 403 The DetNet MPLS and IP data planes were specifically constructed to 404 allow the use of DetNet with both types of segment routing, SR-MPLS 405 [I-D.ietf-spring-segment-routing-mpls] and SRv6 406 [I-D.ietf-6man-segment-routing-header]. 408 In the DetNet context, DetNet in an SR-MPLS or SRv6 data plane could 409 be used in conjunction with centralized flow management and complete 410 label stack distribution to Detnet domain entry nodes via a 411 centralized controller. Extensions to PCEP to allow the use of PCE- 412 CC with SR-MPLS 414 One possible architecture is PCE-CC combined with SR-MPLS or SRv6. 415 Extensions to PCEP to allow the use of PCE-CC with SR-MPLS are 416 described in [I-D.zhao-pce-pcep-extension-pce-controller-sr], with 417 SRv6 in [I-D.dhody-pce-pcep-extension-pce-controller-srv6]. 419 This approach would allow the details of packet or flow treatment to 420 be encoded directly in the SIDs on each packet in a flow to reduce 421 the amount of state in network nodes. This approach also allows the 422 integration of DetNet domains with general SR-based backbone networks 423 in a converged domain. In this approach, a new set of functions for 424 DetNet queuing treatments available in the DetNet domain would need 425 to be defined for inclusion in the SR stack. 427 This is not the only possible approach. There is ongoing work on a 428 number of alternative signaling mechanisms for MPLS-SR and SRv6, 429 including extensions to IGPs and BGP to support distributed 430 signaling. In addition, BGP-LS and BGP route reflectors could be 431 added for a hybrid solution. 433 A possible mostly centralized hybrid approach could be to use a PCE- 434 CC to push paths represented by SID lists while using BGP-LS to 435 collect network topology and link state information. An IGP is used 436 for the usual link state flooding in order to establish adjacencies, 437 but not for DetNet flow path calculations, only for best effort 438 traffic as usual. 440 A similar approach for network slicing that could be leveraged for 441 DetNet is described in [I-D.dong-spring-sr-for-enhanced-vpn]. 443 Also, note that SR cannot currently support DetNet PREOF 444 functionality without extensions. One possible approach could be to 445 combine SR with BIER-TE, as discussed in [I-D.ietf-bier-te-arch]. 447 5. Management Plane Overview 449 The Management Plane includes the ability to statically provision 450 network nodes and to use OAM to monitor DetNet performance and detect 451 outages or other issues at the DetNet layer. 453 5.1. Provisioning 455 Static provisioning in a Detnet network will be performed via the use 456 of appropriate YANG models, including [I-D.ietf-detnet-yang] and 457 [I-D.ietf-detnet-topology-yang]. 459 5.2. DetNet Operations, Administration and Maintenance (OAM) 461 The overall framework and requirements for DetNet OAM are discussed 462 in [I-D.mirsky-detnet-oam]. This document currently includes 463 additional OAM details that may eventually be merged into that 464 document. 466 5.2.1. OAM for Performance Monitoring (PM) 468 5.2.1.1. Active PM 470 Active PM is performed by injecting OAM packets into the network to 471 estimate the performance of the network by measuring the performance 472 of the OAM packets. Adding extra traffic can affect the delay and 473 throughput performance of the network, and for this reason active PM 474 is not recommended for use in operational DetNet domains. However, 475 it is a useful test tool when commissioning a new network. 477 5.2.1.2. Passive PM 479 Passive PM monitors the actual service traffic in a network domain in 480 order to measure its performance without having a detrimental affect 481 on the network. As compared to Active PM, Passive PM is much 482 preferred for use in DetNet domains. 484 A proposal for DetNet passive performance measurement is contained in 485 [I-D.chen-detnet-loss-delay]. 487 5.2.2. OAM for Fault/Defect Management (FM) 489 [I-D.mirsky-detnet-oam] contains requirements for fault/defect 490 detection and management in a DetNet domain. 492 6. IANA Considerations 494 This document has no actions for IANA. 496 Note to RFC Editor: this section may be removed on publication as an 497 RFC. 499 7. Security Considerations 501 The overall security considerations of DetNet are discussed in 502 [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. For 503 DetNet networks that make use of Segment Routing (whether SR-MPLS or 504 SRv6), the security considerations in [RFC8402] also apply. 506 DetNet networks that make use of a centralized controller plane may 507 be threatened by the loss of connectivity (whether accidental or 508 malicious) between the central controller and the network nodes, and/ 509 or the spoofing of control messages from the controller to the 510 network nodes. This is important since such networks depend on 511 centralized controllers to calculate flow paths and instantiate flow 512 state in the network nodes. For networks that use both DetNet and 513 Segment Routing with a centralized controller, this would also 514 include the calculation of SID lists and their installation in edge/ 515 border routers. 517 In both cases, such threats may be mitigated through redundant 518 controllers, the use of authentication between the controller(s) and 519 the network nodes, and other mechanisms for protection against DOS 520 attacks. A mechanism for supporting one or more alternative central 521 controllers and the ability to fail over to such an alternative 522 controller will be required. 524 8. Acknowledgments 526 Thanks to Jim Guichard, Donald Eastlake, and Stewart Bryant for their 527 review comments. 529 9. References 531 9.1. Normative References 533 [I-D.ietf-detnet-architecture] 534 Finn, N., Thubert, P., Varga, B., and J. Farkas, 535 "Deterministic Networking Architecture", draft-ietf- 536 detnet-architecture-13 (work in progress), May 2019. 538 [I-D.ietf-detnet-data-plane-framework] 539 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 540 Bryant, S., and J. Korhonen, "DetNet Data Plane 541 Framework", draft-ietf-detnet-data-plane-framework-01 542 (work in progress), July 2019. 544 [I-D.ietf-detnet-ip] 545 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 546 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 547 draft-ietf-detnet-ip-01 (work in progress), July 2019. 549 [I-D.ietf-detnet-mpls] 550 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 551 Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", 552 draft-ietf-detnet-mpls-01 (work in progress), July 2019. 554 [I-D.ietf-detnet-security] 555 Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, 556 J., Austad, H., Stanton, K., and N. Finn, "Deterministic 557 Networking (DetNet) Security Considerations", draft-ietf- 558 detnet-security-04 (work in progress), March 2019. 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, 562 DOI 10.17487/RFC2119, March 1997, 563 . 565 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 566 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 567 Defined Networking (SDN): Layers and Architecture 568 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 569 2015, . 571 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 572 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 573 May 2017, . 575 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 576 Decraene, B., Litkowski, S., and R. Shakir, "Segment 577 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 578 July 2018, . 580 9.2. Informative References 582 [I-D.chen-detnet-loss-delay] 583 Chen, M. and A. Malis, "DetNet Packet Loss and Delay 584 Performance Measurement", draft-chen-detnet-loss-delay-01 585 (work in progress), October 2018. 587 [I-D.dhody-pce-pcep-extension-pce-controller-srv6] 588 Negi, M., Li, Z., and X. Geng, "PCEP Procedures and 589 Protocol Extensions for Using PCE as a Central Controller 590 (PCECC) for SRv6", draft-dhody-pce-pcep-extension-pce- 591 controller-srv6-01 (work in progress), February 2019. 593 [I-D.dong-spring-sr-for-enhanced-vpn] 594 Dong, J., Bryant, S., Miyasaka, T., Zhu, Y., Qin, F., and 595 Z. Li, "Segment Routing for Enhanced VPN Service", draft- 596 dong-spring-sr-for-enhanced-vpn-04 (work in progress), 597 July 2019. 599 [I-D.finn-detnet-bounded-latency] 600 Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, 601 B., and J. Farkas, "DetNet Bounded Latency", draft-finn- 602 detnet-bounded-latency-04 (work in progress), June 2019. 604 [I-D.ietf-6man-segment-routing-header] 605 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 606 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 607 Routing Header (SRH)", draft-ietf-6man-segment-routing- 608 header-21 (work in progress), June 2019. 610 [I-D.ietf-bier-te-arch] 611 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 612 Engineering for Bit Index Explicit Replication (BIER-TE)", 613 draft-ietf-bier-te-arch-02 (work in progress), May 2019. 615 [I-D.ietf-detnet-ip-over-mpls] 616 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 617 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over 618 MPLS", draft-ietf-detnet-ip-over-mpls-01 (work in 619 progress), July 2019. 621 [I-D.ietf-detnet-ip-over-tsn] 622 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 623 Korhonen, "DetNet Data Plane: IP over IEEE 802.1 Time 624 Sensitive Networking (TSN)", draft-ietf-detnet-ip-over- 625 tsn-00 (work in progress), May 2019. 627 [I-D.ietf-detnet-mpls-over-tsn] 628 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 629 Korhonen, "DetNet Data Plane: MPLS over IEEE 802.1 Time 630 Sensitive Networking (TSN)", draft-ietf-detnet-mpls-over- 631 tsn-00 (work in progress), May 2019. 633 [I-D.ietf-detnet-mpls-over-udp-ip] 634 Varga, B., Farkas, J., Berger, L., Malis, A., Bryant, S., 635 and J. Korhonen, "DetNet Data Plane: MPLS over UDP/IP", 636 draft-ietf-detnet-mpls-over-udp-ip-01 (work in progress), 637 July 2019. 639 [I-D.ietf-detnet-topology-yang] 640 Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic 641 Networking (DetNet) Topology YANG Model", draft-ietf- 642 detnet-topology-yang-00 (work in progress), January 2019. 644 [I-D.ietf-detnet-tsn-vpn-over-mpls] 645 Varga, B., Farkas, J., Malis, A., Bryant, S., and J. 646 Korhonen, "DetNet Data Plane: IEEE 802.1 Time Sensitive 647 Networking over MPLS", draft-ietf-detnet-tsn-vpn-over- 648 mpls-00 (work in progress), May 2019. 650 [I-D.ietf-detnet-yang] 651 Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic 652 Networking (DetNet) Configuration YANG Model", draft-ietf- 653 detnet-yang-02 (work in progress), March 2019. 655 [I-D.ietf-spring-segment-routing-mpls] 656 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 657 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 658 data plane", draft-ietf-spring-segment-routing-mpls-22 659 (work in progress), May 2019. 661 [I-D.mirsky-detnet-oam] 662 Mirsky, G. and M. Chen, "Operations, Administration and 663 Maintenance (OAM) for Deterministic Networks (DetNet)", 664 draft-mirsky-detnet-oam-03 (work in progress), May 2019. 666 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 667 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 668 and Protocol Extensions for Using PCE as a Central 669 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 670 extension-pce-controller-sr-04 (work in progress), 671 February 2019. 673 [IEEE.802.1QBV_2015] 674 IEEE, "IEEE Standard for Local and metropolitan area 675 networks -- Bridges and Bridged Networks - Amendment 25: 676 Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, 677 DOI 10.1109/IEEESTD.2016.7572858, March 2016, 678 . 681 [IEEE.802.1Qcc-2018] 682 IEEE, "IEEE Standard for Local and Metropolitan Area 683 Networks -- Bridges and Bridged Networks -- Amendment 31: 684 Stream Reservation Protocol (SRP) Enhancements and 685 Performance Improvements", IEEE 802.1Qcc-2018, 686 DOI 10.1109/ieeestd.2018.8514112, October 2018, 687 . 690 [OPENFLOW] 691 Open Networking Foundation, "OpenFlow Switch 692 Specification, Version 1.5.1 (Protocol version 0x06)", 693 ONF TS-025, March 2015, . 696 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 697 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 698 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 699 . 701 [RFC4384] Meyer, D., "BGP Communities for Data Collection", BCP 114, 702 RFC 4384, DOI 10.17487/RFC4384, February 2006, 703 . 705 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 706 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 707 October 2007, . 709 [RFC5439] Yasukawa, S., Farrel, A., and O. Komolafe, "An Analysis of 710 Scaling Issues in MPLS-TE Core Networks", RFC 5439, 711 DOI 10.17487/RFC5439, February 2009, 712 . 714 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 715 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 716 DOI 10.17487/RFC5440, March 2009, 717 . 719 [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS 720 Transport Profile Data Plane Architecture", RFC 5960, 721 DOI 10.17487/RFC5960, August 2010, 722 . 724 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 725 the Network Configuration Protocol (NETCONF)", RFC 6020, 726 DOI 10.17487/RFC6020, October 2010, 727 . 729 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 730 and A. Bierman, Ed., "Network Configuration Protocol 731 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 732 . 734 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 735 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 736 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 737 2015, . 739 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 740 S. Ray, "North-Bound Distribution of Link-State and 741 Traffic Engineering (TE) Information Using BGP", RFC 7752, 742 DOI 10.17487/RFC7752, March 2016, 743 . 745 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 746 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 747 . 749 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 750 Architecture for Use of PCE and the PCE Communication 751 Protocol (PCEP) in a Network with Central Control", 752 RFC 8283, DOI 10.17487/RFC8283, December 2017, 753 . 755 Author's Address 757 Andrew G. Malis 758 Futurewei Technologies 760 Email: agmalis@gmail.com