idnits 2.17.00 (12 Aug 2021) /tmp/idnits59951/draft-xu-idr-bier-extensions-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 (February 16, 2015) is 2651 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) == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-04 == Outdated reference: draft-ietf-rtgwg-bgp-routing-large-dc has been published as RFC 7938 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 X. Xu 3 Internet-Draft Huawei 4 Intended status: Standards Track K. Patel 5 Expires: August 20, 2015 Cisco 6 M. Chen 7 Huawei 8 I. Wijnands 9 Cisco 10 February 16, 2015 12 BGP Extensions for BIER 13 draft-xu-idr-bier-extensions-00 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 envioronment for efficient delivery of Broadcast, Unknown-unicast and 22 Multicast (BUM) traffic while eliminating the need for maitaining a 23 huge amount of multicast state in an underlay. This document 24 describes BGP extensions for advertising the BIER-specific 25 information. These extesnions 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 August 20, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 75 9.2. Informative References . . . . . . . . . . . . . . . . . 6 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 Bit Index Explicit Replication (BIER) 81 [I-D.wijnands-bier-architecture] is a new multicast forwarding 82 architecture which doesn't require an explicit tree-building protocol 83 and doesn't require intermediate routers to maintain any multicast 84 state. BIER is applicable in a multi-tenant data center network 85 envioronment for efficient delivery of Broadcast, Unknown-unicast and 86 Multicast (BUM) traffic while eliminating the need for maitaining a 87 huge amount of multicast state in an 88 underlay[I-D.kumar-bier-use-cases]. This document describes BGP 89 extensions for advertising the BIER-specific information. More 90 specifically, in this document, we define a new optional, non- 91 transitive BGP attribute, referred to as the BIER attribute, to 92 convey the BIER-specific information such as BFR-ID, bitstring length 93 and so on. In addition, this document specifies procedures to 94 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]. 111 3. BIER Path Attribute 113 This draft defines a new optional, transitive BGP path attribute, 114 referred to as the BIER attribute. This attribute can be attached to 115 a BGP UPDATE message by the originator so as to indicate the BIER- 116 specific information of a particular BFR which is identified by the 117 /32 or /128 address prefix contained in the NLRI. 119 The attribute type code for the BIER Attribute is TBD. The value 120 field of the BIER Attribute is defined here to contain a set of TLVs. 121 Each such TLV is encoded as shown in Figure 1. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type | Length | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 128 ~ ~ 129 | Value | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 131 Figure 1:BIER TLV 133 Type: A single octet encoding the TLV Type. 135 Length: A single octet encoding the length in octets of the TLV, 136 including the type and length fields. The length is encoded as an 137 unsigned binary integer. (Note that the minimum length is 3, 138 indicating that no value field is present.) 140 Value: A variable-length field containing zero or more octets. 142 This document defines three such TLVs including "BFR-ID TLV" , "BSL 143 TLV" and "MPLS BIER Encapsulation TLV". The first one is used to 144 convey the BFR-ID of the BFR which is indicated by the NLRI. The 145 second one is used to indicate the BitString Length that the BFR 146 which is indicated by the NLRI can support. The third one is used to 147 indicate the MPLS label range available for the MPLS-BIER 148 encapsulation purpose [I-D.wijnands-mpls-bier-encapsulation]. Other 149 TLVs are to be defined in the future. 151 The BFR-ID TLV is encoded as follows: 153 Type:TBD2 155 Length:5 157 Value: contains a two-octet BFR-ID. 159 The BSL TLV is encoded as follows: 161 Type:TBD3 163 Length:4 165 Value: contains a one-octet BSL which indicates the length of the 166 Bitstring in 4-octets. 168 The BIER MPLS Encapsualtion TLV is encoded as follows: 170 Type:TBD4 172 Length:7 174 Value: contains a one-octet Label Range Size field indicating the 175 size of the label range, and a 3-octect Label Rang Base field 176 where the 20 rightmost bits represent the first label in the label 177 range. 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 one of its local 187 addresses (e.g., a loopback address) is contained in the NLRI. 189 5. Restrictions on Sending/Receiving 191 An implementation that supports the BIER attribute MUST support a 192 per-EBGP-session policy, that indicates whether the attribute is 193 enabled or disabled for use on that session. The BIER attribute MUST 194 NOT be sent on any EBGP peers for which the session policy is not 195 configured. If an BIER attribute is received on a BGP session for 196 which session policy is not configured, then the received attribute 197 MUST be treated exactly as if it were an unrecognized non-transitive 198 attribute. That is, "it MUST be quietly ignored and not passed along 199 to other BGP peers". 201 To prevent the BIER attribute from "leaking out" of an BIER domain, 202 each BGP router on the BIER domain MUST support an outbound route 203 announcement policy.Such a policy MUST be disabled on each EBGP 204 session by default unless explicitly configured. 206 6. Acknowledgements 208 TBD. 210 7. IANA Considerations 212 IANA is requested to assign a codepoint in the "BGP Path Attributes" 213 registry to the BIER attribute. IANA shall create a registry for 214 "BGP BIER Attribute Types". The type field consists of a single 215 octet, with possible values from 1 to 255. (The value 0 is 216 "reserved".) The allocation policy for this field is to be 217 "Standards Action". Type codes should be allocated for BFR-ID TLV, 218 BSL TLV and BIER MPLS Encapsualtion TLV respectively. 220 8. Security Considerations 222 TBD. 224 9. References 226 9.1. Normative References 228 [I-D.wijnands-bier-architecture] 229 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 230 S. Aldrin, "Multicast using Bit Index Explicit 231 Replication", draft-wijnands-bier-architecture-04 (work in 232 progress), February 2015. 234 [I-D.wijnands-mpls-bier-encapsulation] 235 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 236 S. Aldrin, "Encapsulation for Bit Index Explicit 237 Replication in MPLS Networks", draft-wijnands-mpls-bier- 238 encapsulation-02 (work in progress), December 2014. 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, March 1997. 243 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 244 Protocol 4 (BGP-4)", RFC 4271, January 2006. 246 9.2. Informative References 248 [I-D.ietf-rtgwg-bgp-routing-large-dc] 249 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 250 routing in large-scale data centers", draft-ietf-rtgwg- 251 bgp-routing-large-dc-01 (work in progress), February 2015. 253 [I-D.kumar-bier-use-cases] 254 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 255 Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., and 256 D. Robinson, "BIER Use Cases", draft-kumar-bier-use- 257 cases-02 (work in progress), February 2015. 259 Authors' Addresses 261 Xiaohu Xu 262 Huawei 264 Email: xuxiaohu@huawei.com 266 Keyur Patel 267 Cisco 269 Email: keyupate@cisco.com 271 Mach Chen 272 Huawei 274 Email: mach.chen@huawei.com 275 IJsbrand Wijnands 276 Cisco 278 Email: ice@cisco.com