idnits 2.17.1 draft-przygienda-bier-isis-ranges-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 (September 27, 2014) is 3496 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) -- No information found for draft-kumar-ospf-bier-extension - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-kumar-ospf-bier-extension-00' == 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 ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) ** Downref: Normative reference to an Informational RFC: RFC 7142 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Przygienda 3 Internet-Draft Ericsson 4 Intended status: Standards Track September 27, 2014 5 Expires: March 31, 2015 7 BIER support via ISIS 8 draft-przygienda-bier-isis-ranges-00 10 Abstract 12 Specification of an ISIS extension to support BIER domains. 14 Requirements Language 16 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 17 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 18 document are to be interpreted as described in RFC 2119 [RFC2119]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 31, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 57 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. BIER as Capability . . . . . . . . . . . . . . . . . . . 4 59 4.2. BIER Domain Identifier . . . . . . . . . . . . . . . . . 4 60 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Enabling a BIER Domain . . . . . . . . . . . . . . . . . 4 62 5.2. Length of Bitmasks . . . . . . . . . . . . . . . . . . . 4 63 5.2.1. Special Consideration . . . . . . . . . . . . . . . . 5 64 5.3. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5 65 5.4. Label Advertisements . . . . . . . . . . . . . . . . . . 5 66 5.4.1. Special Consideration . . . . . . . . . . . . . . . . 5 67 5.5. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 5 68 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. BIER BFR sub-TLV . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 72 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Bit Index Explicit Replication (BIER) 78 [I-D.draft-wijnands-bier-architecture-00] defines an architecture 79 where all intended multicast receivers are encoded as bitmask in the 80 Multicast packet header within different encapsulations such as 81 [I-D.draft-wijnands-mpls-bier-encapsulation-00]. A router that 82 receives such a packet will forward the packet based on the Bit 83 Position in the packet header towards the receiver(s), following a 84 precomputed tree for each of the bits in the packet. Each receiver 85 is represented by a unique bit in the bitmask. 87 This document presents necessary extensions to the currently deployed 88 ISIS for IP [RFC7142] protocol to support distribution of information 89 necessary for operation of BIER domains. This document defines a new 90 TLV to be distributed by every router participating in such BIER 91 domains. 93 2. Terminology 95 Some of the terminology specified in 96 [I-D.draft-wijnands-bier-architecture-00] is replicated here and 97 extended by necessary definitions: 99 BIER: Bit Index Explicit Replication (The overall architecture of 100 forwarding multicast using a Bit Position). 102 BIER-OL: BIER Overlay Signaling. (The method for the BFIR to learn 103 about BFER's). 105 BM: Bit Mask (A bit stream of a certain fixed length. Each Bit 106 represents a receiver). 108 P-BM: Packet Bit Mask (A Bit Mask included in the Multicast Packet). 110 BP: Bit Position (A single Bit from the Bit Mask that represents a 111 receiver). 113 BFR: Bit Forwarding Router (A router that participates in Bit Index 114 Multipoint Forwarding). 116 BFIR: Bit Forwarding Ingress Router (The ingress border router that 117 inserts the BM into the packet). 119 BFER: Bit Forwarding Egress Router. A router that participates in 120 Bit Index Forwarding as leaf. Each BFER must be a BFR. 122 BFT: Bit Forwarding Tree used to reach all BFERs in a domain. 124 BIFT: Bit Index Forwarding Table (A Bit index forwarding table). 126 BMS: Bit Mask Set. Set containing bit positions of all BFER 127 participating in a set. 129 BMP: Bit Mask Position, a given bit in a BMS. 131 3. IANA Considerations 133 This document requests IANA to assign sub-TLV type values from the 134 ISIS router capability TLV [RFC4971] registry. 136 4. Concepts 137 4.1. BIER as Capability 139 This draft introduces a sub-TLV in the router capabilites TLV 140 [RFC4971] to distribute the information. Any of the router's 141 loopback addresses that it originates are considered BFR prefixes as 142 required by [I-D.draft-wijnands-bier-architecture-00]. The question 143 whether a particular loopback address is routable in a specific 144 topology [RFC5120] can be resolved by 145 [I-D.draft-xu-isis-routable-ip-address-01]. 147 4.2. BIER Domain Identifier 149 ISIS can carry BIER information not only for a single BIER domain but 150 for multiple, distinct domains. This allows to run many disjoint 151 BIER layers within the same Multi-Topology [RFC5120] easily instead 152 of always forcing different multicast overlays to share the exactly 153 same set of BFRs and resources. Moreover, multi topology [RFC5120] 154 can be used for the purpose of restricting links that certain set of 155 BIER domains can use or change metrics of such links. A BIER set is 156 therefore always uniquely identified by the tuple of topology T, 157 domain D it belongs to and its number S, denoted as . The 158 domain itself has as its unique attributes the encapsulation, bitmask 159 length and the type of tree it is using to forward BIER frames 160 (currently always SPF). 162 5. Procedures 164 5.1. Enabling a BIER Domain 166 A given domain D in a multi-topology T [RFC5120] (denoted as 167 from now on) is normally not advertised to preserve the scaling of 168 the protocol (i.e. ISIS carries no TLVs containing any of the 169 elements related to ) and is enabled by a first BIER sub-TLV 170 (Section 6.1) containing being advertised into the area. The 171 trigger itself is outside the scope of this draft but can be .e.g. a 172 VPN desiring to initiate a domain as MP2MP or P2MP tree or a BMP 173 being administratively assigned to a BFER and advertised via BIER TLV 174 into the area or any other means within Multicast BIER Overlay(s) 175 using BIER domains. 177 5.2. Length of Bitmasks 179 All routers in the flooding scope of the BIER TLVs SHOULD advertise 180 the same bit mask length for a given . A router discovering 181 bitmask lengths advertised that are shorter than its own MUST report 182 a misconfiguration of a specific . Each router MUST compute 183 BFTs for using only routers having the same mask length as its 184 own advertised Bit Mask Length in BIER sub-TLV for . 186 5.2.1. Special Consideration 188 The same router MAY advertise for different combinations two 189 different mask lengths. This allows to cleanly delineate domains 190 crossing the same router but using different mask lengths in the 191 encoding, even within the same topology. 193 5.3. Encapsulation 195 Since encapsulation is an attribute of a domain just like 196 bitmask length, all rules that apply to Bitmask Length per 197 Section 5.2 apply to it well. 199 5.4. Label Advertisements 201 Each router MAY advertise within the sub-TLV of an according 202 (denoted further as TLV) a valid starting label value and a non- 203 zero range length. It MUST advertise a valid label value and a non- 204 zero range length IF it has computed itself as being on the BFT 205 rooted at any of the BFRs with valid BFR-ids (except itself) 206 participating in . 208 A router CAN withdraw its TLV if it does not want to participate 209 in the domain due to resource constraints, label space optimization, 210 administrative configuration or any other reasons. In case a router 211 advertises a label range size of 0 for it MUST be excluded from 212 the BIER BFTs for . 214 5.4.1. Special Consideration 216 A router MUST advertise a for label range size that guarantees 217 to cover the maximum BFR-id injected into (which implies a 218 certain set id as described in 219 [I-D.draft-wijnands-bier-architecture-00]). Any router that violates 220 this condition MUST be excluded from BIER BFTs for . 222 5.5. BFR-id Advertisements 224 Each BFER MAY advertise with its TLV the according BFR-id that 225 it has administratively chosen. 227 If two BFRs advertise in their TLV the same value for BFR-id, 228 all routers MUST report it as misconfiguration and disregard those 229 routers for all BIER calculations and procedures to align with 230 [I-D.draft-wijnands-bier-architecture-00]. Such routers with 231 colliding assignments MAY still act as BFIRs but will be never able 232 to receive traffic. 234 6. Packet Formats 236 All ISIS BIER information is carried within the router capability TLV 237 [RFC4971] with S bit clear. 239 6.1. BIER BFR sub-TLV 241 This sub-TLV carries the information for the BIER domains that the 242 router participates in as BFR. It can repeat multiple times. If the 243 same is advertised more than once, the first one in the first 244 sub-TLV in the fragment with the lowest ID MUST be used. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Type | Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | MT-ID | Bier Domain ID | Bit Msk Len | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Lbl Range Size| Label | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | BFR-id |A|R|T| Reserv | Encaps | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Type: TBD1. 260 Length: 2 octets. 262 MT-ID: Multi-Topology [RFC5120], 1 octet. 264 BIER Domain ID: Unique identifier for a BIER domain, 2 octets. 266 Label Range Size: Number of labest in the range used on 267 encapsulation for this BIER domain, 1 octet. 269 Label: First label of the range used on encapsulation for this BIER 270 domain, 20 bits. The label is used by e.g. 271 [I-D.draft-wijnands-mpls-bier-encapsulation-00] to forward traffic 272 to sets of BFERs. 274 Local BitMask Length: Bitmask length for this BFR per 275 [I-D.draft-wijnands-bier-architecture-00]. 277 Encapsulation Type: The BIER encapsulation type, 1 octet. Allowed 278 values are: 280 0 MPLS per [I-D.draft-wijnands-mpls-bier-encapsulation-00]. 282 A Indicates administratively set value if set, otherwise the BFR-id 283 value MUST be considered as not assigned in this TLV. 285 R Reserved for future use. MUST be 0. 287 T Reserved for future use. MUST be 0. 289 Reserved MUST be 0 on send, ignored on receive. 291 7. Security Considerations 293 The extension does not introduce any known new protocol 294 vulnerabilities. 296 8. Acknowledgements 298 The draft is aligned with the 299 [I-D.draft-kumar-ospf-bier-extension-00] draft as far as the protocol 300 mechanisms overlap. 302 9. Normative References 304 [I-D.draft-kumar-ospf-bier-extension-00] 305 Psenak, P. and IJ. Wijnands, "OSPF Extension for Bit Index 306 Explicit Replication", internet-draft draft-ietf-ospf- 307 prefix-link-attr-00.txt, September 2014. 309 [I-D.draft-wijnands-bier-architecture-00] 310 Wijnands, IJ., "Stateless Multicast using Bit Index 311 Explicit Replication Architecture", internet-draft draft- 312 wijnands-bier-architecture-00.txt, February 2014. 314 [I-D.draft-wijnands-mpls-bier-encapsulation-00] 315 Wijnands et al., IJ., "Bit Index Explicit Replication 316 using MPLS encapsulation", internet-draft draft-wijnands- 317 mpls-bier-encapsulation-00.txt, February 2014. 319 [I-D.draft-xu-isis-routable-ip-address-01] 320 Chunduri et al., U., "Carrying Routable IP Addresses in 321 IS-IS Router Capability TLV", internet-draft draft-xu- 322 isis-routable-ip-address-01.txt, September 2014. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 328 System to Intermediate System (IS-IS) Extensions for 329 Advertising Router Information", RFC 4971, July 2007. 331 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 332 Topology (MT) Routing in Intermediate System to 333 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 335 [RFC7142] Shand, M. and L. Ginsberg, "Reclassification of RFC 1142 336 to Historic", RFC 7142, February 2014. 338 Author's Address 340 Tony Przygienda 341 Ericsson 342 300 Holger Way 343 San Jose, CA 95134 344 USA 346 Email: antoni.przygienda@ericsson.com