idnits 2.17.1 draft-ietf-bess-pta-flags-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 (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 (February 2, 2016) is 3005 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: August 5, 2016 February 2, 2016 8 Registry and Extensions for 9 P-Multicast Service Interface Tunnel Attribute Flags 10 draft-ietf-bess-pta-flags-02.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 August 5, 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 . . . . . . . . . . . . . . . . . . . . . 3 61 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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 of "Flags" field. Only one flag is defined in that RFC, 71 but there is now a need to define additional flags. However, that 72 RFC did not create an IANA registry for the assignment of bits in the 73 Flags field. This document creates a registry for that purpose. In 74 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 bits 79 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 "Additional PMSI Tunnel Attribute Flags". It also defines a new bit 93 flag in the PMSI Tunnel Attribute flags field, called the "Extension" 94 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 field is 104 set. 106 If a given BGP UPDATE message is carrying a PMSI Tunnel attribute, 107 but is not carrying an Additional PMSI Tunnel Attribute Flags 108 Extended Community, then the Extension flag in the PMSI Tunnel 109 attribute MUST be clear. 111 If a BGP speaker receives an UPDATE message that contains an 112 Additional PMSI Tunnel Attribute Flags Extended Community, but either 113 (a) that UPDATE message does not contain a PMSI Tunnel attribute, or 114 (b) the Extension flag of the PMSI Tunnel attribute is not set, then 115 the Extended Community SHOULD be removed and SHOULD NOT be 116 redistributed. The BGP UPDATE message MUST be processed (and if 117 necessary, redistributed) as if the Extended Community had not been 118 present. 120 Suppose a BGP speaker receives an UPDATE message that contains a PMSI 121 Tunnel attribute, but does not contain an Additional PMSI Tunnel 122 Attribute Flags Extended Community. If the Extension flag of the 123 PMSI Tunnel attribute is set, then the "treat-as-withdraw" procedure 124 of [RFC7606] MUST be applied. 126 3. IANA Considerations 128 IANA is requested to create a new registry called "P-Multicast 129 Service Interface (PMSI) Tunnel Attribute Flags" in the "Border 130 Gateway Protocol (BGP) Parameters" registry. 132 Per [RFC6514] section 5, a PMSI Tunnel Attribute contains a "Flags" 133 octet. The Flags field is a single octet, with bits numbered, left- 134 to-right, from 0 to 7. IANA is requested to initialize the registry 135 as follows: 137 Bit Position Description Reference 138 (left to right) 139 0 unassigned 140 1 Extension This document 141 2 unassigned 142 3 unassigned 143 4 unassigned 144 5 unassigned 145 6 unassigned 146 7 Leaf Information Required (L) RFC6514 148 PMSI Tunnel Attribute Flags 150 The registration procedure for this registry is Standards Action. 152 IANA is also requested to assign a codepoint, from the "First Come, 153 First Served" range of the Transitive Opaque Extended Community Sub- 154 Types registry, for "Additional PMSI Tunnel Attribute Flags". 155 [TO BE REMOVED: This registration should take place at the following 156 location: http://www.iana.org/assignments/bgp-extended-communities 157 /bgp-extended-communities.xhtml#trans-opaque] 159 IANA is further requested to establish a registry for the bit flags 160 carried in the Additional PMSI Tunnel Attribute Flags extended 161 community. The bits shall be numbered 0-47, with 0 being the most 162 significant bit and 47 being the least significant bit. The 163 registration policy for this registry shall be "Standards Action". 164 [TO BE REMOVED: The creation of the registry should take place at the 165 following location: http://www.iana.org/assignments/bgp-extended- 166 communities/bgp-extended-communities.xhtml] 167 The initial registry should be as follows: 169 Bit Flag Name Reference 171 0-47 unassigned 173 Additional PMSI Tunnel Attribute Flags 175 4. Acknowledgments 177 The authors wish to thank Martin Vigoureux for his review of this 178 document. 180 5. Security Considerations 182 This document establishes an IANA registry, and defines a new 183 transitive opaque Extended Community. 185 Establishment of an IANA registry does not raise any security 186 considerations. 188 While the document defines a new Extended Community for carrying bit 189 flags, it does not define any of the bit flags in that Extended 190 Community. Therefore no security considerations are raised. 192 6. Normative References 194 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 195 Requirement Levels", BCP 14, RFC 2119, 196 DOI 10.17487/RFC2119, March 1997, 197 . 199 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 200 Encodings and Procedures for Multicast in MPLS/BGP IP 201 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 202 . 204 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 205 Patel, "Revised Error Handling for BGP UPDATE Messages", 206 RFC 7606, DOI 10.17487/RFC7606, August 2015, 207 . 209 Authors' Addresses 211 Eric C. Rosen 212 Juniper Networks, Inc. 213 10 Technology Park Drive 214 Westford, Massachusetts 01886 215 United States 217 Email: erosen@juniper.net 219 Thomas Morin 220 Orange 221 2, avenue Pierre-Marzin 222 22307 Lannion Cedex 223 France 225 Email: thomas.morin@orange.com