idnits 2.17.1 draft-psenak-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 (February 25, 2015) is 3338 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 (-13) exists of draft-ietf-ospf-prefix-link-attr-03 == 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: August 29, 2015 Cisco 6 A. Dolganow 7 Alcatel-Lucent 8 T. Przygienda 9 Ericsson 10 J. Zhang 11 Juniper Networks, Inc. 12 S. Aldrin 13 Huawei Technologies 14 February 25, 2015 16 OSPF Extensions For BIER 17 draft-psenak-ospf-bier-extensions-02.txt 19 Abstract 21 Bit Index Explicit Replication (BIER) is an architecture that 22 provides optimal multicast forwarding through a "BIER domain" without 23 requiring intermediate routers to maintain any multicast related per- 24 flow state. BIER also does not require any explicit tree-building 25 protocol for its operation. A multicast data packet enters a BIER 26 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 27 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 28 The BFIR router adds a BIER header to the packet. The BIER header 29 contains a bit-string in which each bit represents exactly one BFER 30 to forward the packet to. The set of BFERs to which the multicast 31 packet needs to be forwarded is expressed by setting the bits that 32 correspond to those routers in the BIER 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 August 29, 2015. 54 Copyright Notice 56 Copyright (c) 2015 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. Flooding scope of BIER Information . . . . . . . . . . . 5 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 79 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Bit Index Explicit Replication (BIER) is an architecture that 85 provides optimal multicast forwarding through a "BIER domain" without 86 requiring intermediate routers to maintain any multicast related per- 87 flow state. Neither does BIER explicitly require a tree-building 88 protocol for its operation. A multicast data packet enters a BIER 89 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 90 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 91 The BFIR router adds a BIER header to the packet. The BIER header 92 contains a bit-string in which each bit represents exactly one BFER 93 to forward the packet to. The set of BFERs to which the multicast 94 packet needs to be forwarded is expressed by setting the bits that 95 correspond to those routers in the BIER header. 97 BIER architecture requires routers participating in BIER within a 98 given BIER domain to exchange some BIER specific information among 99 themselves. BIER architecture allows link-state routing protocols to 100 perform the distribution of these information. In this document we 101 describe extensions to OSPF to distribute BIER specific information 102 for the case where BIER uses MPLS encapsulation as described in 103 [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 the BIER specific information that a BIER router needs to 112 advertise to other BIER routers are associated with the BFR-Prefix, a 113 unique (within a given BIER domain), routable IP address that is 114 assign to each BIER router as described in section 2 of 115 [I-D.wijnands-bier-architecture]. 117 Given that the BIER information is associated with the prefix, the 118 OSPF Extended Prefix Opaque LSA [I-D.ietf-ospf-prefix-link-attr] is 119 used to flood BIER related information. 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 | Subdomain-ID | MT-ID | BFR-id | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Sub-TLVs (variable) | 138 +- -+ 139 | | 141 Type: TBD 143 Length: 4 bytes 144 Subdomain-ID: Unique value identifying the BIER subdomain 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-id is 153 zero, it means, the advertising router is not advertising any 154 BIER-id. 156 Each BFR sub-domain MUST be associate with a single OSPF topology 157 that is identified by the MT-ID. If the association between BEIR 158 sub-domain and OSPF topology advertised in the BIER sub-TLV is in 159 conflict with the association locally configured on the receiving 160 router, BIER sub-TLV SHOULD be ignored. 162 2.2. The BIER MPLS Encapsulation Sub-TLV 164 BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER Sub-TLV. 165 BIER MPLS Encapsulation Sub-TLVt is used in order to advertise MPLS 166 specific information used for BIER. It MAY appear multiple times in 167 the BIER Sub-TLV. 169 BIER MPLS Encapsulation Sub-TLV has the following format: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |Lbl Range Size | Label Range Base | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | BS Length | Reserved | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type: TBD 183 Length: 4 bytes 185 Label Range Size: A 1 octet field encoding the label range size of 186 the label range. It MUST be greater then 0, otherwise the TLV 187 MUST be ignored. 189 Label Range Base: A 3 octet field, where the 20 rightmost bits 190 represent the first label in the label range. 192 BS Length: A 1 octet field encoding the supported BitString length 193 associated with this BFR-prefix. The values allowed in this field 194 are specified in section 3 of 195 [I-D.wijnands-mpls-bier-encapsulation]. 197 The "label range" is the set of labels beginning with the label 198 range base and ending with (label range base)+(label range size)- 199 1. A unique label range is allocated for each BitStream length 200 and Multi-Topology ID. These labels are used for BIER forwarding 201 as described in [I-D.wijnands-bier-architecture] and 202 [I-D.wijnands-mpls-bier-encapsulation]. 204 The size of the label range is determined by the number of Set 205 Identifiers (SI) (section 2 of [I-D.wijnands-bier-architecture]) 206 that are used in the network. Each SI maps to a single label in 207 the label range. The first label is for SI=0, the second label is 208 for SI=1, etc. 210 If same BS length is repeated in multiple BIER MPLS Encapsulation 211 Sub-TLV inside the same BIER Sub-TLV, the first BIER MPLS 212 Encapsulation Sub-TLV with such BS length MUST be used and any 213 subsequent BIER MPLS Encapsulation Sub-TLVs with the same BS length 214 MUST be ignored. 216 Label ranges within all BIER MPLS Encapsulation Sub-TLV inside the 217 same BIER Sub-TLV SHOULD NOT overlap. If the overlap is detected, 218 overlapping BIER MPLS Encapsulation Sub-TLV SHOULD be ignored. 220 2.3. Flooding scope of BIER Information 222 Flooding scope of the OSPF Extended Prefix Opaque LSA 223 [I-D.ietf-ospf-prefix-link-attr] that is used for advertising BIER 224 Sub TLV is set to area. If (and only if) a single BIER domain 225 contains multiple OSPF areas, OSPF must propagate BIER information 226 between areas. The following procedure is used in order to propagate 227 BIER related information between areas: 229 When an OSPF ABR advertises a Type-3 Summary LSA from an intra- 230 area or inter-area prefix to all its connected areas, it will also 231 originate an Extended Prefix Opaque LSA, as described in 232 [I-D.ietf-ospf-prefix-link-attr]. The flooding scope of the 233 Extended Prefix Opaque LSA type will be set to area-scope. The 234 route-type in the OSPF Extended Prefix TLV is set to inter-area. 235 When determining whether a BIER Sub-TLV should be included in this 236 LSA ABR will: 238 - look at its best path to the prefix in the source area and 239 find the advertising router associated with the best path to 240 that prefix. 242 - determine if such advertising router advertised a BIER Sub- 243 TLV for the prefix. If yes, ABR will copy the information from 244 such BIER MPLS Sub-TLV when advertising BIER MPLS Sub-TLV to 245 each connected area. 247 3. Security Considerations 249 Implementations must assure that malformed TLV and Sub-TLV 250 permutations do not result in errors which cause hard OSPF failures. 252 4. IANA Considerations 254 The document requests two new allocations from the OSPF Extended 255 Prefix sub-TLV registry as defined in 256 [I-D.ietf-ospf-prefix-link-attr]. 258 BIER Sub-TLV: TBD 260 BIER MPLS Encapsulation Sub-TLV: TBD 262 5. Acknowledgments 264 The authors would like to thank Rajiv Asati, Christian Martin, Greg 265 Shepherd and Eric Rosen for their contribution. 267 6. Normative References 269 [I-D.ietf-ospf-prefix-link-attr] 270 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 271 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 272 Advertisement", draft-ietf-ospf-prefix-link-attr-03 (work 273 in progress), February 2015. 275 [I-D.wijnands-bier-architecture] 276 Wijnands, I., Rosen, E., Dolganow, A., and T. Przygienda, 277 "Multicast using Bit Index Explicit Replication", draft- 278 wijnands-bier-architecture-00 (work in progress), 279 September 2014. 281 [I-D.wijnands-mpls-bier-encapsulation] 282 Wijnands, I., Rosen, E., Dolganow, A., and J. Tantsura, 283 "Encapsulation for Bit Index Explicit Replication in MPLS 284 Networks", draft-wijnands-mpls-bier-encapsulation-00 (work 285 in progress), September 2014. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 291 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 292 4915, June 2007. 294 Authors' Addresses 296 Peter Psenak (editor) 297 Cisco 298 Apollo Business Center 299 Mlynske nivy 43 300 Bratislava 821 09 301 Slovakia 303 Email: ppsenak@cisco.com 305 Nagendra Kumar 306 Cisco 307 7200 Kit Creek Road 308 Research Triangle Park, NC 27709 309 US 311 Email: naikumar@cisco.com 313 IJsbrand Wijnands 314 Cisco 315 De Kleetlaan 6a 316 Diegem 1831 317 Belgium 319 Email: ice@cisco.com 321 Andrew Dolganow 322 Alcatel-Lucent 323 600 March Rd. 324 Ottawa, Ontario K2K 2E6 325 Canada 327 Email: andrew.dolganow@alcatel-lucent.com 328 Tony Przygienda 329 Ericsson 330 300 Holger Way 331 San Jose, CA 95134 332 USA 334 Email: antoni.przygienda@ericsson.com 336 Jeffrey Zhang 337 Juniper Networks, Inc. 338 10 Technology Park Drive 339 Westford, MA 01886 340 USA 342 Email: zzhang@juniper.net 344 Sam Aldrin 345 Huawei Technologies 346 2330 Central Expressway 347 Santa Clara, CA 95051 348 USA 350 Email: zzhang@juniper.net