idnits 2.17.1 draft-ietf-bier-idr-extensions-02.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 (January 17, 2017) is 2649 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-mpls-encapsulation' is defined on line 258, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-05 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-06 == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 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 M. Chen 4 Intended status: Standards Track Huawei 5 Expires: July 21, 2017 K. Keyur Patel 6 Arrcus, Inc. 7 I. Wijnands 8 Cisco 9 A. Przygienda 10 Juniper 11 January 17, 2017 13 BGP Extensions for BIER 14 draft-ietf-bier-idr-extensions-02 16 Abstract 18 Bit Index Explicit Replication (BIER) is a new multicast forwarding 19 architecture which doesn't require an explicit tree-building protocol 20 and doesn't require intermediate routers to maintain any multicast 21 state. BIER is applicable in a multi-tenant data center network 22 environment for efficient delivery of Broadcast, Unknown-unicast and 23 Multicast (BUM) traffic while eliminating the need for maintaining a 24 huge amount of multicast state in the underlay. This document 25 describes BGP extensions for advertising the BIER-specific 26 information. These extensions are applicable in those multi-tenant 27 data centers where BGP instead of IGP is deployed as an underlay for 28 network reachability advertisement. These extensions may also be 29 applicable in other scenarios. 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 http://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 July 21, 2017. 48 Copyright Notice 50 Copyright (c) 2017 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 (http://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. BIER Path Attribute . . . . . . . . . . . . . . . . . . . . . 3 69 4. Originating BIER Attribute . . . . . . . . . . . . . . . . . 4 70 5. Restrictions on Sending/Receiving . . . . . . . . . . . . . . 5 71 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 77 10.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] is 83 a new multicast forwarding architecture which doesn't require an 84 explicit tree-building protocol and doesn't require intermediate 85 routers to maintain any multicast state. BIER is applicable in a 86 multi-tenant data center network environment for efficient delivery 87 of Broadcast, Unknown-unicast and Multicast (BUM) traffic while 88 eliminating the need for maintaining a huge amount of multicast state 89 in the underlay [I-D.ietf-bier-use-cases]. This document describes 90 BGP 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. 97 These extensions are applicable in those multi-tenant data centers 98 where BGP instead of IGP is used as an underlay [RFC7938]. These 99 extensions may also be applicable to other BGP based network 100 scenarios. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Terminology 110 This memo makes use of the terms defined in [RFC4271] and 111 [I-D.ietf-bier-architecture]. 113 3. BIER Path Attribute 115 This draft defines a new optional, transitive BGP path attribute, 116 referred to as the BIER attribute. This attribute can be attached to 117 a BGP UPDATE message by the originator so as to indicate the BIER- 118 specific information of a particular BFR which is identified by the 119 /32 or /128 address prefix contained in the NLRI. In other words, if 120 the BIER path attribute is present, the NLRI is treated by BIER as a 121 "BFR-prefix". When creating a BIER attribute, a BFR needs to include 122 one BIER TLV for every pair that it supports. 123 The attribute type code for the BIER Attribute is TBD. The value 124 field of the BIER Attribute contains one or more BIER TLV as shown in 125 Figure 1. 127 0 1 2 3 128 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 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Type=TBD | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Sub-domain | BFR-ID | Reserved | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 ~ ~ 135 | Sub-TLVs | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.......................... 137 Figure 1:BIER TLV 139 Type: Two octets encoding the BIER TLV Type: TBD. 141 Length: Two octets encoding the length in octets of the TLV, 142 including the type and length fields. The length is encoded as an 143 unsigned binary integer. (Note that the minimum length is 8, 144 indicating that no sub-TLV is present.) 145 Sub-domain: a one-octet field encoding the sub-domain ID 146 corresponding to the BFR-ID. 148 BFR-ID: a two-octet field encoding the BFR-ID. 150 Sub-TLVs: contains one or more sub-TLV. The BIER MPLS 151 Encapsulation sub-TLV is one of such sub-TLVs. 153 The BIER MPLS Encapsulation sub-TLV is encoded as follows: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type=TBD | Length=12 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Label Range Base |Lbl Range Size | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | BSL | Reserved | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 2:BIER MPLS Encapsulation sub-TLV 166 Type:TBD 168 Length:12 170 Label Range Size: a one-octet field indicating the size of the 171 label range. 173 Label Range Base: a 3-octet field where the 20 rightmost bits 174 represent the first label in the label range while the other bits 175 MUST be set to 0 when transmitting, and MUST be ignored upon 176 receipt. 178 BSL: a one-octet field indicating the length of the Bitstring in 179 4-octets. The field MUST be filled with one of the valid BSL 180 values as specified in [I-D.ietf-bier-architecture]. Upon 181 receiving a BSL-TLV containing an invalid BSL value, it MUST be 182 ignored. 184 4. Originating BIER Attribute 186 An implementation that supports the BIER attribute MUST support a 187 policy to enable or disable the creation of the BIER attribute and 188 its attachment to specific BGP routes. An implementation MAY disable 189 the creation of the BIER attribute unless explicitly configured to do 190 so otherwise. A BGP speaker MUST only attach the locally created 191 BIER attribute to a BGP UPDATE message in which at least one of its 192 BFR-prefixes is contained in the NLRI 194 5. Restrictions on Sending/Receiving 196 An implementation that supports the BIER attribute MUST support a 197 per-EBGP-session policy, that indicates whether the attribute is 198 enabled or disabled for use on that session. The BIER attribute MUST 199 NOT be sent on any EBGP peers for which the session policy is not 200 configured. If an BIER attribute is received on a BGP session for 201 which session policy is not configured, then the received attribute 202 MUST be treated exactly as if it were an unrecognised non-transitive 203 attribute. That is, "it MUST be quietly ignored and not passed along 204 to other BGP peers". 206 To prevent the BIER attribute from "leaking out" of an BIER domain, 207 each BGP router on the BIER domain MUST support an outbound route 208 announcement policy. Such a policy MUST be disabled on each EBGP 209 session by default unless explicitly configured. 211 6. Deployment Considerations 213 It's assumed by this document that the BIER domain is aligned with 214 the Administrative Domain (AD) which are composed of multiple ASes 215 (either private or public ASes). Use of the BIER attribute in other 216 scenarios is outside the scope of this document. 218 Since the BIER attribute is an optional, transitive BGP path 219 attribute, a non-BFR BGP speakers could still advertise the received 220 route with a BIER attribute. This is desirable in the incremental 221 deployment scenario where a BGP speaker could tunnel a BIER packet or 222 the payload of a BIER packet to a BFER directly if the BGP next-hop 223 of the route for that BFER is a non-BFR. Furthermore, a BGP speaker 224 is allowed to tunnel a BIER packet to the BGP next-hop if these two 225 BFR-capable BGP neighbors are not directly connected (e.g., multi-hop 226 EBGP). 228 7. Acknowledgements 230 Thanks a lot for Eric Rosen and Peter Psenak for their valuable 231 comments on this document. 233 8. IANA Considerations 235 IANA is requested to assign a codepoint in the "BGP Path Attributes" 236 registry to the BIER attribute. IANA shall create a registry for 237 "BGP BIER Attribute Types". The type field consists of two octets, 238 with possible values from 1 to 655355 (The value 0 is "reserved".) 239 The allocation policy for this field is to be "First Come First 240 Serve". Type codes should be allocated for BIER TLV and BIER MPLS 241 Encapsulation sub-TLV respectively. 243 9. Security Considerations 245 This document introduces no new security considerations beyond those 246 already specified in [RFC4271]. 248 10. References 250 10.1. Normative References 252 [I-D.ietf-bier-architecture] 253 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 254 S. Aldrin, "Multicast using Bit Index Explicit 255 Replication", draft-ietf-bier-architecture-05 (work in 256 progress), October 2016. 258 [I-D.ietf-bier-mpls-encapsulation] 259 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., 260 Aldrin, S., and I. Meilik, "Encapsulation for Bit Index 261 Explicit Replication in MPLS and non-MPLS Networks", 262 draft-ietf-bier-mpls-encapsulation-06 (work in progress), 263 December 2016. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, 267 DOI 10.17487/RFC2119, March 1997, 268 . 270 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 271 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 272 DOI 10.17487/RFC4271, January 2006, 273 . 275 10.2. Informative References 277 [I-D.ietf-bier-use-cases] 278 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 279 Przygienda, T., arkadiy.gulko@thomsonreuters.com, a., 280 Robinson, D., Arya, V., and C. Bestler, "BIER Use Cases", 281 draft-ietf-bier-use-cases-04 (work in progress), January 282 2017. 284 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 285 BGP for Routing in Large-Scale Data Centers", RFC 7938, 286 DOI 10.17487/RFC7938, August 2016, 287 . 289 Authors' Addresses 291 Xiaohu Xu (editor) 292 Huawei 294 Email: xuxiaohu@huawei.com 296 Mach Chen 297 Huawei 299 Email: mach.chen@huawei.com 301 Keyur Patel 302 Arrcus, Inc. 304 Email: keyur@arrcus.com 306 IJsbrand Wijnands 307 Cisco 309 Email: ice@cisco.com 311 Antoni Przygienda 312 Juniper 314 Email: prz@juniper.net