idnits 2.17.1 draft-zcxh-bier-te-forwarding-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 : ---------------------------------------------------------------------------- ** There are 20 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([I-D.eckert-bier-te-arch]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2017) is 2410 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VRF' is mentioned on line 246, but not defined == Outdated reference: A later version (-06) exists of draft-eckert-bier-te-arch-05 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-08 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER WG Yongqing. Zhu 3 Internet-Draft Huanan. Chen 4 Intended status: Standards Track China Telecom 5 Expires: March 23, 2018 Quan. Xiong 6 Fangwei. Hu 7 ZTE Corporation 8 September 19, 2017 10 BIER-TE Forwarding 11 draft-zcxh-bier-te-forwarding-00.txt 13 Abstract 15 Traffic Engineering for Bit Index Explicit Replication (BIER-TE) 16 shares part of architecture, definition and packet format with Bit 17 Index Explicit Replication (BIER) according to the introduction in 18 [I-D.eckert-bier-te-arch]. But BIER-TE supports the traffic 19 engineering by explicit hop-by-hop forwarding and loose hop 20 forwarding of packets. 22 This document proposes a set of extensions to realize the BIER-TE 23 forwarding including the assignment of BitPositions to adjacencies 24 and the configuration of Bit Index Forwarding Table (BIFT). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 23, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Operation Overview . . . . . . . . . . . . . . . . . . . 3 63 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. BIER-TE Forwarding . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. The Assignment of BitPositions to Adjacencies . . . . . . 5 66 2.2. The configuration of BIFT . . . . . . . . . . . . . . . . 5 67 3. BIER-TE Forwarding Example . . . . . . . . . . . . . . . . . 6 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 Traffic Engineering for Bit Index Explicit Replication (BIER-TE) 77 shares part of architecture, definition and packet format with Bit 78 Index Explicit Replication (BIER) according to the introduction in 79 [I-D.eckert-bier-te-arch]. But BIER-TE supports the traffic 80 engineering by explicit hop-by-hop forwarding and loose hop 81 forwarding of packets. 83 [I-D.ietf-bier-mpls-encapsulation] specifies a BIER encapsulation 84 that BIER header contains a bitstring in which each bit represents 85 one egress router in the domain. But in BIER-TE, every BitPosition 86 of the BitString of a BIER-TE packet indicates one or more 87 adjacencies which BFRs will transit packets passing though. BFRs 88 recognizes BitStrings or packets for every Sub-Domain-ID(SD), 89 BitStringLength(BSL) and Set Identification(SI) combination. 91 [I-D.eckert-bier-te-arch] discussed the process of the BIER-TE 92 forwarding including Bit Index Forwarding Table (BIFT) and forwarding 93 example. The BIER-TE controller host determines and assigns the 94 BitPositions to the adjacencies which explicit paths can be built 95 through them and then pushes the BitPositions/adjacencies to the BIFT 96 which indexed by SI:BitPosition. The BIFT is configured to the 97 routers known as "Bit-Forwarding Router" (BFR) which should be able 98 to send packets to adjacencies connecting to other BFRs. 100 1.1. Motivation 102 As defined in [I-D.ietf-bier-architecture], a multicast data packet 103 enters a domain at a "Bit-Forwarding Ingress Router" (BFIR), and 104 leaves at one or more "Bit-Forwarding Egress Routers" (BFERs). For a 105 multicast forwarding, the controller host needs to assign lots of 106 BitPositions and use multiple SI and BSL within the same sub-domain. 107 The distinct SD, BSL and SI combinations MUST be mapped to more than 108 one BitStrings and carried in different packets. 110 As discussed in [I-D.eckert-bier-te-arch], the BIER-TE controller 111 host tracks the BFR topology of the BIER-TE domain and determines the 112 BitPositions and related BIFTs.Different with BIER, the BIFT related 113 to the BitPositions which associated with a particular SD, BSL and SI 114 combination need to be built throughout the whole network in BIER-TE. 116 The BFRs need to forward the packets based on the BitString and BIFT 117 with a SD, BSL and SI combination.The BitPositions of these 118 adjacencies passing through BFIR to each BFER must be assigned in the 119 same SD, BSL and SI combination to ensure the multicast flow be 120 forwarded to the BFER within the same packet. The assignment of 121 BitPositions and the configuration of BIFT should be taken to 122 considerations in detail. 124 1.2. Operation Overview 126 Based on the discussion above, this document proposes a set of 127 extensions to realize the BIER-TE forwarding including the assignment 128 of BitPositions to adjacencies and the configuration of BIFT. The 129 main point is that the assignment of BitPositions and the 130 configuration of the BIFT MUST be accomplished based on the explicit 131 paths of multicast flow and be completed after the BFIR and BFERs are 132 configured. The controller host SHOULD take charge of the management 133 about multicast flow information. 135 The controller host dosen't need to track the topology to determine 136 what adjacencies require BitPositions. The controller host MAY 137 compute the explicit paths from BFIR to each BFER first and then 138 assign the BitPositions including SD,BSL and SI combination to the 139 adjacencies which the paths passing though respectively based on the 140 policy. The assignment results need to meet the requirement that the 141 BitPositions of the adjacencies from BFIR to each BFER could belong 142 to a SD, BSL and SI combination. And then the controller pushes 143 those BitPositions/adjacencies to the BIFT of the BFRs. The 144 configuration of BIFT is not completed in BFR topology but 145 incremental configuration based on the requirement of multicast 146 flows. 148 1.3. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 2. BIER-TE Forwarding 156 This document proposes a general mechanism to extend the process in 157 [I-D.eckert-bier-te-arch]. The operation for BIER-TE forwarding is 158 as follows. 160 The controller host which representing the control plane of BIER-TE 161 discovers the network topology information. 163 When the multicast flows needs to be forwarded in the BIER-TE 164 network, the controller host tracks the multicast flow overlay to 165 determine which multicast flow needs to be sent by a BFIR to which 166 BFERs. 168 And based on the topology, the controller host needs to calculate the 169 explicit paths from BFIR to every BFER across the BIER-TE domain 170 according to the algorithms which is outside the scope of this 171 document. 173 The BIER-TE controller host assigns the BitPositions including SD, 174 BSL and SI combination to the adjacencies according to the assignment 175 method and policy as discussed on the session 3.1. The BIFT for 176 related BFRs which the explicit paths passing through SHOULD be 177 populated by the controller host and configured once the BitPositions 178 assigned with the detail in session 3.2 . 180 Finally, the BIER-TE controller host calculates the BitStrings 181 according to the explicit paths and its related explicit SD, BSL and 182 SI combination and pushes them into the BFIR as discussed in 183 [I-D.eckert-bier-te-arch]. 185 Once the BIFTs and BitStrings was programmed into the data plane of 186 BFRs by the BIER-TE controller host, they can be used to forward 187 packets according to the rules specified in the BIER-TE forwarding 188 Procedures defined in [I-D.eckert-bier-te-arch]. 190 2.1. The Assignment of BitPositions to Adjacencies 192 The BIER-TE controller host assigns the BitPositions including SD, 193 BSL and SI combination to the adjacencies based on the explicit paths 194 passing though. One or more BitPositions MAY be assigned to an 195 adjacency with the different SD, BSL and SI combination. The 196 assignment need to meet the requirement that the BitPositions of the 197 adjacencies from BFIR to each BFER could belong to a SD, BSL and SI 198 combination. 200 This document proposes a merthord for the assignment of BitPosition 201 to adjacencies and defines two types of the assignment policy of 202 BitPositions as following. 204 If the multicast flow needs to be sent from a BFIR to M BFERs along M 205 explicit paths, the controller host MAY assign BitPositions for all 206 adjacencies of M explicit paths with the K sets of SD, BSL and SI 207 combinations which K M according to the assignment policy. 209 EXCLUSIVE-TYPE: Each multicast flow MAY use one or more SD, BSL and 210 SI combination exclusively. 212 SHARING-TYPE: More than one multicast flows MAY share the same SD, 213 BSL and SI combination. If the adjacencies of a path have been 214 assigned to the same SI except some adjacencies which have not been 215 assigned ever, the controller host SHOULD assign BP for these no- 216 assigned adjacencies the same SI with the others. The premise is the 217 index of the SI is enough for the assignment. 219 OPTIONALY, the policy of assignment MAY be configured by customers 220 based on the requirement outside of the document. 222 2.2. The configuration of BIFT 224 The BIFT is populated by the BIER-TE control plane and exists in all 225 BFRs as defined in [I-D.eckert-bier-te-arch]. This document proposes 226 an extension to BIFT as the table 1 shown. 228 BIFT-id represents a particular BIFT and corresponds to a particular 229 combination of SD, BSL, and SI. The value of BITF-id MUST be 230 assigned by BIER-TE controller host and unique throughout the BIER-TE 231 domain. The BIFT-id can be used in BIER encapsulation as discussed 232 in [I-D.ietf-bier-mpls-encapsulation]. BIFT-type indicates the type 233 of BIFT including BIER and BIER-TE. 235 Table 1 Extension of BIFT 236 ------------------------------------------------------------------------------------ 237 | Index: | Adjacencies: | 238 | BIFT-id () : BitPosition | or one or more per entry | 239 | BIFT-type: BIER-TE | 240 ==================================================================================== 241 | BIFT-id:1 | forward_connected(interface,neighbor,DNR) | 242 ------------------------------------------------------------------------------------ 243 | BIFT-id:2 | forward_connected(interface,neighbor,DNR) | 244 | | forward_connected(interface,neighbor,DNR) | 245 ------------------------------------------------------------------------------------ 246 | BIFT-id:3 | local_decap([VRF]) | 247 ------------------------------------------------------------------------------------ 248 | BIFT-id:4 | forward_routed([VRF,]l3-neighbor) | 249 ------------------------------------------------------------------------------------ 250 | BIFT-id:5 | | 251 ------------------------------------------------------------------------------------ 252 | BIFT-id:6 | ECMP({adjacency1,...adjacencyN}, seed) | 253 ------------------------------------------------------------------------------------ 254 ... 255 | ID:BitStringLength | ... | 256 ------------------------------------------------------------------------------------ 258 The BIFT in one sub-domain of a BFR is a table indexed by BIFT- 259 id:BitPosition which populated by the controller host and configured 260 once the BitPositions assigned. One or more BitPositions in table 261 MAY correspond to the same adjacency. The configuration of BIFT is 262 not completed before the service deployment but incremental 263 configuration based on the requirement of multicast flows. The 264 difference is that the configuration of BIFT is not to replace the 265 table in BFR but update and add the BIFT-id:BitPosition items into 266 BIFT. 268 When links or nodes fail or recover in the topology or service is 269 deleted by customers, the related items need to be removed from BIFT 270 with little effect on other BIFT items of other flows. 272 3. BIER-TE Forwarding Example 274 Step by step example of basic BIER-TE forwarding and using the 275 network defined in [I-D.eckert-bier-te-arch]. The extension process 276 for BIER-TE forwarding is shown as follows. 278 [Bier-Te Controller Host] 279 / | \ 280 v v v 282 | a13 a1 | 283 +- BFIR2 --+ | 284 | | a2 a6 | LAN2 285 | +-- BFR3 --+ | 286 | | | a7 a11 | 287 Src -+ +-- BFER1 --+ 288 | | a3 a8 | | 289 | +-- BFR4 --+ +-- Rcv1 290 | | | | 291 | | 292 | a14 a4 | 293 +- BFIR1 --+ | 294 | +-- BFR5 --+ a10 a12 | 295 LAN1 | a5 a9 +-- BFER2 --+ 296 | +-- Rcv2 297 | 298 LAN3 300 IP |..... BIER-TE network ......| IP 302 Figure 1 Forwarding Example 304 aXX indicate the Adjacencies number assigned by the BIER-TE 305 controller host according to the BIER-TE topology. 307 1, The BIER-TE controller discovers the network topology information 308 and assigns the Adjacencies number for the adjacencies as the figure 309 shown. 311 2, The BIER-TE controller tracks the multicast flow overlay to 312 determine what multicast flow needs to be sent by which BFIR to which 313 BFERs. Example is from BFIR2 to BFER1 and BFER2. 315 3, The BIER-TE controller computes the two optimal paths from BFIR2 316 to BFER1 and from BFIR2 to BFER2 respectively. The result is shown 317 as follows. 319 a.BFIR2->BFER1:SRC->a13->a2->a7->a11->RCV 321 b.BFIR2->BFER2:SRC->a13->a2->a8->a5->a10->a12->RCV 323 4, The BIER-TE controller host assigns BP for the path from BFIR2 to 324 BFER1 with the assignment method and the policy type is EXCLUSIVE- 325 TYPE. SD =0, SI=0, BSL=4, BIFT-id = 0, the BIFT-id:BitPosition is as 326 follows: 328 a13->0:1 330 a2->0:2 332 a7->0:3 334 a11->0:4 336 5, The BIER-TE controller host assigns BP for the path from BFIR2 to 337 BFER2. SD =0, SI=1, BSL=8, BIFT-id = 1, the BIFT-id:BitPosition is 338 as follows: 340 a13->1:1 342 a2->1:2 344 a8->1:3 346 a5->1:4 348 a10->1:5 350 a12->1:6 352 6, Based on the assignment, the BIER-TE controller populates the 353 according BIFTs and forwards it to the BFRs as the following shown. 355 BIFT BFIR2: 357 0:1: local_decap() 359 1:1: local_decap() 361 0:2: forward_connected(BFR3) 363 1:2: forward_connected(BFR3) 365 BIFT BFR3: 367 0:3: forward_connected(BFER1) 369 1:3: forward_connected(BFR4) 371 BIFT BFER1: 373 0:4: local_decap() 375 1:3: forward_connected(BFR4) 377 BIFT BFIR1: 379 1:4: forward_connected(BFR5) 381 BIFT BFR4: 383 0:3: forward_connected(BFER1) 385 1:4: forward_connected(BFR5) 387 BIFT BFR5: 389 1:5: forward_connected(BFER2) 391 BIFT BFER2: 393 1:6: local_decap() 395 7, The BitString is splited into two sub-BitStrings according to the 396 BIFT-id by the BIER-TE controller.Examples for SI:Bitstring is 0:1111 397 and 1:00111111. 399 4. Security Considerations 401 TBD. 403 5. IANA Considerations 405 TBD. 407 6. Acknowledgements 409 TBD. 411 7. Normative References 413 [I-D.eckert-bier-te-arch] 414 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 415 Engineering for Bit Index Explicit Replication BIER-TE", 416 draft-eckert-bier-te-arch-05 (work in progress), June 417 2017. 419 [I-D.ietf-bier-architecture] 420 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 421 S. Aldrin, "Multicast using Bit Index Explicit 422 Replication", draft-ietf-bier-architecture-08 (work in 423 progress), September 2017. 425 [I-D.ietf-bier-mpls-encapsulation] 426 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 427 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 428 Explicit Replication in MPLS and non-MPLS Networks", 429 draft-ietf-bier-mpls-encapsulation-08 (work in progress), 430 September 2017. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, 434 DOI 10.17487/RFC2119, March 1997, 435 . 437 Authors' Addresses 439 Yongqing Zhu 440 China Telecom 441 109 West Zhongshan Ave 442 Guangzhou, Guangdong 510630 443 China 445 Phone: +86 20 38639581 446 Email: zhuyq@gsta.com 448 Huanan Chen 449 China Telecom 450 109 West Zhongshan Ave 451 Guangzhou, Guangdong 510630 452 China 454 Phone: +86 20 38639346 455 Email: chenhuanan@gsta.com 457 Quan Xiong 458 ZTE Corporation 459 No.6 Huashi Park Rd 460 Wuhan, Hubei 430223 461 China 463 Phone: +86 27 83531060 464 Email: xiong.quan@zte.com.cn 465 Fangwei Hu 466 ZTE Corporation 467 No.889 Bibo Rd 468 Shanghai 201203 469 China 471 Phone: +86 21 68896273 472 Email: hu.fangwei@zte.com.cn