idnits 2.17.00 (12 Aug 2021) /tmp/idnits36969/draft-ietf-bier-ospf-bier-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 (March 21, 2016) is 2252 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: draft-ietf-ospf-prefix-link-attr has been published as RFC 7684 == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-00 == Outdated reference: A later version (-02) exists of draft-wijnands-mpls-bier-encapsulation-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF P. Psenak, Ed. 3 Internet-Draft N. Kumar 4 Intended status: Standards Track IJ. Wijnands 5 Expires: September 22, 2016 Cisco 6 A. Dolganow 7 Alcatel-Lucent 8 T. Przygienda 9 Ericsson 10 J. Zhang 11 Juniper Networks, Inc. 12 S. Aldrin 13 Google, Inc. 14 March 21, 2016 16 OSPF Extensions for BIER 17 draft-ietf-bier-ospf-bier-extensions-02.txt 19 Abstract 21 Bit Index Explicit Replication (BIER) is an architecture that 22 provides multicast forwarding through a "BIER domain" without 23 requiring intermediate routers to maintain multicast related per-flow 24 state. Neither does BIER require an explicit tree-building protocol 25 for its operation. A multicast data packet enters a BIER domain at a 26 "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at 27 one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router 28 adds a BIER header to the packet. Such header contains a bit-string 29 in which each bit represents exactly one BFER to forward the packet 30 to. The set of BFERs to which the multicast packet needs to be 31 forwarded is expressed by the according set of bits switched on in 32 BIER packet header. 34 This document describes the OSPF protocol extension required for BIER 35 with MPLS encapsulation. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 22, 2016. 54 Copyright Notice 56 Copyright (c) 2016 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Flooding of the BIER Information in OSPF . . . . . . . . . . 3 73 2.1. The BIER Sub-TLV . . . . . . . . . . . . . . . . . . . . 3 74 2.2. The BIER MPLS Encapsulation Sub-TLV . . . . . . . . . . . 4 75 2.3. Optional BIER Tree Type Sub-TLV . . . . . . . . . . . . . 5 76 2.4. Flooding scope of BIER Information . . . . . . . . . . . 6 77 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 80 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 Bit Index Explicit Replication (BIER) is an architecture that 86 provides optimal multicast forwarding through a "BIER domain" without 87 requiring intermediate routers to maintain any multicast related per- 88 flow state. Neither does BIER explicitly require a tree-building 89 protocol for its operation. A multicast data packet enters a BIER 90 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 91 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 92 The BFIR router adds a BIER header to the packet. The BIER header 93 contains a bit-string in which each bit represents exactly one BFER 94 to forward the packet to. The set of BFERs to which the multicast 95 packet needs to be forwarded is expressed by setting the bits that 96 correspond to those routers in the BIER header. 98 BIER architecture requires routers participating in BIER to exchange 99 BIER related information within a given domain. BIER architecture 100 permits link-state routing protocols to perform distribution of such 101 information. This document describes extensions to OSPF necessary to 102 carry BIER specific information in the case where BIER uses MPLS 103 encapsulation as described in [I-D.wijnands-mpls-bier-encapsulation]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Flooding of the BIER Information in OSPF 111 All BIER specific information that a BFR needs to advertise to other 112 BFRs is associated with a BFR-Prefix. BFR prefix is a unique (within 113 a given BIER domain), routable IP address that is assigned to each 114 BFR as described in more detail in section 2 of 115 [I-D.wijnands-bier-architecture]. 117 Given that BIER information must be associated with a BFR prefix, the 118 OSPF Extended Prefix Opaque LSA [I-D.ietf-ospf-prefix-link-attr] has 119 been chosen to flood it. 121 2.1. The BIER Sub-TLV 123 A new Sub-TLV of the Extended Prefix TLV (defined in 124 [I-D.ietf-ospf-prefix-link-attr]) is defined for distributing BIER 125 information. The new Sub-TLV is called BIER Sub-TLV. Multiple BIER 126 Sub-TLVs may be included in the Extended Prefix TLV. 128 BIER Sub-TLV has the following format: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Sub-domain-ID | MT-ID | BFR-id | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Sub-TLVs (variable) | 138 +- -+ 139 | | 141 Type: TBD 143 Length: variable 144 Sub-domain-ID: Unique value identifying the BIER sub-domain within 145 the BIER domain, as described in section 1 of 146 [I-D.wijnands-bier-architecture]. 148 MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies 149 the topology that is associated with the BIER sub-domain. 151 BFR-id: A 2 octet field encoding the BFR-id, as documented in 152 section 2 [I-D.wijnands-bier-architecture]. If the BFR is not 153 locally configured with a valid BFR-id, the value of this field is 154 set to invalid BFR-id per [I-D.wijnands-bier-architecture]. 156 Each BFR sub-domain MUST be associated with one and only one OSPF 157 topology that is identified by the MT-ID. If the association between 158 BIER sub-domain and OSPF topology advertised in the BIER sub-TLV by 159 other BFRs is in conflict with the association locally configured on 160 the receiving router, whole BIER sub-TLV of the advertising routers 161 MUST be ignored. 163 If a BFR advertises the same Sub-domain-ID in multiple BIER sub-TLVs, 164 the BRF MUST be treated as if it did not advertise a BIER sub-TLV for 165 such sub-domain. 167 All BFRs MUST detect advertisement of duplicate valid BFR-IDs for a 168 given MT-ID and Sub-domain-ID. When such duplication is detected all 169 BFRs advertising duplicates MUST be treated as if they did not 170 advertise a valid BFR-id. 172 2.2. The BIER MPLS Encapsulation Sub-TLV 174 BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER Sub-TLV. 175 BIER MPLS Encapsulation Sub-TLV is used in order to advertise MPLS 176 specific information used for BIER. It MAY appear multiple times in 177 the BIER Sub-TLV. 179 BIER MPLS Encapsulation Sub-TLV has the following format: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |Lbl Range Size | Label Range Base | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | BS Length | Reserved | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Type: TBD 192 Length: 4 bytes 194 Label Range Size: A 1 octet field encoding the label range size of 195 the label range. It MUST be greater then 0, otherwise the 196 advertising router MUST be treated as if it did not advertise a 197 BIER sub-TLV. 199 Label Range Base: A 3 octet field, where the 20 rightmost bits 200 represent the first label in the label range. 202 BS Length: A 1 octet field encoding the supported BitString length 203 associated with this BFR-prefix. The values allowed in this field 204 are specified in section 3 of 205 [I-D.wijnands-mpls-bier-encapsulation]. 207 The "label range" is the set of labels beginning with the label 208 range base and ending with (label range base)+(label range size)- 209 1. A unique label range is allocated for each BitStream length 210 and Sub-domain-ID. These labels are used for BIER forwarding as 211 described in [I-D.wijnands-bier-architecture] and 212 [I-D.wijnands-mpls-bier-encapsulation]. 214 The size of the label range is determined by the number of Set 215 Identifiers (SI) (section 2 of [I-D.wijnands-bier-architecture]) 216 that are used in the network. Each SI maps to a single label in 217 the label range. The first label is for SI=0, the second label is 218 for SI=1, etc. 220 If same BS length is repeated in multiple BIER MPLS Encapsulation 221 Sub-TLV inside the same BIER Sub-TLV, the advertising router MUST be 222 treated as if it did not advertise a BIER sub-TLV. 224 Label ranges within all BIER MPLS Encapsulation Sub-TLV inside the 225 same BIER Sub-TLV MUST NOT overlap. If the overlap is detected, the 226 advertising router MUST be treated as if it did not advertise a BIER 227 sub-TLV. 229 All advertised labels MUST be valid, otherwise the advertising router 230 MUST be treated as if it did not advertise a BIER sub-TLV. 232 2.3. Optional BIER Tree Type Sub-TLV 234 This Sub-TLV carries the information associated with the supported 235 BIER tree type for a subdomain. This Sub-TLV is optional and its 236 absence has the same semantics as its presence with Tree Type value 0 237 (SPF). When Tree Type 0 is used it is recommended that this Sub-TLV 238 is omitted in order to reduce the space consumed in the parent TLV. 240 This Sub-TLV MAY occur no more than once in a BIER sub-TLV. If 241 multiple occurences of this Sub-TLV are present in a single BIER Sub- 242 TLV the advertising router MUST be treated as if it did not advertise 243 a BIER sub-TLV. 245 If the tree type (implied or explicitly advertised) does not match 246 the locally configured tree type associated with the matching 247 subdomain the advertising router MUST be treated as if it did not 248 advertise a BIER sub-TLV. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type | Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Tree Type | 256 +-+-+-+-+-+-+-+-+ 258 Type: value of 1 indicating BIER Tree Type. 260 Length: 1 octet. 262 Tree Type: 1 octet 264 2.4. Flooding scope of BIER Information 266 Flooding scope of the OSPF Extended Prefix Opaque LSA 267 [I-D.ietf-ospf-prefix-link-attr] that is used for advertising BIER 268 Sub TLV is set to area. To allow BIER deployment in a multi-area 269 environment, OSPF must propagate BIER information between areas. The 270 following procedure is used in order to propagate BIER related 271 information between areas: 273 When an OSPF ABR advertises a Type-3 Summary LSA from an intra- 274 area or inter-area prefix to all its connected areas, it will also 275 originate an Extended Prefix Opaque LSA, as described in 276 [I-D.ietf-ospf-prefix-link-attr]. The flooding scope of the 277 Extended Prefix Opaque LSA type will be set to area-scope. The 278 route-type in the OSPF Extended Prefix TLV is set to inter-area. 279 When determining whether a BIER Sub-TLV should be included in this 280 LSA ABR will: 282 - look at its best path to the prefix in the source area and 283 find the advertising router associated with the best path to 284 that prefix. 286 - determine if such advertising router advertised a BIER Sub- 287 TLV for the prefix. If yes, ABR will copy the information from 288 such BIER MPLS Sub-TLV when advertising BIER MPLS Sub-TLV to 289 each connected area. 291 3. Security Considerations 293 Implementations must assure that malformed TLV and Sub-TLV 294 permutations do not result in errors which cause hard OSPF failures. 296 4. IANA Considerations 298 The document requests three new allocations from the OSPF Extended 299 Prefix sub-TLV registry as defined in 300 [I-D.ietf-ospf-prefix-link-attr]. 302 BIER Sub-TLV: TBD 304 BIER MPLS Encapsulation Sub-TLV: TBD 306 BIER Tree Type Sub-TLV: TBD 308 5. Acknowledgments 310 The authors would like to thank Rajiv Asati, Christian Martin, Greg 311 Shepherd and Eric Rosen for their contribution. 313 6. Normative References 315 [I-D.ietf-ospf-prefix-link-attr] 316 Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., 317 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 318 Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work 319 in progress), August 2015. 321 [I-D.wijnands-bier-architecture] 322 Wijnands, I., Rosen, E., Dolganow, A., and T. Przygienda, 323 "Multicast using Bit Index Explicit Replication", draft- 324 wijnands-bier-architecture-00 (work in progress), 325 September 2014. 327 [I-D.wijnands-mpls-bier-encapsulation] 328 Wijnands, I., Rosen, E., Dolganow, A., and J. Tantsura, 329 "Encapsulation for Bit Index Explicit Replication in MPLS 330 Networks", draft-wijnands-mpls-bier-encapsulation-00 (work 331 in progress), September 2014. 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 339 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 340 RFC 4915, DOI 10.17487/RFC4915, June 2007, 341 . 343 Authors' Addresses 345 Peter Psenak (editor) 346 Cisco 347 Apollo Business Center 348 Mlynske nivy 43 349 Bratislava 821 09 350 Slovakia 352 Email: ppsenak@cisco.com 354 Nagendra Kumar 355 Cisco 356 7200 Kit Creek Road 357 Research Triangle Park, NC 27709 358 US 360 Email: naikumar@cisco.com 362 IJsbrand Wijnands 363 Cisco 364 De Kleetlaan 6a 365 Diegem 1831 366 Belgium 368 Email: ice@cisco.com 370 Andrew Dolganow 371 Alcatel-Lucent 372 600 March Rd. 373 Ottawa, Ontario K2K 2E6 374 Canada 376 Email: andrew.dolganow@alcatel-lucent.com 377 Tony Przygienda 378 Ericsson 379 300 Holger Way 380 San Jose, CA 95134 381 USA 383 Email: antoni.przygienda@ericsson.com 385 Jeffrey Zhang 386 Juniper Networks, Inc. 387 10 Technology Park Drive 388 Westford, MA 01886 389 USA 391 Email: zzhang@juniper.net 393 Sam Aldrin 394 Google, Inc. 395 1600 Amphitheatre Parkway 396 Mountain View, CA 397 USA 399 Email: aldrin.ietf@gmail.com