idnits 2.17.1 draft-ietf-pim-reserved-bits-04.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 : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document obsoletes RFC5059, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC8364, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC5015, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC6754, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC7761, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document obsoletes RFC3973, but the header doesn't have an 'Obsoletes:' line to match this. -- The draft header indicates that this document updates RFC5059, but the abstract doesn't seem to directly say this. It does mention RFC5059 though, so this could be OK. -- The draft header indicates that this document updates RFC5015, but the abstract doesn't seem to directly say this. It does mention RFC5015 though, so this could be OK. -- The draft header indicates that this document updates RFC6754, but the abstract doesn't seem to directly say this. It does mention RFC6754 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3973, updated by this document, for RFC5378 checks: 2002-01-03) (Using the creation date from RFC5015, updated by this document, for RFC5378 checks: 2000-03-09) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 19, 2019) is 1652 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) -- Obsolete informational reference (is this intentional?): RFC 6166 (Obsoleted by RFC 8736) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft Cisco Systems, Inc. 4 Obsoletes: 6166 (if approved) A. Retana 5 Updates: 3973, 5015, 5059, 6754, 7761, Futurewei Technologies, Inc. 6 8364 (if approved) September 19, 2019 7 Intended status: Standards Track 8 Expires: March 22, 2020 10 PIM Message Type Space Extension and Reserved Bits 11 draft-ietf-pim-reserved-bits-04 13 Abstract 15 The PIM version 2 messages share a common message header format. The 16 common header definition contains eight reserved bits. This document 17 specifies how these bits may be used by individual message types, and 18 creates a registry containing the per-message-type usage. This 19 document also extends the PIM type space by defining three new 20 message types. For each of the new types, four of the previously 21 reserved bits are used to form an extended type range. 23 This document Updates RFC 7761 and RFC 3973 by defining the use of 24 the currently Reserved field in the PIM common header. This document 25 further updates RFC 7761 and RFC 3973, along with RFC 5015, RFC 5059, 26 RFC 6754 and RFC 8364, by specifying the use of the currently 27 Reserved bits for each PIM message. 29 This document obsoletes RFC 6166. 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 https://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 March 22, 2020. 48 Copyright Notice 50 Copyright (c) 2019 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 (https://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 2. Conventions used in this document . . . . . . . . . . . . . . 3 67 3. PIM header common format . . . . . . . . . . . . . . . . . . 3 68 4. Flag Bit definitions . . . . . . . . . . . . . . . . . . . . 3 69 4.1. Flag Bits for Type 4 (Bootstrap) . . . . . . . . . . . . 4 70 4.2. Flag Bits for Type 10 (DF Election) . . . . . . . . . . . 4 71 4.3. Flag Bits for Type 12 (PFM) . . . . . . . . . . . . . . . 4 72 4.4. Flag Bits for Types 13, 14 and 15 (Type Space Extension) 4 73 5. PIM Type Space Extension . . . . . . . . . . . . . . . . . . 4 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 78 8.2. Informative References . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 81 1. Introduction 83 The PIM version 2 messages share a common message header format 84 defined in the PIM Sparse Mode [RFC7761] specification. The common 85 header definition contains eight Reserved bits. While all message 86 types use this common header, there is no document formally 87 specifying that these bits are to be used per message type. 89 This document refers to the bits specified as Reserved in the common 90 PIM header [RFC7761] as PIM message type Flag Bits, or simply Flag 91 Bits, and it specifies that they are to be separately used on a per- 92 message-type basis. It creates a registry containing the per- 93 message-type usage. 95 This document Updates [RFC7761] and [RFC3973] by defining the use of 96 the currently Reserved field in the PIM common header. This document 97 further updates [RFC7761] and [RFC3973], along with [RFC5015], 98 [RFC5059], [RFC6754] and [RFC8364], by specifying the use of the 99 currently Reserved bits for each PIM message. 101 The currently defined PIM message types are in the range from 0 to 102 15. That type space is almost exhausted. Message type 15 was 103 reserved by [RFC6166] for type space extension. In Section 5, this 104 document specifies the use of the Flag Bits for message types 13, 14 105 and 15 in order to extend the PIM type space. This document 106 Obsoletes [RFC6166]. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. PIM header common format 118 The common PIM header is defined in section 4.9 of [RFC7761]. This 119 document updates the definition of the Reserved field and refers to 120 that field as PIM message type Flag Bits, or simply Flag Bits. The 121 new common header format is as below. 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 |PIM Ver| Type | Flag Bits | Checksum | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Figure 1: New Common Header 131 The Flag Bits field is defined in Section 4. All other fields remain 132 unchanged. 134 4. Flag Bit definitions 136 Unless otherwise specified, all the Flag Bits for each PIM type are 137 Reserved [RFC8126]. They MUST be set to zero on transmission, and 138 they MUST be ignored upon receipt. The specification of a new PIM 139 type MUST indicate whether the bits should be treated differently. 141 When defining Flag Bits, it is helpful to have a well-defined way of 142 referring to a particular bit. The most significant of the Flag 143 Bits, the bit immediately following the type field is referred to as 144 bit 7. The least significant, the bit right in front of the checksum 145 field is referred to as bit 0. This is shown in the diagram below. 147 0 1 2 3 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |PIM Ver| Type |7 6 5 4 3 2 1 0| Checksum | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 Figure 2: Flag Bits 155 4.1. Flag Bits for Type 4 (Bootstrap) 157 PIM message type 4 (Bootstrap) [RFC5059] defines Flag Bit 7 as No- 158 Forward. The usage of the bit is defined in that document. The 159 remaining Flag Bits are Reserved. 161 4.2. Flag Bits for Type 10 (DF Election) 163 PIM message type 10 (DF Election) [RFC5015] specifies that the four 164 most significant Flag Bits (bits 4-7) are to be used as a Subtype. 165 The usage of those bits is defined in that document. The remaining 166 Flag Bits are Reserved. 168 4.3. Flag Bits for Type 12 (PFM) 170 PIM message type 12 (PFM) [RFC8364] defines Flag Bit 7 as No-Forward. 171 The usage of the bit is defined in that document. The remaining Flag 172 Bits are Reserved. 174 4.4. Flag Bits for Types 13, 14 and 15 (Type Space Extension) 176 These types and the corresponding Flag Bits are defined in Section 5. 178 5. PIM Type Space Extension 180 This document defines types 13, 14 and 15, such that each of these 181 types has 16 subtypes, providing a total of 48 subtypes available for 182 future PIM extensions. This is achieved by defining a new SubType 183 field (see Figure 3) using the four most significant Flag Bits (bits 184 4-7). The notation type.subtype is used to reference these new 185 extended types. The remaining four Flag Bits (bits 0-3) are Reserved 186 to be used by each extended type (abbreviated as FB below). 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 |PIM Ver| Type |SubType| FB | Checksum | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 3: Sub-Types 196 6. Security Considerations 198 This document clarifies the use of the Flag Bits in the common PIM 199 header and it extends the PIM type space. As such, there is no 200 impact on security or changes to the considerations in [RFC7761] and 201 [RFC3973]. 203 7. IANA Considerations 205 This document updates the PIM Message Types registry to indicate 206 which Flag Bits are defined for use by each of the PIM message types. 207 The Registry should now reference this document instead of [RFC6166]. 208 The Registration Policy remains IETF Review [RFC8126]. Assignments 209 into this registry MUST define any non-default usage (see Section 4) 210 of the Flag Bits in addition to defining the Type. 212 The updated PIM Message Types registry is shown below. 214 Type Name Flag Bits Reference 215 --------------------------------------------------------------------- 216 0 Hello 0-7: Reserved [RFC3973][RFC7761] 218 1 Register 0-7: Reserved [RFC7761] 220 2 Register Stop 0-7: Reserved [RFC7761] 222 3 Join/Prune 0-7: Reserved [RFC3973][RFC7761] 224 4 Bootstrap 0-6: Reserved [RFC5059][RFC7761] 225 7: No-Forward [RFC5059] 227 5 Assert 0-7: Reserved [RFC3973][RFC7761] 229 6 Graft 0-7: Reserved [RFC3973] 231 7 Graft-Ack 0-7: Reserved [RFC3973] 233 8 Candidate RP 0-7: Reserved [RFC7761] 234 Advertisement 236 9 State Refresh 0-7: Reserved [RFC3973] 238 10 DF Election 0-3: Reserved [RFC5015] 239 4-7: Subtype [RFC5015] 241 11 ECMP Redirect 0-7: Reserved [RFC6754] 243 12 PIM Flooding Mechanism 0-6: Reserved [RFC8364] 244 7: No-Forward [RFC8364] 246 13.0-15.15 Unassigned 0-3: Unassigned [this document] 248 Table 1: Updated PIM Message Types Registry 250 The Unassigned types above, as explained in Section 5, use the 251 extended type notation of type.subtype. Each extended type only has 252 4 Flag Bits available. New extended message types should be assigned 253 conscutively, starting with 13.0, then 13.1, etc. 255 8. References 257 8.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, 261 DOI 10.17487/RFC2119, March 1997, 262 . 264 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 265 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 266 Multicast - Sparse Mode (PIM-SM): Protocol Specification 267 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 268 2016, . 270 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 271 Writing an IANA Considerations Section in RFCs", BCP 26, 272 RFC 8126, DOI 10.17487/RFC8126, June 2017, 273 . 275 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 276 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 277 May 2017, . 279 8.2. Informative References 281 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 282 Independent Multicast - Dense Mode (PIM-DM): Protocol 283 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 284 January 2005, . 286 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 287 "Bidirectional Protocol Independent Multicast (BIDIR- 288 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 289 . 291 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 292 "Bootstrap Router (BSR) Mechanism for Protocol Independent 293 Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 294 2008, . 296 [RFC6166] Venaas, S., "A Registry for PIM Message Types", RFC 6166, 297 DOI 10.17487/RFC6166, April 2011, 298 . 300 [RFC6754] Cai, Y., Wei, L., Ou, H., Arya, V., and S. Jethwani, 301 "Protocol Independent Multicast Equal-Cost Multipath 302 (ECMP) Redirect", RFC 6754, DOI 10.17487/RFC6754, October 303 2012, . 305 [RFC8364] Wijnands, IJ., Venaas, S., Brig, M., and A. Jonasson, "PIM 306 Flooding Mechanism (PFM) and Source Discovery (SD)", 307 RFC 8364, DOI 10.17487/RFC8364, March 2018, 308 . 310 Authors' Addresses 312 Stig Venaas 313 Cisco Systems, Inc. 314 Tasman Drive 315 San Jose CA 95134 316 USA 318 Email: stig@cisco.com 320 Alvaro Retana 321 Futurewei Technologies, Inc. 322 2330 Central Expressway 323 Santa Clara CA 95050 324 USA 326 Email: alvaro.retana@futurewei.com