idnits 2.17.00 (12 Aug 2021) /tmp/idnits59061/draft-xu-idr-bier-extensions-01.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, 2015) is 2636 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.wijnands-mpls-bier-encapsulation' is defined on line 260, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-04 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) == Outdated reference: draft-ietf-rtgwg-bgp-routing-large-dc has been published as RFC 7938 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei 5 Expires: September 4, 2015 K. Patel 6 I. Wijnands 7 Cisco 8 A. Przygienda 9 Ericsson 10 March 3, 2015 12 BGP Extensions for BIER 13 draft-xu-idr-bier-extensions-01 15 Abstract 17 Bit Index Explicit Replication (BIER) is a new multicast forwarding 18 architecture which doesn't require an explicit tree-building protocol 19 and doesn't require intermediate routers to maintain any multicast 20 state. BIER is applicable in a multi-tenant data center network 21 environment for efficient delivery of Broadcast, Unknown-unicast and 22 Multicast (BUM) traffic while eliminating the need for maintaining a 23 huge amount of multicast state in the underlay. This document 24 describes BGP extensions for advertising the BIER-specific 25 information. These extensions are applicable in those multi-tenant 26 data centers where BGP instead of IGP is deployed as an underlay for 27 network reachability advertisement. These extensions may also be 28 applicable in other scenarios. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 4, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 3 68 4. Originating BIER Attribute . . . . . . . . . . . . . . . . . 4 69 5. Restrictions on Sending/Receiving . . . . . . . . . . . . . . 5 70 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 10.2. Informative References . . . . . . . . . . . . . . . . . 6 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 79 1. Introduction 81 Bit Index Explicit Replication (BIER) 82 [I-D.wijnands-bier-architecture] is a new multicast forwarding 83 architecture which doesn't require an explicit tree-building protocol 84 and doesn't require intermediate routers to maintain any multicast 85 state. BIER is applicable in a multi-tenant data center network 86 environment for efficient delivery of Broadcast, Unknown-unicast and 87 Multicast (BUM) traffic while eliminating the need for maintaining a 88 huge amount of multicast state in the 89 underlay[I-D.kumar-bier-use-cases]. This document describes BGP 90 extensions for advertising the BIER-specific information. More 91 specifically, in this document, we define a new optional, non- 92 transitive BGP attribute, referred to as the BIER attribute, to 93 convey the BIER-specific information such as BFR-ID, BitString Length 94 (BSL) and so on. In addition, this document specifies procedures to 95 prevent the BIER attribute from "leaking out" of a BIER domain . 96 These extensions are applicable in those multi-tenant data centers 97 where BGP instead of IGP is used as an underlay 98 [I-D.ietf-rtgwg-bgp-routing-large-dc]. These extensions may also be 99 applicable to other BGP based network scenarios. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. Terminology 109 This memo makes use of the terms defined in [RFC4271] and 110 [I-D.wijnands-bier-architecture]. 112 3. BIER Path Attribute 114 This draft defines a new optional, transitive BGP path attribute, 115 referred to as the BIER attribute. This attribute can be attached to 116 a BGP UPDATE message by the originator so as to indicate the BIER- 117 specific information of a particular BFR which is identified by the 118 /32 or /128 address prefix contained in the NLRI. 120 The attribute type code for the BIER Attribute is TBD. The value 121 field of the BIER Attribute contains one or more BIER TLV as shown in 122 Figure 1. 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Type=TBD | Length | Sub-domain | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | BFR-ID | BSL | | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 131 ~ ~ 132 | Sub-TLVs | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 134 Figure 1:BIER TLV 136 Type: A single octet encoding the BIER TLV Type: TBD. 138 Length: Two octets encoding the length in octets of the TLV, 139 including the type and length fields. The length is encoded as an 140 unsigned binary integer. (Note that the minimum length is 7, 141 indicating that no sub-TLV is present.) 142 Sub-domain: a one-octet field encoding the sub-domain ID 143 corresponding to the BFR-ID. 145 BFR-ID: a two-octet field encoding the BFR-ID. 147 BSL: a one-octet field indicating the length of the Bitstring in 148 4-octets. The field MUST be filled with one of the valid BSL 149 values as specified in [I-D.wijnands-bier-architecture]. Upon 150 receiving a BSL-TLV containing an invalid BSL value, it MUST be 151 ignored. 153 Sub-TLVs: contains one or more sub-TLV. The BIER MPLS 154 Encapsulation sub-TLV is one of such sub-TLVs. 156 The BIER MPLS Encapsulation sub-TLV is encoded as follows: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Type=TBD | Length=7 |Lbl Range Size | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Label Range Base | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 2:BIER MPLS Encapsulation sub-TLV 167 Type:TBD 169 Length:7 171 Label Range Size: a one-octet field indicating the size of the 172 label range. 174 Label Range Base: a 3-octet field where the 20 rightmost bits 175 represent the first label in the label range while the other bits 176 MUST be set to 0 when transmitting, and MUST be ignored upon 177 receipt. 179 4. Originating BIER Attribute 181 An implementation that supports the BIER attribute MUST support a 182 policy to enable or disable the creation of the BIER attribute and 183 its attachment to specific BGP routes. An implementation MAY disable 184 the creation of the BIER attribute unless explicitly configured to do 185 so otherwise. A BGP speaker MUST only attach the locally created 186 BIER attribute to a BGP UPDATE message in which at least one of its 187 routable addresses (e.g., a loopback address) is contained in the 188 NLRI. Furthermore, the routable address contained in the NLRI is 189 RECOMMENDED to be the one used for establishing BGP sessions. In 190 other words, the routable address is usually used as the BGP nexthop 191 address of BGP updates advertised by that BGP speaker. 193 5. Restrictions on Sending/Receiving 195 An implementation that supports the BIER attribute MUST support a 196 per-EBGP-session policy, that indicates whether the attribute is 197 enabled or disabled for use on that session. The BIER attribute MUST 198 NOT be sent on any EBGP peers for which the session policy is not 199 configured. If an BIER attribute is received on a BGP session for 200 which session policy is not configured, then the received attribute 201 MUST be treated exactly as if it were an unrecognised non-transitive 202 attribute. That is, "it MUST be quietly ignored and not passed along 203 to other BGP peers". 205 To prevent the BIER attribute from "leaking out" of an BIER domain, 206 each BGP router on the BIER domain MUST support an outbound route 207 announcement policy. Such a policy MUST be disabled on each EBGP 208 session by default unless explicitly configured. 210 6. Deployment Considerations 212 It's assumed by this document that the BIER domain is aligned with 213 the Administrative Domain (AD) which are composed of multiple ASes 214 (either private or public ASes). Use of the BIER attribute in other 215 scenarios is outside the scope of this document. 217 Since the BIER attribute is an optional, transitive BGP path 218 attribute, a non-BFR BGP speakers could still advertise the received 219 route with a BIER attribute. This is desirable in the incremental 220 deployment scenario where a BGP speaker could tunnel a BIER packet or 221 the payload of a BIER packet to a BFER directly if the BGP next-hop 222 of the route for that BFER is a non-BFR. Furthermore, a BGP speaker 223 is allowed to tunnel a BIER packet to the BGP next-hop if these two 224 BFR-capable BGP neighbors are not directly connected (e.g., multi-hop 225 EBGP) . As for which tunnel type should be used, it could be manually 226 configured or dynamically negotiated by using the BGP Encapsulation 227 SAFI mechanism as defined in [RFC5512]. The BIER-specific extensions 228 to the BGP Encapsulation SAFI would be defined in a future version of 229 this document. 231 7. Acknowledgements 233 TBD. 235 8. IANA Considerations 237 IANA is requested to assign a codepoint in the "BGP Path Attributes" 238 registry to the BIER attribute. IANA shall create a registry for 239 "BGP BIER Attribute Types". The type field consists of a single 240 octet, with possible values from 1 to 255. (The value 0 is 241 "reserved".) The allocation policy for this field is to be 242 "Standards Action". Type codes should be allocated for BIER TLV and 243 BIER MPLS Encapsulation sub-TLV respectively. 245 9. Security Considerations 247 This document introduces no new security considerations beyond those 248 already specified in [RFC4271]. 250 10. References 252 10.1. Normative References 254 [I-D.wijnands-bier-architecture] 255 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 256 S. Aldrin, "Multicast using Bit Index Explicit 257 Replication", draft-wijnands-bier-architecture-04 (work in 258 progress), February 2015. 260 [I-D.wijnands-mpls-bier-encapsulation] 261 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 262 S. Aldrin, "Encapsulation for Bit Index Explicit 263 Replication in MPLS Networks", draft-wijnands-mpls-bier- 264 encapsulation-02 (work in progress), December 2014. 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 270 Protocol 4 (BGP-4)", RFC 4271, January 2006. 272 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 273 Subsequent Address Family Identifier (SAFI) and the BGP 274 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 276 10.2. Informative References 278 [I-D.ietf-rtgwg-bgp-routing-large-dc] 279 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 280 routing in large-scale data centers", draft-ietf-rtgwg- 281 bgp-routing-large-dc-01 (work in progress), February 2015. 283 [I-D.kumar-bier-use-cases] 284 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 285 Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., and 286 D. Robinson, "BIER Use Cases", draft-kumar-bier-use- 287 cases-02 (work in progress), February 2015. 289 Authors' Addresses 291 Xiaohu Xu 292 Huawei 294 Email: xuxiaohu@huawei.com 296 Mach Chen 297 Huawei 299 Email: mach.chen@huawei.com 301 Keyur Patel 302 Cisco 304 Email: keyupate@cisco.com 306 IJsbrand Wijnands 307 Cisco 309 Email: ice@cisco.com 311 Antoni Przygienda 312 Ericsson 314 Email: antoni.przygienda@ericsson.com