idnits 2.17.1 draft-thubert-bier-replication-elimination-03.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 3, 2018) is 2246 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 614, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-00 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-04 == Outdated reference: A later version (-09) exists of draft-ietf-detnet-problem-statement-02 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-14 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER P. Thubert, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track T. Eckert 5 Expires: September 4, 2018 Huawei 6 Z. Brodard 7 Ecole Polytechnique 8 H. Jiang 9 Telecom Bretagne 10 March 3, 2018 12 BIER-TE extensions for Packet Replication and Elimination Function 13 (PREF) and OAM 14 draft-thubert-bier-replication-elimination-03 16 Abstract 18 This specification extends Bit Index Explicit Replication - Traffic 19 Engineering (BIER-TE) forwarding to support in the data plane the 20 DetNet Packet Replication and Elimination Functions (PREF). It also 21 provides traceability of links/adjacencies where replication and loss 22 happen, in a manner that is agnostic to the forwarding information 23 (OAM). 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 4, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. On BIER - Traffic Engineering . . . . . . . . . . . . . . . . 3 62 4. BIER-TE-based Replication and Elimination Control . . . . . . 4 63 5. Elimination Function (Normative) . . . . . . . . . . . . . . 9 64 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 66 8. Security considerations . . . . . . . . . . . . . . . . . . . 12 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 11.2. Informative References . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 Deterministic Networking (DetNet) [I-D.ietf-detnet-problem-statement] 77 provides a capability to carry unicast or multicast data flows for 78 real-time applications with extremely low data loss rates and known 79 upper bound maximum latency [I-D.ietf-detnet-architecture]. 81 DetNet applies to multiple environments where there is a desire to 82 replace a point to point serial cable or a multidrop bus by a 83 switched or routed infrastucture, in order to scale, lower costs, and 84 simplify management. One classical use case is found in particular 85 in the context of the convergence of IT with Operational Technology 86 (OT), also referred to as the Industrial Internet. But there are 87 many others use cases [I-D.ietf-detnet-use-cases], for instance in in 88 professional audio and video, automotive, radio fronthauls, etc.. 90 The DetNet data plane alternatives [I-D.dt-detnet-dp-alt] studies the 91 applicability of existing and emerging dataplane techniques that can 92 be leveraged to enable DetNet properties in IP networks. One 93 critical feature in the dataplane is traceability, the capability to 94 control the activity of intermediate nodes on a packet. For 95 instance, if Replication and Elimination is applied to a packet, then 96 it is desirable to determine which node performed a certain copy of 97 that packet that is circulating in the network. Likewise, engineered 98 paths are required to support redundant transmission across disjoint 99 paths in support of DetNets PREF functios. 101 Traceability belongs to Operations, Administration, and Maintenance 102 (OAM) which is the toolset for fault detection and isolation, and for 103 performance measurement. More can be found on OAM Tools in "An 104 Overview of Operations, Administration and Maintenance (OAM) Tools" 105 [I-D.ietf-opsawg-oam-overview]. 107 This document proposes a new set to mechanisms based on [RFC8279] 108 (BIER) and more specifically BIER Traffic Engineering 109 [I-D.ietf-bier-te-arch] (BIER-TE) to control the process or Packet 110 Replication and Elimination Functions (PREF), and provide 111 traceability of these operations, in the DetNet dataplane. An 112 adjacency, which is represented by a bit in the BIER header, can 113 correspond in the dataplane to an Ethernet hop, a Label Switched 114 Path, or it can correspond to an IPv6 loose or strict source routed 115 path. 117 BIER-TE was primarily designed to carry multicast traffic, but there 118 is nothing prohibiting for it to be used with unicast traffic, and 119 the authors of this document think that for networks whose size 120 requirement match the supportable bitstring length (BSL) in BIER, it 121 can be a good choice as the forwarding plane specifically for DetNet 122 type traffic for both multicast and unicast traffic because it would 123 be a common solution for unicast and multicast (limiting the number 124 of different technologies a DetNet solution requires) and likely 125 provides the most flexible support for path engineering, replication 126 and elimination (PREF) and the novel OAM method described in this 127 document. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. On BIER - Traffic Engineering 137 [RFC8279] (BIER) is a network plane replication technique that was 138 initially intended as a new method for multicast distribution. In a 139 nutshell, a BIER header includes a bitmap that explicitly signals the 140 listeners that are intended for a particular packet, which means that 141 1) the sender is aware of the individual listeners and 2) the BIER 142 control plane is a simple extension of the unicast routing as opposed 143 to a dedicated multicast data plane, which represents a considerable 144 reduction in OPEX. For this reason, the technology faces a lot of 145 traction from Service Providers. 147 The simplicity of the BIER technology makes it very versatile as a 148 network plane signaling protocol. Already, a new Traffic Engineering 149 variation is emerging that uses bits to signal segments along a TE 150 path. 152 While BIER-TE was like BIER primarily developed for multicast 153 traffic, the authors think that it can equally be attractive for 154 unicast traffic requiring the DetNet resilience of multiple 155 transitions. If the topology of the network can well be represented 156 by standard BIER-TE bitstring sizes of e.g.: up to 256 bits, then 157 this would allow for a single technology for both unicast and 158 multicast. 160 BIER-TE supports a Traffic Engineered forwarding plane by explicit 161 hop-by-hop forwarding and loose hop forwarding of packets. 163 From the BIER-TE architecture, the key differences over BIER are: 165 o BIER-TE replaces in-network autonomous path calculation by 166 explicit paths calculated off path for example by a BIER-TE 167 controller host. 168 o In BIER-TE every BitPosition of the BitString of a BIER-TE packet 169 indicates one or more adjacencies - instead of a BFER as in BIER. 170 processing packets as a destination (BFER) is one of the possible 171 adjacency types. 172 o BIER-TE in each BFR has no routing table but only a BIER-TE 173 Forwarding Table (BIFT) indexed by SI:BitPosition and populated 174 with only those adjacencies to which the BFR should replicate 175 packets to. 177 The generic view of an adjacency can be over a link, a tunnel or 178 along a path segment. 180 4. BIER-TE-based Replication and Elimination Control 182 This document only needs to introduce new functionality to support 183 the Elimination Function and OAM. Creation of appropriate BIER-TE 184 packets is subject to to existing work. 186 In the solution described below, the encapsulation/insertion of flow- 187 identification and sequence number into packets is performed by a 188 function on the BFIR outside the scope of this document. A companion 189 document draft-huang-bier-te-encapsulation defines an encapsulation 190 for BIER-TE and BIER that can support flow-id and sequence-number ID. 191 Other encapsulations can be used as well, as long as they provide 192 these signaling elements and are supported by the Elimination 193 Function described in this document (e.g.: that the EF can read these 194 fields and therefore remove duplicates). In the remainder of this 195 document we will call this the extended BIER encapsulation and assume 196 that it is used when describing examples. Unless otherwise noted, we 197 assume that the BFIR performs encapsulation of some data flow packets 198 with an extended BIER header, indicates BIER-TE forwarding in it and 199 fills in flow-id and sequence number. It then fills in the bitstring 200 with two (or more) alternative paths/DAGs and sends off the packets 201 into the BIER-TE domain, replicating it itself if so indicated by the 202 bitstring. 204 In a nutshell, BIER-TE is used as follows: 206 o A controller computes a complex path, sometimes called a track, 207 which takes the general form of a ladder. The steps and the side 208 rails between them are the adjacencies that can be activated on 209 demand on a per-packet basis using bits in the BIER header. 211 ===> (A) ====> (C) ==== 212 // ^ | ^ | \\ 213 ingress (I) | | | | (E) egress 214 \\ | v | v // 215 ===> (B) ====> (D) ==== 217 Figure 1: Ladder Shape with Replication and Elimination Points 219 o The controller assigns a BIER domain, and inside that domain, 220 assigns bits to the adjacencies. The controller assigns each bit 221 to a replication node that sends towards the adjacency, for 222 instance the ingress router into a segment that will insert a 223 routing header in the packet. A single bit may be used for a step 224 in the ladder, indicating the other end of the step in both 225 directions. 227 ===> (A) ====> (C) ==== 228 // 1 ^ | 4 ^ | 7 \\ 229 ingress (I) |2| |6| (E) egress 230 \\ 3 | v 5 | v 8 // 231 ===> (B) ====> (D) ==== 233 Figure 2: Assigning Bits 235 o The controller activates the replication by deciding the setting 236 of the bits associated with the adjacencies. This decision can be 237 modified at any time, but takes the latency of a controller round 238 trip to effectively take place. Below is an example that uses 239 Replication and Elimination to protect the A->C adjacency. The 240 "(EF)" in the following pictures Owner column indicates the fact 241 that that BFR will perform the "Elimination Function" for received 242 BIER-TE packets before further processing/copying them. In this 243 example, only C performs EF. A (1) in the Example Bitstring 244 indicates that the bit is set, but that the actual adjacency is 245 not used by packets because this bit is shared with another 246 adjacency and the overall bitstring will make the packet only use 247 that other adjacency. This applies to bits 2 and 6. 249 +-------+-----------+--------+-------------------+ 250 | Bit # | Adjacency | Owner | Example Bitstring | 251 +-------+-----------+--------+-------------------+ 252 | 1 | I->A | I | 1 | 253 | 2 | A->B | A | 1 | 254 | | B->A | B | (1) | 255 | 3 | I->B | I | 0 | 256 | 4 | A->C | A | 1 | 257 | 5 | B->D | B | 1 | 258 | 6 | C->D | C (EF) | (1) | 259 | | D->C | D | | 260 | 7 | C->E | C (EF) | 1 | 261 | 8 | D->E | D | 0 | 262 +-------+-----------+--------+-------------------+ 264 Replication and Elimination Protecting A->C 266 Table 1: Controlling Replication 268 o The BIER header with the controlling BitString , flow-id and 269 sequence number is injected in the packet by the ingress node I 270 (BFIR). That node may act as a replication point, in which case 271 it may issue multiple copies of the packet, but for the purpose of 272 this example it will not do it, so that the two paths used in this 273 example only go from A to C, and therefore require explicit path 274 engineering. For example, bandwidth I-A and I-B may be more 275 limited and those paths being non long-haul may not warrant the 276 dual transmission. 278 ====> Repl ===> Elim ==== 279 // | ^ \\ 280 ingress | | egress 281 v | 282 Fwd ====> Fwd 284 Figure 3: Enabled Adjacencies 286 o For each of its bits that is set in the BIER header, the owner 287 replication point resets the bit used for a copy and transmits 288 towards the associated adjacency; to achieve this, the replication 289 point copies the packet and inserts the relevant data plane 290 information, such as next-hop label, MAC-address or source route 291 header (for a BIER-TE routed adjacency), towards the adjacency 292 that corresponds to the bit 294 +-----------+----------------+ 295 | Adjacency | BIER BitString | 296 +-----------+----------------+ 297 | I->A | 01011110 | 298 | A->B | 00011110 | 299 | B->D | 00010110 | 300 | D->C | 00010010 | 301 | A->C | 01001110 | 302 +-----------+----------------+ 304 BitString in BIER Header as Packet Progresses 306 Table 2: BIER-TE in Action 308 o Adversely, an elimination node on the path performs the 309 Elimination Function which will remove duplicate packets (same 310 flow-id, same sequence number) and performs a bitwise AND on the 311 BitStrings from the various copies of the packet that it has 312 received, before it forwards the packet with the resulting 313 BitString. Details of the Elimination Function are described 314 below. 316 +-----------+----------------+ 317 | Operation | BIER BitString | 318 +-----------+----------------+ 319 | D->C | 00010010 | 320 | A->C | 01001110 | 321 | | -------- | 322 | AND in C | 00000010 | 323 | | | 324 | C->E | 00000000 | 325 +-----------+----------------+ 327 BitString Processing at Elimination Point C 329 Table 3: BIER-TE in Action (cont.) 331 o In this example, all the transmissions succeeded and the BitString 332 at arrival has all the bits reset - note that the egress may be an 333 Elimination Point in which case this is evaluated after this node 334 has performed its AND operation on the received BitStrings). 336 +-------------------+-----------------------+ 337 | Failing Adjacency | Egress BIER BitString | 338 +-------------------+-----------------------+ 339 | I->A | Frame Lost | 340 | I->B | Not Tried | 341 | A->C | 00010000 | 342 | A->B | 01001100 | 343 | B->D | 01001100 | 344 | D->C | 01001100 | 345 | C->E | Frame Lost | 346 | D->E | Not Tried | 347 +-------------------+-----------------------+ 349 BitString indicating failures 351 Table 4: BIER-TE in Action (cont.) 353 o But if a transmission failed along the way, one (or more) bit is 354 never cleared. Table 4 provides the possible outcomes of a 355 transmission. If the frame is lost, then it is probably due to a 356 failure in either I->A or C->E, and the controller should enable 357 I->B and D->E to find out. A BitString of 00010000 indicates 358 unequivocally a transmission error on the A->C adjacency, and a 359 BitString of 01001100 indicates a loss in either A->B, B->D or 360 D->C; enabling D->E on the next packets may provide more 361 information to sort things out. 363 In more details: 365 The BIER header is of variable size, and a DetNet network of a 366 limited size can use a model with 64 bits if 64 adjacencies are 367 enough, whereas a larger deployment may be able to signal up to 256 368 adjacencies for use in very complex paths. The format of this header 369 is common to BIER and BIER-TE. 371 For the DetNet data plane, a replication point is an ingress point 372 for more than one adjacency, and an elimination point is an egress 373 point for more than one adjacency. 375 A pre-populated state in a replication node indicates which bits are 376 served by this node and to which adjacency each of these bits 377 corresponds. With DetNet, the state is typically installed by a 378 controller entity such as a PCE. The way the adjacency is signaled 379 in the packet is fully abstracted in the bit representation and must 380 be provisioned to the replication nodes and maintained as a local 381 state, together with the timing or shaping information for the 382 associated flow. 384 The DetNet data plane uses BIER-TE to control which adjacencies are 385 used for a given packet. This is signaled from the path ingress, 386 which sets the appropriate bits in the BIER BitString to indicate 387 which replication must happen. 389 The replication point clears the bit associated to the adjacency 390 where the replica is placed, and the elimination points perform a 391 logical AND of the BitStrings of the copies that it gets before 392 forwarding. 394 As is apparent in the examples above, clearing the bits enables to 395 trace a packet to the replication points that made any particular 396 copy. BIER-TE also enables to detect the failing adjacencies or 397 sequences of adjacencies along a path and to activate additional 398 replications to counter balance the failures. 400 Finally, using the same BIER-TE bit for both directions of the steps 401 of the ladder enables to avoid replication in both directions along 402 the crossing adjacencies. At the time of sending along the step of 403 the ladder, the bit may have been already reset by performing the AND 404 operation with the copy from the other side, in which case the 405 transmission is not needed and does not occur (since the control bit 406 is now off). 408 5. Elimination Function (Normative) 410 This section defines the normative behavior of the Elimination 411 Function with optional OAM sub-function. 413 The Elimination Function is performed logically on reception of BIER- 414 TE packets. It is therefore not part of the adjacencies or otherwise 415 assigned to a specific bit. "Logically" means that this 416 specification does not constrain implementations, especially on 417 multi-linecard/multi-chassis systems to perform EF on a physcial 418 egres module. It just implies that it has to happen before 419 replication to the bits in the bitstring. 421 TBD: In addition to being an ingres, EF could as well be modelled as 422 a new adjacency asigned to bits. The full adjacency of a bit could 423 then be a sequence of EF followed by one (or more) of existing 424 adjacencies. This is currently not considered by this document due 425 to the lack of identified need to support this option - e.g.: 426 problems that can not be equally/better be solved with EF logically 427 on ingres. 429 The Elimination Function is more formally written as EF(OAM, BIFT, 430 {flows}/*), and is configured like BIFTs from the BIER-TE controller 431 host and/or other future mechanisms. 433 OAM is boolean and indicates whether OAM function of bitwise AND of 434 received packet copies is performed. This OAM function requires 435 additional memory/processing over EF without OAM. Note that the OAM 436 function does not change the effect of the Elimination Function for 437 BFR/receivers - they will continue to just receive the first copy of 438 a packet. Instead, it will continue to track further copies solely 439 for the purpose of providing OAM information. This also requires 440 some timout or sequence number advancement to decide when to 441 terminate waiting for further copies of packets before considering 442 the OAM analysis of this packet to be complete. BFR supporting this 443 document SHOULD support the OAM sub-function. 445 BIFT indicates the for which to perform EF. Devices 446 SHOULD support enabling per EF. {flows}/* indicates the set of flows 447 for which EF operates (using the specified BIFT). Duplicate 448 elimination has to create per-flow state to remember which sequence 449 number packets for this flow where already received. In the case of 450 OAM also what bits where set in that received prior copy of the 451 packet. 453 When a device supports "*", then it will automatically allocate such 454 a flow-state for every new recognized flow and expire such flow state 455 after an operator determined timeout of activity - for example with a 456 default of 10 seconds. Dynamic allocation of flow-state may cause 457 some inital duplicates before this state is working and it makes the 458 BFR more vulnerable to state DOS attacks, but it will allows BIER 459 applications to send flows with the benefit of EF without the help of 460 the controller having to know and program every flow. 462 In the {flows} option, control procedures (e.g.: BIER-TE controller 463 host) indicate to the BFR explicitly the set of flows for which it 464 should install/operate the EF function. Note that the flow-id in the 465 extended BIER encapsulation is the combination of BFIR-ID and entropy 466 field of the BIER header. 468 BFR supporting this document MUST support the {flows} option and MAY 469 support the "*" option. 471 The following picture explains the results of EF being performed on 472 ingres in a typical example: 474 I1 475 | 476 v 477 /---------- B1 ------------\ 478 | | 479 \-- B3 -- B4 -- B5 -- B6 --/ 480 | | | | 481 | | | | 482 O1 O2 O3 O4 484 Figure 4: EF with Rings 486 Consider a simple ring where BFIR I1 generates BIER-TE packets. The 487 bitstring indicates that the packet is sent hop-by-hop 488 counterclockwise B1->B3->B4->B6 and counterclockwise 489 B1->B6->B5->B4->B3. Bits for BFER O1, O2, O3 and O4 are also set. 490 B3,B4,B5,B6,B7 perform EF. The result of this setup is that B2 491 creates two copies of the packets received from I1, one going to B6, 492 the other to B3. Assume B4 first received the counter-clockwise copy 493 from B3 and B5 the clockwise copy from B6. They will both forward 494 these packets to each other because those where the first copies they 495 saw, but the would block these second copies. Therefore only the 496 link B4<->B5 will have carried the packet copy twice (once in each 497 direction). All the other ring links will only carry one copy of the 498 packet. 500 This is notably different from schemes where EF is not performed 501 before replication, but afterwards. In those schemes, both copies of 502 the packets would flow counterclockwise around (most of) the ring, 503 ocupying more bandwidth. 505 6. Summary 507 With the addition of the functions of this document, BIER-TE becomes 508 a potential option for the DetNet dataplane specifically beneficial 509 when PREF (replication and elimination) is required for resilience 510 (to reduce packet loss). For DetNet multicast but also DetNet 511 unicast. The unique capabilities of this approach areare: 513 o Explicit per-packet path selection for packet. Multicast and 514 Unicast. 515 o Control which replication take place on a per packet basis, so 516 that replication points can be configured but not actually 517 utilized 518 o Trace the replication activity and determine which node replicated 519 a particular packet 520 o Measure the quality of transmission of the actual data packet 521 along the replication segments and use that in a control loop to 522 adapt the setting of the bits and maintain the reliability. 524 7. Implementation Status 526 A research-stage implementation of the forwarding plane fir a 6TiSCH 527 IOT use case was developed at Cisco's Paris Innovation Lab (PIRL) by 528 Zacharie Brodard. It was implemented on OpenWSN Open-source firmware 529 and tested on the OpenMote-CC2538 hardware. It implements the header 530 types 15,16, 17, 18 and 19 (bit-by-bit encoding without group ID) in 531 order to allow a BIER-TE protocol over IEE802.15.4e. 533 This work was complemented with a Controller-based control loop by 534 Hao Jiang. The controller builds the complex paths (called Tracks in 535 6TiSCH) and decides the setting oif the BitStrings in real time in 536 order to optimize the delivery ratio within a minimal energy budget. 538 Links: 540 github: https://github.com/zach-b/openwsn-fw/tree/BIER 541 OpenWSN firmware: https://openwsn.atlassian.net/wiki/pages/ 542 viewpage.action?pageId=688187 543 OpenMote hardware: http://www.openmote.com/ 545 8. Security considerations 547 TBD. 549 9. IANA Considerations 551 This document has no IANA considerations. 553 10. Acknowledgements 555 The method presented in this document was discussed and worked out 556 together with the DetNet Data Plane Design Team: 558 Jouni Korhonen 559 Janos Farkas 560 Norman Finn 561 Olivier Marce 562 Gregory Mirsky 563 Pascal Thubert 564 Zhuangyan Zhuang 566 The authors also like to thank the DetNet chairs Lou Berger and Pat 567 Thaler, as well as Thomas Watteyne, 6TiSCH co-chair, for their 568 contributions and support to this work. 570 11. References 572 11.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, 576 DOI 10.17487/RFC2119, March 1997, 577 . 579 11.2. Informative References 581 [I-D.dt-detnet-dp-alt] 582 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 583 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 584 and Solution Alternatives", draft-dt-detnet-dp-alt-04 585 (work in progress), September 2016. 587 [I-D.ietf-bier-te-arch] 588 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 589 Engineering for Bit Index Explicit Replication (BIER-TE)", 590 draft-ietf-bier-te-arch-00 (work in progress), January 591 2018. 593 [I-D.ietf-detnet-architecture] 594 Finn, N., Thubert, P., Varga, B., and J. Farkas, 595 "Deterministic Networking Architecture", draft-ietf- 596 detnet-architecture-04 (work in progress), October 2017. 598 [I-D.ietf-detnet-problem-statement] 599 Finn, N. and P. Thubert, "Deterministic Networking Problem 600 Statement", draft-ietf-detnet-problem-statement-02 (work 601 in progress), September 2017. 603 [I-D.ietf-detnet-use-cases] 604 Grossman, E., "Deterministic Networking Use Cases", draft- 605 ietf-detnet-use-cases-14 (work in progress), February 606 2018. 608 [I-D.ietf-opsawg-oam-overview] 609 Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 610 Weingarten, "An Overview of Operations, Administration, 611 and Maintenance (OAM) Tools", draft-ietf-opsawg-oam- 612 overview-16 (work in progress), March 2014. 614 [I-D.ietf-spring-segment-routing] 615 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 616 Litkowski, S., and R. Shakir, "Segment Routing 617 Architecture", draft-ietf-spring-segment-routing-15 (work 618 in progress), January 2018. 620 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 621 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 622 Explicit Replication (BIER)", RFC 8279, 623 DOI 10.17487/RFC8279, November 2017, 624 . 626 Authors' Addresses 628 Pascal Thubert (editor) 629 Cisco Systems 630 Village d'Entreprises Green Side 631 400, Avenue de Roumanille 632 Batiment T3 633 Biot - Sophia Antipolis 06410 634 FRANCE 636 Phone: +33 4 97 23 26 34 637 Email: pthubert@cisco.com 639 Toerless Eckert 640 Huawei USA - Futurewei Technologies Inc. 641 2330 Central Expy 642 Santa Clara 95050 643 USA 645 Email: tte+ietf@cs.fau.de 646 Zacharie Brodard 647 Ecole Polytechnique 648 Route de Saclay 649 Palaiseau 91128 650 FRANCE 652 Phone: +33 6 73 73 35 09 653 Email: zacharie.brodard@polytechnique.edu 655 Hao Jiang 656 Telecom Bretagne 657 2, rue de la Chataigneraie 658 Cesson-Sevigne 35510 659 FRANCE 661 Phone: +33 7 53 70 97 34 662 Email: hao.jiang@telecom-bretagne.eu