idnits 2.17.1 draft-ietf-bier-idr-extensions-05.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 (February 28, 2018) is 2242 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) ** Downref: Normative reference to an Informational RFC: RFC 7938 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Xu, Ed. 3 Internet-Draft Alibaba Inc. 4 Intended status: Standards Track M. Chen 5 Expires: September 1, 2018 Huawei 6 K. Patel 7 Arrcus, Inc. 8 I. Wijnands 9 Cisco 10 A. Przygienda 11 Juniper 12 February 28, 2018 14 BGP Extensions for BIER 15 draft-ietf-bier-idr-extensions-05 17 Abstract 19 Bit Index Explicit Replication (BIER) is a new multicast forwarding 20 architecture which doesn't require an explicit tree-building protocol 21 and doesn't require intermediate routers to maintain any multicast 22 state. BIER is applicable in a multi-tenant data center network 23 environment for efficient delivery of Broadcast, Unknown-unicast and 24 Multicast (BUM) traffic while eliminating the need for maintaining a 25 huge amount of multicast state in the underlay. This document 26 describes BGP extensions for advertising the BIER-specific 27 information. These extensions are applicable in those multi-tenant 28 data centers where BGP instead of IGP is deployed as an underlay for 29 network reachability advertisement. These extensions may also be 30 applicable in other scenarios. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on September 1, 2018. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 3 75 4. Originating BIER Attribute . . . . . . . . . . . . . . . . . 4 76 5. Restrictions on Sending/Receiving . . . . . . . . . . . . . . 5 77 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 84 1. Introduction 86 Bit Index Explicit Replication (BIER) [RFC8279] is a new multicast 87 forwarding architecture which doesn't require an explicit tree- 88 building protocol and doesn't require intermediate routers to 89 maintain any multicast state. BIER is applicable in a multi-tenant 90 data center network environment for efficient delivery of Broadcast, 91 Unknown-unicast and Multicast (BUM) traffic while eliminating the 92 need for maintaining a huge amount of multicast state in the 93 underlay. This document describes BGP extensions for advertising the 94 BIER-specific information. More specifically, in this document, we 95 define a new optional, non- transitive BGP attribute, referred to as 96 the BIER attribute, to convey the BIER-specific information such as 97 BFR-ID, BitString Length (BSL) and so on. In addition, this document 98 specifies procedures to prevent the BIER attribute from "leaking out" 99 of a BIER domain. 101 These extensions are applicable in those multi-tenant data centers 102 where BGP instead of IGP is used as an underlay [RFC7938]. These 103 extensions may also be applicable to other BGP based network 104 scenarios. 106 2. Terminology 108 This memo makes use of the terms defined in [RFC4271] and [RFC8279]. 110 3. BIER Path Attribute 112 This draft defines a new optional, transitive BGP path attribute, 113 referred to as the BIER attribute. This attribute can be attached to 114 a BGP UPDATE message by the originator so as to indicate the BIER- 115 specific information of a particular BFR which is identified by the 116 /32 or /128 address prefix contained in the NLRI. In other words, if 117 the BIER path attribute is present, the NLRI is treated by BIER as a 118 "BFR-prefix". When creating a BIER attribute, a BFR needs to include 119 one BIER TLV for every pair that it supports. 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 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Sub-domain | BFR-ID | Reserved | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 ~ ~ 132 | Sub-TLVs | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 134 Figure 1:BIER TLV 136 Type: Two octets 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 8, 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 Sub-TLVs: contains one or more sub-TLV. The BIER MPLS 148 Encapsulation sub-TLV is one of such sub-TLVs. 150 The BIER MPLS Encapsulation sub-TLV is encoded as follows: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type=TBD | Length=12 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Label Range Base |Lbl Range Size | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | BSL | Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 2:BIER MPLS Encapsulation sub-TLV 163 Type:TBD 165 Length:12 167 Label Range Size: a one-octet field indicating the size of the 168 label range. 170 Label Range Base: a 3-octet field where the 20 rightmost bits 171 represent the first label in the label range while the other bits 172 MUST be set to 0 when transmitting, and MUST be ignored upon 173 receipt. 175 BSL: a one-octet field indicating the length of the Bitstring in 176 4-octets. The field MUST be filled with one of the valid BSL 177 values as specified in [RFC8279]. Upon receiving a BSL-TLV 178 containing an invalid BSL value, it MUST be ignored. 180 4. Originating BIER Attribute 182 An implementation that supports the BIER attribute MUST support a 183 policy to enable or disable the creation of the BIER attribute and 184 its attachment to specific BGP routes. An implementation MAY disable 185 the creation of the BIER attribute unless explicitly configured to do 186 so otherwise. A BGP speaker MUST only attach the locally created 187 BIER attribute to a BGP UPDATE message in which at least one of its 188 BFR-prefixes is contained in the NLRI 190 5. Restrictions on Sending/Receiving 192 An implementation that supports the BIER attribute MUST support a 193 per-EBGP-session policy, that indicates whether the attribute is 194 enabled or disabled for use on that session. The BIER attribute MUST 195 NOT be sent on any EBGP peers for which the session policy is not 196 configured. If an BIER attribute is received on a BGP session for 197 which session policy is not configured, then the received attribute 198 MUST be treated exactly as if it were an unrecognised non-transitive 199 attribute. That is, "it MUST be quietly ignored and not passed along 200 to other BGP peers". 202 To prevent the BIER attribute from "leaking out" of an BIER domain, 203 each BGP router on the BIER domain MUST support an outbound route 204 announcement policy. Such a policy MUST be disabled on each EBGP 205 session by default unless explicitly configured. 207 6. Deployment Considerations 209 It's assumed by this document that the BIER domain is aligned with 210 the Administrative Domain (AD) which are composed of multiple ASes 211 (either private or public ASes). Use of the BIER attribute in other 212 scenarios is outside the scope of this document. 214 Since the BIER attribute is an optional, transitive BGP path 215 attribute, a non-BFR BGP speakers could still advertise the received 216 route with a BIER attribute. This is desirable in the incremental 217 deployment scenario where a BGP speaker could tunnel a BIER packet or 218 the payload of a BIER packet to a BFER directly if the BGP next-hop 219 of the route for that BFER is a non-BFR. Furthermore, a BGP speaker 220 is allowed to tunnel a BIER packet to the BGP next-hop if these two 221 BFR-capable BGP neighbors are not directly connected (e.g., multi-hop 222 EBGP). 224 7. Acknowledgements 226 Thanks a lot for Eric Rosen and Peter Psenak for their valuable 227 comments on this document. 229 8. IANA Considerations 231 IANA is requested to assign a codepoint in the "BGP Path Attributes" 232 registry to the BIER attribute. IANA shall create a registry for 233 "BGP BIER Attribute Types". The type field consists of two octets, 234 with possible values from 1 to 655355 (The value 0 is "reserved".) 235 The allocation policy for this field is to be "First Come First 236 Serve". Type codes should be allocated for BIER TLV and BIER MPLS 237 Encapsulation sub-TLV respectively. 239 9. Security Considerations 241 This document introduces no new security considerations beyond those 242 already specified in [RFC4271]. 244 10. Normative References 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 252 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 253 DOI 10.17487/RFC4271, January 2006, 254 . 256 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 257 BGP for Routing in Large-Scale Data Centers", RFC 7938, 258 DOI 10.17487/RFC7938, August 2016, 259 . 261 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 262 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 263 Explicit Replication (BIER)", RFC 8279, 264 DOI 10.17487/RFC8279, November 2017, 265 . 267 Authors' Addresses 269 Xiaohu Xu (editor) 270 Alibaba Inc. 272 Email: xiaohu.xxh@alibaba-inc.com 274 Mach Chen 275 Huawei 277 Email: mach.chen@huawei.com 279 Keyur Patel 280 Arrcus, Inc. 282 Email: keyur@arrcus.com 283 IJsbrand Wijnands 284 Cisco 286 Email: ice@cisco.com 288 Antoni Przygienda 289 Juniper 291 Email: prz@juniper.net