idnits 2.17.00 (12 Aug 2021) /tmp/idnits54903/draft-ietf-pim-hierarchicaljoinattr-08.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 (Using the creation date from RFC5384, updated by this document, for RFC5378 checks: 2005-10-20) -- 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 (April 25, 2016) is 2210 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 issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft J. Arango 4 Updates: 5384 (if approved) Cisco Systems 5 Intended status: Standards Track I. Kouvelas 6 Expires: October 27, 2016 Arista Networks 7 April 25, 2016 9 Hierarchical Join/Prune Attributes 10 draft-ietf-pim-hierarchicaljoinattr-08.txt 12 Abstract 14 This document defines a hierachical method of encoding Join 15 attributes, providing a more efficient encoding when the same 16 attribute values need to be specified for multiple sources in a PIM 17 Join/Prune message. This document updates RFC 5384 by renaming the 18 Encoding Type registry specified there. 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 October 27, 2016. 37 Copyright Notice 39 Copyright (c) 2016 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 56 3. Hierarchical Join/Prune Attribute Definition . . . . . . . . 3 57 4. PIM Address Encoding Types . . . . . . . . . . . . . . . . . 6 58 5. Hierarchical Join/Prune Attribute Hello Option . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 PIM Join attributes as defined in [RFC5384] allow for specifying a 67 set of attributes for each of the joined or pruned sources in a PIM 68 Join/Prune message. Attributes must be separately specified for each 69 individual source in the message. However, in some cases the same 70 attributes and values need to be specified for some, or even all, the 71 sources in the message. The attributes and their values then need to 72 be repeated for each of the sources where they apply. 74 This document provides a hierarchical way of encoding attributes and 75 their values in a Join/Prune message, so that if the same attribute 76 and value is to apply for all the sources, it needs only be specified 77 once in the message. Similarly, if all the sources in a specific 78 group set share a specific attribute and value, it needs only be 79 specified once for the entire group set. 81 This document extends [RFC5384] by specifying that the encoding type 82 defined there also applies to Encoded-Unicast and Encoded-Group 83 formats. This document also updates RFC 5384 by renaming the PIM 84 Encoded-Source Address Encoding Type Field registry to be a PIM 85 Address Encoding Type registry. The content of the registry remains 86 the same. The encoding type used for Join attributes is however 87 still limited to be used in Join/Prune messages. Note that Join 88 attributes, as they are referred to in [RFC5384], also apply to 89 pruned sources in a Join/Prune message. Thus the more correct name 90 Join/Prune attributes will be used throughout the rest of this 91 document. 93 This document allows Join/Prune attributes to be specified in the 94 Upstream Neighbor Address field, and also in the Multicast Group 95 Address field, of a Join/Prune message. It defines how this is used 96 to specify the same Join/Prune attribute and value for multiple 97 sources. This document also defines a new Hello Option to indicate 98 support for the hierarchical encoding specified. 100 2. Requirements Notation 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 3. Hierarchical Join/Prune Attribute Definition 108 The format of a PIM Join/Prune message is defined in [RFC7761] as 109 follows: 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |PIM Ver| Type | Reserved | Checksum | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Upstream Neighbor Address (Encoded-Unicast format) | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Reserved | Num groups | Holdtime | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Multicast Group Address 1 (Encoded-Group format) | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Number of Joined Sources | Number of Pruned Sources | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Joined Source Address 1 (Encoded-Source format) | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | . | 127 | . | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Joined Source Address n (Encoded-Source format) | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | Pruned Source Address 1 (Encoded-Source format) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | . | 134 | . | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Pruned Source Address n (Encoded-Source format) | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | . | 139 | . | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Multicast Group Address m (Encoded-Group format) | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Number of Joined Sources | Number of Pruned Sources | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Joined Source Address 1 (Encoded-Source format) | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | . | 148 | . | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Joined Source Address n (Encoded-Source format) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Pruned Source Address 1 (Encoded-Source format) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | . | 155 | . | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Pruned Source Address n (Encoded-Source format) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 The message contains a single Upstream Neighbor Address, and one or 161 more group sets. Each group set contains a Group Address and two 162 source lists, the Joined Sources and the Pruned Sources. The 163 Upstream Neighbor Address, the group addresses and the source 164 addresses are encoded in Encoded-Unicast format, Encoded-Group format 165 and Encoded-Source format, respectively. This document extends the 166 use of the source address encoding defined in [RFC5384] to also apply 167 to the Upstream Neighbor Address and the Group Address fields, see 168 Section 4. 170 For a Join/Prune message a hierarchy of Join/Prune attributes is 171 defined. Attributes at the highest level, that is the least 172 specific, apply to every source in the message. These are encoded in 173 the Upstream Neighbor Address. Attributes at the next more specific 174 level apply to every source in a group set. They are encoded in a 175 Group Address. And finally there are attributes that apply to a 176 single source, encoded in the source address as defined in [RFC5384]. 178 The complete set of attributes that apply to a given source is 179 obtained by combining the message wide attributes, the attributes of 180 the group set that the source belongs to, and the source specific 181 attributes. However, if the same attribute is specified at multiple 182 levels, then the one at the most specific level overrides the other 183 instances of the attribute. Note that the set of attributes and 184 their values is formed before processing the attributes. Hence a 185 value that is invalid for a given type might override a valid value 186 at a higher level. 188 As an example, say that for a given source we have attributes T_1 189 with value V_1, T_2 with value V_2, and T_3 with value V_3. Also 190 that in the Group Address of the source's group set we have 191 attributes T_1 with value V_6, and T_4 with value V_4. And that we 192 in the Upstream Neighbor Address have encoded the attributes T_1 with 193 value V_7, T_4 with value V_8, and T_5 with value V_5. The 194 attributes applied to the given source will be T_1 with value V_1, 195 T_2 with value V_2, T_3 with value V_3, T_4 with value V_4 and T_5 196 with value V_5. Here we have T_1 with different values at each 197 level, so we use the value specified at the source level. Also we 198 have T_4 with different values at the group and message levels, so we 199 use the value at the group level. Here it could be that V_1 is not a 200 valid value for T_1, but it still overrides the values at the higher 201 levels as we do not process the attributes until after forming the 202 set. 204 Note that Join/Prune attributes are still applied to sources as 205 specified in [RFC5384]. This document does not change the meaning of 206 any attributes, it is simply a more compact way of encoding an 207 attribute when the same attribute and value applies to multiple 208 sources. E.g., with the example above, we would have the exact same 209 meaning if we instead had encoded all the attributes T1, ..., T5 with 210 the respective values V1, ..., V5 in the source address. 212 4. PIM Address Encoding Types 214 Addresses in PIM messages are specified together with an address 215 family and an encoding type. This applies to Encoded-Unicast, 216 Encoded-Group and Encoded-Source addresses. The encoding types allow 217 the address to be encoded according to different schemes. An 218 encoding type indicates how an address is encoded irrespective of 219 address type, Encoded-Unicast, Encoded-Group or Encoded-Source. It 220 is possible that there will be future encoding types that do not 221 apply to all address types though. This means that as currently 222 defined, 0 is native encoding, and 1 is Join/Prune attributes 223 encoding, encoded according to [RFC5384]. Note that as specified in 224 [RFC5384], a type 1 Encoded Address MUST contain at least one Join/ 225 Prune attribute. 227 5. Hierarchical Join/Prune Attribute Hello Option 229 A PIM router indicates that it supports the mechanism specified in 230 this document by including the Hierarchical Join/Prune Attribute 231 Hello Option in its PIM Hello message. When this new Hello Option is 232 included, it MUST also include the Join-Attribute Hello option as 233 specified in [RFC5384]. The format of the Hierarchical Join/Prune 234 Attribute Hello Option is defined to be: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | OptionType = TBD | OptionLength = 0 | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 OptionType = TBD, OptionLength = 0. Note that there is no option 243 value included. 245 A PIM router MUST NOT send a Join/Prune message with Join/Prune 246 attributes encoded in the Upstream Neighbor Address or any of the 247 group addresses out any interface on which there is a PIM neighbor 248 that has not included this option in its Hellos. Even a router that 249 is not the upstream neighbor must be able to parse the message in 250 order to perform Join suppression and Prune override. 252 6. Security Considerations 254 This document specifies a more compact encoding of Join/Prune 255 attributes. Use of the encoding has no impact on security aside from 256 using the encoding in [RFC5384]. For instance an attack with a 257 forged message with certain attribute values is equally difficult 258 independent of which encoding is used. If an attribute that applies 259 to the entire message is wrong, then that may cause an issue for all 260 the sources in the message. But without this encoding, one would 261 instead include that attribute for every single source, and that 262 would also cause an issue for all the sources in the message. 264 7. IANA Considerations 266 The current PIM Encoded-Source Address Encoding Type Field registry 267 needs to be renamed to a PIM Address Encoding Type registry. The 268 content of the registry remains the same. The Hierarchical Join/ 269 Prune Attribute Hello Option needs to be added to the PIM-Hello 270 Options registry, and TBD above must be replaced by the assigned 271 value. 273 8. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 281 Independent Multicast (PIM) Join Attribute Format", 282 RFC 5384, DOI 10.17487/RFC5384, November 2008, 283 . 285 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 286 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 287 Multicast - Sparse Mode (PIM-SM): Protocol Specification 288 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 289 2016, . 291 Authors' Addresses 293 Stig Venaas 294 Cisco Systems 295 Tasman Drive 296 San Jose, CA 95134 297 USA 299 Email: stig@cisco.com 300 Jesus Arango 301 Cisco Systems 302 Tasman Drive 303 San Jose, CA 95134 304 USA 306 Email: jearango@cisco.com 308 Isidor Kouvelas 309 Arista Networks 310 5453 Great America Parkway 311 Santa Clara, CA 95054 312 USA 314 Email: kouvelas@arista.com