idnits 2.17.1 draft-ietf-bess-pta-flags-03.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 RFC6514, updated by this document, for RFC5378 checks: 2006-08-01) -- 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 (May 3, 2016) is 2915 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 BESS Working Group E. Rosen 3 Internet-Draft Juniper Networks, Inc. 4 Updates: 6514 (if approved) T. Morin 5 Intended status: Standards Track Orange 6 Expires: November 4, 2016 May 3, 2016 8 Registry and Extensions for 9 P-Multicast Service Interface Tunnel Attribute Flags 10 draft-ietf-bess-pta-flags-03.txt 12 Abstract 14 The BGP-based control procedures for Multicast Virtual Private 15 Networks make use of a BGP attribute known as the "P-Multicast 16 Service Interface (PMSI) Tunnel" attribute. The attribute contains a 17 one-octet "Flags" field. The purpose of this document is to 18 establish an IANA registry for the assignment of the bits in this 19 field. Since the Flags field contains only eight bits, this document 20 also defines a new BGP Extended Community, "Additional PMSI Tunnel 21 Attribute Flags", that can be used to carry additional flags for the 22 PMSI Tunnel attribute. This document updates RFC 6514. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 4, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Extending the PMSI Tunnel Attribute Flags Field . . . . . . . 2 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 A BGP attribute known as the "P-Multicast Service Interface (PMSI) 69 Tunnel" attribute is defined in [RFC6514]. This attribute contains a 70 one-octet "Flags" field. Only one flag is defined in that RFC, but 71 there is now a need to define additional flags. However, that RFC 72 did not create an IANA registry for the assignment of bits in the 73 "Flags" field. This document creates a registry for that purpose. 74 In addition, there may be a need to define more than eight flags. 75 Therefore this document defines a new BGP Extended Community, 76 "Additional PMSI Tunnel Attribute Flags", that can be used to carry 77 additional flags for the PMSI Tunnel attribute. A registry is also 78 created for this Extended Community, allowing IANA to assign flag 79 bits from the Extended Community's six-octet value field. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Extending the PMSI Tunnel Attribute Flags Field 87 In [RFC6514], only a single octet in the "PMSI Tunnel" attribute is 88 defined to carry bit flags. This allows eight flags, which is 89 unlikely to be sufficient for all future applications. 91 This document defines a new Transitive Opaque Extended Community 92 ([RFC4360], [RFC7153]), "Additional PMSI Tunnel Attribute Flags". It 93 also defines a new bit flag in the "PMSI Tunnel" attribute Flags 94 field, called the "Extension" flag. 96 The "Additional PMSI Tunnel Attribute Flags" Extended Community MUST 97 NOT be carried by a given BGP UPDATE message unless the following 98 conditions both hold: 100 o the given BGP UPDATE message is also carrying a "PMSI Tunnel" 101 attribute, and 103 o the "Extension" flag of that "PMSI Tunnel" attribute's "Flags" 104 field is set. 106 The six-octet value field of the "Additional PMSI Tunnel Attribute 107 Flags" Extended Community is considered to be a string of 48 bit 108 flags. As shown in Figure 1, the leftmost bit (the most significant 109 bit of the most significant octet) is bit 0, and the rightmost bit 110 (the least significant bit of the least significant octet) is bit 47. 112 0 1 2 3 113 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 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | | | | | 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 3 4 119 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Figure 1: Value Field of the Additional PMSI Tunnel Attribute Flags 125 Extended Community 127 A BGP speaker MUST NOT attach more than one "Additional PMSI Tunnel 128 Attribute Flags" Extended Community to a given BGP UPDATE. If a 129 given BGP UPDATE already contains an "Additional PMSI Tunnel 130 Attribute Flags" Extended Community, a BGP speaker MUST NOT attach 131 any additional such Extended Communities. 133 If a BGP speaker receives a BGP UPDATE with more than one "Additional 134 PMSI Tunnel Attribute Flags" Extended Communities attached, only the 135 flag settings in first occurrence of the Extended Community are 136 significant. Flag settings in subsequent occurrences of the Extended 137 Community MUST be ignored. When propagating the UPDATE, all 138 instances of the Extended Community other than the first SHOULD be 139 removed. 141 Suppose a BGP speaker receives an UPDATE message that contains a 142 "PMSI Tunnel" attribute, but does not contain an "Additional PMSI 143 Tunnel Attribute Flags" Extended Community. If the "Extension" flag 144 of the "PMSI Tunnel" attribute is set, the UPDATE is considered to be 145 malformed, and the "treat-as-withdraw" procedure of [RFC7606] MUST be 146 applied. 148 If a BGP speaker receives an UPDATE message that contains one or more 149 "Additional PMSI Tunnel Attribute Flags" Extended Communities, but 150 either (a) that UPDATE message does not contain a PMSI Tunnel 151 attribute, or (b) the Extension flag of the PMSI Tunnel attribute is 152 not set, then the Extended Community(ies) SHOULD be removed and 153 SHOULD NOT be redistributed. The BGP UPDATE message MUST be 154 processed (and if necessary, redistributed) as if the Extended 155 Community(ies) had not been present. 157 A BGP speaker that supports the current document, but does not 158 recognize a particular flag (either in the" PMSI Tunnel" attribute 159 "Flags" field or in the "Additional PMSI Tunnel Attribute Flags" 160 Extended Community) MUST simply ignore that flag. If the BGP speaker 161 propagates either the PMSI Tunnel attribute or the "Additional PMSI 162 Tunnel Attribute Flags" Extended Community or both along with the 163 UPDATE message, it SHOULD leave the setting of the flag unchanged. 165 It is possible that a particular application will require all members 166 of a particular set of BGP speakers to support a particular flag. 167 How it is determined whether all such BGP speakers support that flag 168 is outside the scope of this document. 170 In some situations, a BGP speaker may need to modify or replace the 171 "PMSI Tunnel" attribute before propagating an UPDATE. If the 172 "Extension" flag of the "PMSI Tunnel" attribute was set before the 173 attribute is modified or replaced, but that flag is no longer set 174 after the attribute is modified or replaced, any "Additional PMSI 175 Tunnel Attribute Flags" Extended Communities MUST be removed before 176 the UPDATE is propagated. If the PMSI Tunnel attribute is removed 177 entirely before an UPDATE is propagated, the "Additional PMSI Tunnel 178 Attribute Flags" Extended Communities (if any) MUST also be removed. 180 3. IANA Considerations 182 IANA is requested to create a new registry called "P-Multicast 183 Service Interface (PMSI) Tunnel Attribute Flags" in the "Border 184 Gateway Protocol (BGP) Parameters" registry. 186 Per [RFC6514] section 5, a "PMSI Tunnel" attribute contains a "Flags" 187 octet. The Flags field is a single octet, with bits numbered, left- 188 to-right, from 0 to 7. IANA is requested to initialize the registry 189 as follows: 191 Bit Position Description Reference 192 (left to right) 193 0 unassigned 194 1 Extension This document 195 2 unassigned 196 3 unassigned 197 4 unassigned 198 5 unassigned 199 6 unassigned 200 7 Leaf Information Required (L) RFC6514 202 PMSI Tunnel Attribute Flags 204 The registration procedure for this registry is Standards Action. 206 IANA is also requested to assign a codepoint, from the "First Come, 207 First Served" range of the Transitive Opaque Extended Community Sub- 208 Types registry, for "Additional PMSI Tunnel Attribute Flags". 209 [TO BE REMOVED: This registration should take place at the following 210 location: http://www.iana.org/assignments/bgp-extended-communities 211 /bgp-extended-communities.xhtml#trans-opaque] 213 IANA is further requested to establish a registry for the bit flags 214 carried in the "Additional PMSI Tunnel Attribute Flags" Extended 215 Community. The bits shall be numbered 0-47, with 0 being the most 216 significant bit and 47 being the least significant bit. The 217 registration policy for this registry shall be "Standards Action". 218 [TO BE REMOVED: The creation of the registry should take place at the 219 following location: http://www.iana.org/assignments/bgp-extended- 220 communities/bgp-extended-communities.xhtml] 221 The initial registry should be as follows: 223 Bit Flag Name Reference 225 0-47 unassigned 227 Additional PMSI Tunnel Attribute Flags 229 4. Acknowledgments 231 The authors wish to thank Martin Vigoureux for his review of this 232 document. We also thank Christian Huitema and Alexey Melnikov for 233 their review and comments. 235 5. Security Considerations 237 This document establishes an IANA registry, and defines a new 238 Transitive Opaque Extended Community ([RFC4360], [RFC7153]). 240 Establishment of an IANA registry does not raise any security 241 considerations. 243 While this document defines a new Extended Community for carrying bit 244 flags, it does not define any of the bit flags in that Extended 245 Community. Therefore no security considerations are raised. 247 This document defines a new flag, the "Extension" flag, in the "PMSI 248 Tunnel" attribute. If a particular UPDATE contains "PMSI Tunnel" 249 attribute with this flag set, but the UPDATE does not contain an 250 "Additional PMSI Tunnel Attribute Flags" Extended Community, then the 251 UPDATE is considered to be malformed, and the "treat-as-withdraw" 252 procedure of [RFC7606] is invoked. Thus one can cause an UPDATE to 253 be treated as a withdrawal by incorrectly setting this bit. 255 6. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, 259 DOI 10.17487/RFC2119, March 1997, 260 . 262 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 263 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 264 February 2006, . 266 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 267 Encodings and Procedures for Multicast in MPLS/BGP IP 268 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 269 . 271 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 272 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 273 March 2014, . 275 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 276 Patel, "Revised Error Handling for BGP UPDATE Messages", 277 RFC 7606, DOI 10.17487/RFC7606, August 2015, 278 . 280 Authors' Addresses 282 Eric C. Rosen 283 Juniper Networks, Inc. 284 10 Technology Park Drive 285 Westford, Massachusetts 01886 286 United States 288 Email: erosen@juniper.net 290 Thomas Morin 291 Orange 292 2, avenue Pierre-Marzin 293 22307 Lannion Cedex 294 France 296 Email: thomas.morin@orange.com