idnits 2.17.1 draft-ietf-bier-bgp-ls-bier-ext-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 (August 30, 2018) is 2058 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) == Unused Reference: 'I-D.ietf-bier-isis-extensions' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 299, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6952 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Ran. Chen 3 Internet-Draft Zheng. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: March 3, 2019 Vengada. Govindan 6 IJsbrand. Wijnands 7 Cisco 8 August 30, 2018 10 BGP Link-State extensions for BIER 11 draft-ietf-bier-bgp-ls-bier-ext-03 13 Abstract 15 Bit Index Explicit Replication (BIER) is an architecture that 16 provides optimal multicast forwarding through a "BIER domain" without 17 requiring intermediate routers to maintain any multicast related per- 18 flow state. BIER also does not require any explicit tree-building 19 protocol for its operation. A multicast data packet enters a BIER 20 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 21 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 22 The BFIR router adds a BIER header to the packet. The BIER header 23 contains a bitstring in which each bit represents exactly one BFER to 24 forward the packet to. The set of BFERs to which the multicast 25 packet needs to be forwarded is expressed by setting the bits that 26 correspond to those routers in the BIER header. 28 This document specifies extensions to the BGP Link-state address- 29 family in order to advertising BIER information. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 3, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions used in this document . . . . . . . . . . . . . . 3 67 3. BGP-LS Extensions for BIER . . . . . . . . . . . . . . . . . 3 68 3.1. The BIER TLV . . . . . . . . . . . . . . . . . . . . . . 3 69 3.1.1. The BIER MPLS Encapsulation Sub-TLV . . . . . . . . . 4 70 3.2. The BIER-TE TLV . . . . . . . . . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. Normative references . . . . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Bit Index Explicit Replication (BIER) is an architecture that 80 provides optimal multicast forwarding through a "BIER domain" without 81 requiring intermediate routers to maintain any multicast related per- 82 flow state. BIER also does not require any explicit tree-building 83 protocol for its operation. A multicast data packet enters a BIER 84 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 85 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 86 The BFIR router adds a BIER header to the packet. The BIER header 87 contains a bitstring in which each bit represents exactly one BFER to 88 forward the packet to. The set of BFERs to which the multicast 89 packet needs to be forwarded is expressed by setting the bits that 90 correspond to those routers in the BIER header. 92 This document specifies extensions to the BGP Link-state address- 93 family in order to advertising BIER-specific. An external component 94 (e.g., a controller) then can collect BIER information in the 95 "northbound" direction within the BIER domain. 97 2. Conventions used in this document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC2119. 103 3. BGP-LS Extensions for BIER 105 Each BFR MUST be assigned a "BFR-Prefix". A BFR's BFR-Prefix MUST be 106 an IP address (either IPv4 or IPv6) of the BFR, and MUST be unique 107 and routable within the BIER domain as described in section 2 of 108 [I-D.ietf-bier-architecture], and then external component (e.g., a 109 controller) need to collect BIER information of BIER routers are 110 associated with the BFR-Prefix in the "northbound" direction within 111 the BIER domain. 113 Given that the BIER information is associated with the prefix, the 114 BGP-LS Prefix Attribute TLV [I-D.ietf-idr-ls-distribution] can be 115 used to carry the BIER information. A new Prefix Attribute TLV and 116 Sub-TLV are defined for the encoding of BIER information. 118 3.1. The BIER TLV 120 A new Prefix Attribute TLV (defined in [I-D.ietf-idr-ls-distribution] 121 is defined for distributing BIER information. The new TLV is called 122 the BIER TLV. The BIER TLVs may appear multiple times. 124 The following BIER TLV is defined: 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | reserved | subdomain-id | MT-ID | BSL | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | BFR-id | reserved | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Sub-TLVs (variable) | 136 +- -+ 137 | | 139 Figure 1 141 Type:as indicated in IANA Considerations section. 143 Length: 2 octet. 145 Reserved: MUST be 0 on transmission, ignored on reception. May be 146 used in future versions. 148 Subdomain-id: Unique value identifying the BIER sub-domain, 1 octet. 150 MT-ID: Multi-Topology ID that identifies the topology that is 151 associated with the BIER sub-domain.1 octet. 153 BitString Length (BS Len): A 1 octet field encoding the supported 154 BitString length associated with this BFR-prefix.This field are 155 specified in section 3 of [I-D.ietf-bier-mpls-encapsulation].Given 156 that the bier router can support BSL values set, this field encoding 157 the BSL values set that BIER routers supported. 159 BFR-id: A 2 octet field encoding the BFR-id, as documented in 160 [I-D.ietf-bier-architecture]. If the BFR-id is zero, it means, the 161 advertising router is not advertising any BIER-id.In some 162 environment, BFR-id can be configured by NMS, The BFR-id should be 163 sent to a controller. 165 If multiple BIER Sub-TLVs are present, all having the same BS Length 166 and Subdomain-id values, first one MUST be used and subsequent ones 167 MUST be ignored. 169 3.1.1. The BIER MPLS Encapsulation Sub-TLV 171 The BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER TLV. 172 BIER MPLS Encapsulation Sub-TLV is used in order to advertise MPLS 173 specific information used for BIER. It MUST appear multiple times in 174 the BIER TLV as described in [I-D.ietf-bier-ospf-bier-extensions] 176 In some environment, each router allocates its labels, and advertises 177 it to the controller.That solution is simpler as the controller does 178 not need to deal with label allocation. If the controller has to 179 deal with Label allocation , there needs to be a (global) range 180 carved out such there are no conflicts. We can avoid all that by 181 having the router allocate the BIER Label range and advertise it to 182 the controller. 184 The following the BIER MPLS Encapsulation Sub-TLV is defined: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |Lbl Range Size | Label Range Base | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | BS Length | Reserved | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2 198 Type: as indicated in IANA Considerations section. 200 Length: 2 octet. 202 Label Range Size: A 1 octet field encoding the label range size of 203 the label range. It MUST be greater than 0, otherwise the TLV MUST 204 be ignored. 206 Label Range Base: A 3 octet field, where the 20 rightmost bits 207 represent the first label in the label range. 209 BS Length: Bitstring length for the label range that this router is 210 advertising per [I-D.ietf-bier-mpls-encapsulation]. 1 octet.The 211 values allowed in this field are specified in section 3 of 212 [I-D.ietf-bier-mpls-encapsulation]. 214 The "label range" is the set of labels beginning with the label range 215 base and ending with (label range base)+(label range size)-1. A 216 unique label range is allocated for each BitStream length and Sub- 217 domain-ID. These label is used for BIER forwarding as described in 218 [I-D.ietf-bier-architecture] and 219 [I-D.ietf-bier-mpls-encapsulation].Label ranges within the sub-TLV 220 MUST NOT overlap, otherwise the whole sub-TLV MUST be disregarded 222 BS length in multiple BIER MPLS Encapsulation Sub-TLV inside the same 223 BIER Sub-TLV MUST NOT repeat, otherwise only the first BIER MPLS 224 Encapsulation Sub-TLV with such BS length MUST be used and any 225 subsequent BIER MPLS Encapsulation Sub-TLVs with the same BS length 226 MUST be ignored. 228 3.2. The BIER-TE TLV 230 This TLV is used to collect BIER-TE information in the "northbound" 231 direction within the BIER-TE domain. 233 The section will be added in next version. 235 4. IANA Considerations 237 This document requests assigning code-points from the registry for 238 the new Prefix Attribute TLV and Sub-TLV. 240 +-------------------+---------------+-----------------+ 241 | TLV Code Point | Description | Value defined | 242 +-------------------+---------------+-----------------+ 243 | 1158( recommend ) | BIER | this document | 244 +-------------------+---------------+-----------------+ 246 Table 1: The new Prefix Attribute TLV 248 +-----------------+-------------------------------+-----------------+ 249 | Sub-TLV | Description | Value | 250 | Code Point | | | 251 +-----------------+-------------------------------+-----------------+ 252 | 1 ( recommend) | BIER MPLS Encapsulation | this document | 253 +------------+-------------------------------+----------------------+ 255 Table 2: The new Prefix Attribute Sub-TLV 257 5. Security Considerations 259 Procedures and protocol extensions defined in this document do not 260 affect the BGP security model. See [RFC6952] for details. 262 6. Acknowledgements 264 We would like to thank Peter Psenak (Cisco) for his comments and 265 support of this work. 267 7. Normative references 269 [I-D.ietf-bier-architecture] 270 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 271 S. Aldrin, "Multicast using Bit Index Explicit 272 Replication", draft-ietf-bier-architecture-08 (work in 273 progress), September 2017. 275 [I-D.ietf-bier-isis-extensions] 276 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 277 "BIER support via ISIS", draft-ietf-bier-isis- 278 extensions-11 (work in progress), March 2018. 280 [I-D.ietf-bier-mpls-encapsulation] 281 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 282 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 283 Explicit Replication in MPLS and non-MPLS Networks", 284 draft-ietf-bier-mpls-encapsulation-12 (work in progress), 285 October 2017. 287 [I-D.ietf-bier-ospf-bier-extensions] 288 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 289 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 290 Extensions for BIER", draft-ietf-bier-ospf-bier- 291 extensions-18 (work in progress), June 2018. 293 [I-D.ietf-idr-ls-distribution] 294 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 295 Ray, "North-Bound Distribution of Link-State and TE 296 Information using BGP", draft-ietf-idr-ls-distribution-13 297 (work in progress), October 2015. 299 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 300 (TE) Extensions to OSPF Version 2", RFC 3630, 301 DOI 10.17487/RFC3630, September 2003, 302 . 304 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 305 BGP, LDP, PCEP, and MSDP Issues According to the Keying 306 and Authentication for Routing Protocols (KARP) Design 307 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 308 . 310 Authors' Addresses 312 Ran Chen 313 ZTE Corporation 314 No.50 Software Avenue,Yuhuatai District 315 Nanjing, Jiangsu Province 210012 316 China 318 Phone: +86 025 88014636 319 Email: chen.ran@zte.com.cn 320 Zheng Zhang 321 ZTE Corporation 322 No.50 Software Avenue,Yuhuatai District 323 Nanjing, Jiangsu Province 210012 324 China 326 Email: zhang.zheng@zte.com.cn 328 Vengada Prasad Govindan 329 Cisco 331 Email: venggovi@cisco.com 333 IJsbrand Wijnands 334 Cisco 335 De Kleetlaan 6a 336 Diegem 1831 337 Belgium 339 Email: ice@cisco.com