idnits 2.17.1 draft-huang-bier-te-encapsulation-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 date (March 5, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-00 == Outdated reference: A later version (-04) exists of draft-ietf-detnet-dp-sol-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Huang 3 Internet-Draft T. Eckert 4 Intended status: Experimental N. Wei 5 Expires: September 6, 2018 Huawei 6 P. Thubert 7 Cisco 8 March 5, 2018 10 Encapsulation for BIER-TE 11 draft-huang-bier-te-encapsulation-00 13 Abstract 15 This document proposes an enhanced encapsulation for BIER to support 16 BIER, BIER-TE and a control word. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 6, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. BIER-TE Encapsulation (normative) . . . . . . . . . . . . . . 3 55 2.1. BT bit - Simultaneous support for BIER and BIER-TE . . . 3 56 2.2. BIFT-ID . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Control Word and flows . . . . . . . . . . . . . . . . . 3 58 2.4. Header format & fields . . . . . . . . . . . . . . . . . 4 59 3. BIER-TE based resilience operations (informational) . . . . . 5 60 4. BitStringLength (BSL) considerations (informational) . . . . 6 61 4.1. IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.2. Multicast in L3VPN . . . . . . . . . . . . . . . . . . . 8 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 [BIER-TE-ARCH] specifies BIER-TE: Traffic Engineering for Bit Index 74 Explicit Replication (BIER). It builds on the BIER architecture as 75 described in RFC8279 [RFC8279], but uses every BitPosition of the 76 BitString of a BIER-TE packet to indicate one or more adjacencies 77 instead of a BFER as in BIER. 79 This document proposes an enhanced version of the MPLS and non-MPLS 80 encapsulation for BIER packets to support both BIER and BIER-TE. It 81 is based on RFC8296 [RFC8296]. 83 This enhanced encapsulation also adds support for a control word in 84 the header and discusses it. Finally, the document discusses 85 BitStringLength (BSL) size requirements in implementations for 86 informational reasons to help aide implementors to determine an 87 appropriate BSL. 89 1.1. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC2119 [RFC2119]. 95 2. BIER-TE Encapsulation (normative) 97 2.1. BT bit - Simultaneous support for BIER and BIER-TE 99 This document supports mixed BIER and BIER-TE forwarding in a domain. 100 Either or both of them may be used in a domain. The overall solution 101 to support this depends on additional signaling such as existing BIER 102 ISIS/BGP signaling. Architecturally, every SD SHOULD only use a 103 single Type of BIER: BIER or BIER-TE. Note that this document will 104 use the abbreviation BT to refer to the Bier Type. 106 In the presence of BIER and BIER-TE together in the network, there is 107 always a risk of receiving a packet which is meant to be of one BT 108 and processing it through a BIFT of the other BT. This can come from 109 misconfiguration even in the face of signalling via IGP/BGP. The 110 risk increases also when packets are generated modular from 111 applications on PE or other sources and could use both BTs. To 112 resolve this, the header includes a bit to indicate the BT. If the 113 BT of a packet is inconsistent with the BT of the BIFT on the BFR, 114 the BFR MUST NOT forward it. OAM actions MAY be triggered (subject 115 to future work). 117 Note that the TTL field of the existing BIER packet header (or of IP 118 packets) spends 7 bits on loop prevention. One bit for the BT is a 119 comparably low cost to protect against a similar degree of problems. 121 Indicating the BT explicitly through a bit in the encapsulation is 122 called the "explicit" option. Relying solely on the BT of the BIFTs 123 is called "implicit" option. In this version of the document, we 124 choose the explicit option for reasons outlined above. 126 2.2. BIFT-ID 128 Like in the original BIER header, the semantic of the BIFT-id of the 129 header is that it is representing a on the BFR receiving 130 the packet. In the case of MPLS forwarding, the expectation is that 131 the protocols to signal label ranges would be extended to also signal 132 label ranges for the SD using BIER-TE. This is subject to the work 133 of other documents. In the case of non-MPLS forwarding, no 134 additional signaling may be neccessary, and BIER and BIER-TE packets 135 using the encapsulation of this document would equally use the BIFT- 136 ID encoding as described in [BIER-non-MPLS]. 138 2.3. Control Word and flows 140 This document adds a "control word" to the BIER packet header to 141 allow that BIER or BIER-TE packets with this header could be used as 142 a DetNet Data Plane, independent of MPLS encapsulation, see 143 [I-D.ietf-detnet-dp-sol], section 5.3 (in revision 01). 145 The control word provides a sequence number, therefore allowing to 146 correct reordering and discover packet loss. The primary use though 147 is resilient dual-path transmission of two copies of the same packet 148 via disjoint paths. This is specifically a desirable use-case with 149 BIER-TE because it allows the engineering of such disjoint paths. 150 The flow to which the sequence number in the control word applies is 151 . 153 Note: The justification to carry a control word in the BIER 154 encapsulation is similar to carrying the BFIR-ID in it. Initially, 155 both could be seen as primarily required on BIER domain edge-nodes as 156 part of the overlay using BIER, but not by BIER/BIER-TE itself 157 directly. See Section 3 for more explanation how the resilience 158 mechanism requiring the control word would work. Compared to the 159 BFIR-ID, there is also the option to leverage it within BIER-TE 160 itself. The details of that operations is subject to other 161 specifications. 163 The authors think that the overhead of the control word is always 164 acceptable for BIER-TE. For BIER, the use of this extended header 165 version is optional, therefore BIER packets that need a control word 166 would use this version of the header, those that do not need it would 167 use version 1. If this overhead is considered to not be acceptable 168 for all BIER-TE packets, the encoding could make those 32 bits 169 optional through the use of one of the reserved bits or version 170 numbers or by using a bit in the header to indicate whether the 171 control word is present or not. 173 2.4. Header format & fields 174 0 1 2 3 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | BIFT-id | TC |S| TTL | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 |Nibble | Ver | BSL | Entropy (flow-id) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |OAM|T|R| DSCP | Proto | BFIR-id | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |0 0 0 0| Control Word (sequence number) | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | BitString (first 32 bits) ~ 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 ~ ~ 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 ~ BitString (last 32 bits) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 0 1 2 3 193 All header fields not described below are left unchanged from 194 [BIER-TE-ARCH] 196 T: This 1-bit field identifies that the packet is to be forwarded as 197 a BIER packet (0) or a BIER-TE paket(1). 199 Ver: The version of this header format is 2. 201 R: Reserved - unchanged (just reduced by one bit from version). Must 202 be set to 0. 204 Entropy: Unchanged, but double-used as part of the flow-identifier 205 together with the control word 207 Control Word: The control word in the terminology of MPLS pseudowires 208 (where it originates from) is the full 32 bits. For detnet, the 209 current target is 28 bits of sequence number and 4 bits 0 preceeding 210 it. 212 3. BIER-TE based resilience operations (informational) 214 This section discusses how resilience operations with the help of the 215 sequence number in the control word of the header in this document 216 can be operated as an overlay (BFIR-BFER) function but also points 217 out that it could become an integral (optional) part of BIER-TE 218 itself. This section is solely informational. The planned document 219 to describe the BIER-TE forwarding aspects of resilience operations 220 is [I-D.thubert-bier-replication-elimination]. 222 The BFIR determines - potentially with the help of a BIER-TE 223 Controller Host (controller) - a bitstring that forms two disjoint 224 DAGs (Directed Acyclic Graphs) through the BIER-TE domain towards the 225 same set of BFER. In addition, an entropy value is decided (by BFIR 226 and/or controller) and signalled to the BFER. The BFER can therefore 227 set up "duplicate elimination state": The BFIR increments the 228 sequence number with every packet of the flow it sends. The BFER 229 assign packets to a flow by and perform duplicate 230 elimination on them. 232 Note that the bitstring as seen on the receiving BFER can provide 233 additional diagnostics, for example the bits not reset by forwarding 234 in BIER-TE give an indication about which path the BIER-TE packet was 235 forwarded. 237 Instead of simply considering this protected mode of operations 238 solely an end-to-end (BFIR/BFER) function, it could also be more 239 flexibly embedded into BIER-TE itself, allow to provide in-BIER-TE 240 segmented Packet Replication and (duplicate) Eliminiation Functions 241 (PREF) definable by the bitstring of a BIER-TE packet. This could be 242 achieved by adding to BIER-TE forwarding functions new adjacency 243 types for duplication with sequence-number generation and duplicate- 244 elimination. The ability to perform such processing as part of BIER- 245 TE itself is the primary reason to ensure that all the necessary 246 elements for such operations are part of the BIER-TE header itself. 248 4. BitStringLength (BSL) considerations (informational) 250 BIER-TE uses each BitPostion to indicate the adjacencies instead of a 251 BFER as in BIER, it therefore consumes more BitPostions than BIER. 252 In BIER-TE, the number of adjacencies passed by one BIER-TE packet 253 MUST be less than the value of BitString length (BSL). The BIER-TE 254 architecture discusses a range of options to reduce the number of 255 bits for intermediate hops through various BIER-TE adjacencies and 256 how to use them. 258 The maximum supported BSL has a different impact in BIER-TE than it 259 has in BIER: A smaller maximum supported BSL in BIER primarily leads 260 to less replication efficiency: With a BSL of 256, BIER can be up to 261 256 more efficient than unicast (1 packet for 256 receivers). In 262 BIER-TE, the BSL also limits the size of the topology towards BFER 263 and the alternative paths that can explicitly be engineered to reach 264 the BFER. One simple guess is that 50% of bits in a bitstring may be 265 required for intermediate hops, therefore requiring about double the 266 amount of bits as BIER - as the cost of being able to engineer pats. 268 So far, there is no comprehensive analysis of the number of required 269 bits for specific scenarios in BIER-TE. The following subsections 270 give two examples of such scenarios and how to use and save BIER-TE 271 bits for intermedia hops. 273 4.1. IPTV 275 Multicast is widely used for IPTV services by simultaneously 276 delivering a single stream of video to thousands of recipients. 277 Currently, PIM is widely used to provide multicast capability usually 278 from core router(CR) to provider edges (PEs). And the multicast tree 279 is usually constructed in the hierarchical way. The end users using 280 PIM/IGMP to request the multicast data. BIER can be well used in 281 from CR to those PEs. The number of hops from multicast source (CR) 282 which could be BFIRs, to the multicast receivers (PE) which can be 283 regarded as BRERs is usually no more than 10. BIER-TE will be useful 284 in the cases where different video channels can have different 285 transport paths to achieve load balancing. 287 To save the bit consumption, 2 ways could be used: 289 1. Multiple BFRs and routes are required to receive the same data. 290 These BFRs or links can share one bit. 292 2. Different bits can be used for pruning. But these bits can be 293 reused in similar but different groups. 295 Considering an example illustrated as following: 297 +----+ 298 |BFIR| 299 +-+--+ 300 | 301 | 302 +-------------------------+---| 303 | | 304 | | 305 | | 306 +---+---+ +----+----+ 307 | BFR1 | .... | BFRn | 308 +---+---+ +----+----+ 309 | | 310 | ... 311 +------|-------+ +------+---------+ 312 | | | | | | 313 | | | | | | 314 +--+----------------+ +---------+-----------+ 315 | BFER1 | | BFERn | 316 +--+----------------+ +---------------------+ 318 BRF1 and BFRn, and other BFRs in between, can share one bit because 319 they are receiving all the content and don't need pruning. From BFR1 320 to BFER1, there are 3 ways to reach BFER1. So these 3 ways can be 321 assigned with different bits. But these 3 bits can be reused in the 322 group from BFRn to BFERn, and other groups in between, which share 323 the same topology as the group from BFR1 to BFER1. 325 BIER-TE can be well implemented using these 2 ways to save the bit 326 consumption in IPTV networks with the similar topologies like the 327 above example. 329 4.2. Multicast in L3VPN 331 MVPN is a technology to deploy multicast service in an existing VPN 332 or as part of a transport infrastructure. Multicast data is 333 transmitted between private networks over a VPN infrastructure by 334 encapsulating the original multicast packets. PE routers are 335 connected to these private networks either containing receivers or 336 senders. 338 There are several multicast applications widely using the MVPN 339 deployment. For example, L3VPN multicast service offered by service 340 providers to enterprise customers, and video transport applications 341 for separation between different customers: One content provider may 342 provider video wholesale service to another, or multiple content 343 provider may share one network to transport video from headend. 344 Especially the latter case, network SLAs should be guaranteed as the 345 original video content is precious. Thus, traffic engineering is 346 required. 348 According to the current implementations, the scale of a MVPN network 349 usually contains less than several hundreds of PEs, and hundreds of 350 core routers which are connected in full mesh, like following figure 351 illustrated. 353 +--+ +----+ +----+ +--+ 354 |PE+----------+ CE +---------+ CE +--------+PE| 355 ++-+ +-+--+ +--+-+ +--+ 356 | | | | 357 | | | | 358 ++-+ +-+--+ +--+-+ +-++ 359 |PE+----------+ CE +---------+ CE +---------+PE| 360 +--+ +----+ +----+ +--+ 362 In such a case, the ways in Section 7.5.2 of [BIER-TE-ARCH] can be 363 used by regarding the CE area as the Core. Based on this, current 364 BIER design is sufficient to be reused in BIER-TE. 366 5. Acknowledgements 368 TBD. 370 6. Security Considerations 372 The security considerations are in compliance with BIER-TE 373 architecture [BIER-TE-ARCH] and BIER encapsulation RFC8296 [RFC8296]. 374 And the content in this document does not create any other attacks or 375 security concerns. 377 7. IANA Considerations 379 TBD. 381 8. References 383 8.1. Normative References 385 [BIER-non-MPLS] 386 Wijnands, I., Xu, X., and H. Bidgoli, "An Optional 387 Encoding of the BIFT-id Field in the non-MPLS BIER 388 Encapsulation", ID draft-wijnandsxu-bier-non-mpls-bift- 389 encoding-01 (work in progress), August 2017. 391 [BIER-TE-ARCH] 392 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 393 Engineering for Bit Index Explicit Replication BIER-TE", 394 ID draft-ietf-bier-te-arch-00 (work in progress), January 395 2018. 397 [I-D.thubert-bier-replication-elimination] 398 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 399 TE extensions for Packet Replication and Elimination 400 Function (PREF) and OAM", draft-thubert-bier-replication- 401 elimination-03 (work in progress), March 2018. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 409 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 410 Explicit Replication (BIER)", RFC 8279, 411 DOI 10.17487/RFC8279, November 2017, 412 . 414 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 415 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 416 for Bit Index Explicit Replication (BIER) in MPLS and Non- 417 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 418 2018, . 420 8.2. Informative References 422 [I-D.ietf-detnet-dp-sol] 423 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 424 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 425 "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- 426 sol-01 (work in progress), January 2018. 428 Authors' Addresses 430 Rachel Huang 431 Huawei 432 101 Software Avenue, Yuhua District 433 Nanjing 210012 434 China 436 Email: rachel.huang@huawei.com 437 Toerless Eckert 438 Huawei USA - Futurewei Technologies Inc. 439 2330 Central Expy 440 Santa Clara 95050 441 USA 443 Email: tte+ietf@cs.fau.de 445 Naiwen Wei 446 Huawei 448 Email: weinaiwen@huawei.com 450 Pascal Thubert 451 Cisco Systems 452 Village d'Entreprises Green Side 453 400, Avenue de Roumanille 454 Batiment T3 455 Biot - Sophia Antipolis 06410 456 FRANCE 458 Phone: +33 4 97 23 26 34 459 Email: pthubert@cisco.com