idnits 2.17.1 draft-ietf-bess-pta-flags-01.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 draft header indicates that this document updates RFC6514, but the abstract doesn't seem to directly say this. It does mention RFC6514 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 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 (August 6, 2015) is 3183 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 (==), 3 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: February 7, 2016 August 6, 2015 8 Registry and Extensions for 9 P-Multicast Service Interface Tunnel Attribute Flags 10 draft-ietf-bess-pta-flags-01.txt 12 Abstract 14 RFC6514 defines the "P-Multicast Service Interface Tunnel (PMSI 15 Tunnel) attribute". This attribute contains an octet of "flags". 16 Only one flag is defined in that RFC, but there is now a need to 17 define additional flags. Since the RFC did not create a registry for 18 the assignment of flag bits, this document updates the RFC by 19 creating a registry for that purpose. This document also defines a 20 new BGP Extended Community, "Additional PMSI Tunnel Attribute Flags", 21 that can be used to carry additional flags for the PMSI Tunnel 22 attribute. 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 February 7, 2016. 41 Copyright Notice 43 Copyright (c) 2015 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. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 [RFC6514] defines the "P-Multicast Service Interface Tunnel (PMSI 68 Tunnel) attribute". This attribute contains an octet of "flags". 69 Only one flag is defined in that RFC, but there is now a need to 70 define additional flags. Since the RFC did not create a registry for 71 the assignment of flag bits, this document creates a registry for 72 that purpose. In addition, there may be a need to define more than 73 eight flags. Therefore this document defines a new BGP Extended 74 Community, "Additional PMSI Tunnel Attribute Flags", that can be used 75 to carry additional flags for the PMSI Tunnel attribute. A registry 76 is also created for this extended community, allowing IANA to 77 allocate bits from the extended community's six-octet value field. 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Extending the PMSI Tunnel Attribute Flags Field 85 [RFC6514] defines only a single octet in the PMSI Tunnel attribute to 86 use for bit flags. This allows eight flags, which is unlikely to be 87 sufficient for all future applications. 89 This document defines a new Transitive Opaque Extended Community, 90 "Additional PMSI Tunnel Attribute Flags". It also defines a new bit 91 flag in the PMSI Tunnel Attribute flags field, called the "Extension" 92 flag. 94 The "Additional PMSI Tunnel Attribute Flags" Extended Community MUST 95 NOT be added to a BGP UPDATE message unless that message is also 96 carrying a PMSI Tunnel attribute. Further, when an "Additional PMSI 97 Tunnel Attribute Flags" Extended Community is added to a BGP UPDATE 98 message, the "Extension" flag of the PMSI Tunnel attribute flags 99 field MUST be set. If at any time the "Additional PMSI Tunnel 100 Attribute Flags" Extended Community is removed from the UPDATE 101 message, the "Extension" flag in the PMSI Tunnel attribute MUST be 102 cleared. 104 If a BGP speaker receives an UPDATE message that contains an 105 "Additional PMSI Tunnel Attribute Flags" Extended Community, but that 106 UPDATE message does not contain a PMSI Tunnel attribute, or the 107 "Extension" flag of the PMSI Tunnel attribute is not set, the 108 Extended Community SHOULD be removed and SHOULD NOT be redistributed. 109 The BGP UPDATE message MUST be processed (and if necessary, 110 redistributed) as if the Extended Community had not been present. 112 If a BGP speaker receives an UPDATE message that contains a PMSI 113 Tunnel attribute and does not contain an "Additional PMSI Tunnel 114 Attribute Flags" Extended Community, but the Extension flag of the 115 PMSI Tunnel attribute is set, the "treat-as-withdraw" procedure of 116 [ERRORS] MUST be applied. 118 3. IANA Considerations 120 IANA is requested to create a new registry called "P-Multicast 121 Service Interface Tunnel (PMSI Tunnel) Attribute Flags" in the 122 "Border Gateway Protocol (BGP) Parameters" registry. 124 Per [RFC6514] section 5, a PMSI Tunnel Attribute contains a "Flags" 125 octet. The Flags field is a single octet, with bits numbered, left- 126 to-right, from 0 to 7. IANA is requested to initialize the registry 127 as follows: 129 Bit Position Description Reference 130 (left to right) 131 0 unassigned 132 1 Extension This document 133 2 unassigned 134 3 unassigned 135 4 unassigned 136 5 unassigned 137 6 unassigned 138 7 Leaf Information Required (LIR) RFC6514 140 PMSI Tunnel Attribute Flags 142 The registration procedure for this registry is Standards Action. 144 IANA is also requested to assign a codepoint from the "Transitive 145 Opaque Extended Community Sub-Types" registry for "Additional PMSI 146 Tunnel Attribute Flags". 148 IANA is further requested to establish a registry for the bit flags 149 carried in the Additional PMSI Tunnel Attribute Flags extended 150 community. The bits shall be numbered 0-47, with 0 being the most 151 significant bit and 47 being the least significant bit. The 152 registration policy for this registry shall be "Standards Action". 153 Initially, bits 0-47 are unassigned. This registry belongs with the 154 BGP Extended Communities registries. 156 4. Security Considerations 158 No security considerations are raised by this document. 160 5. Normative References 162 [ERRORS] Chen, E., Scudder, J., Mohapatra, P., and K. Patel, 163 "Revised Error Handling for BGP UPDATE Messages", 164 internet-draft draft-ietf-idr-error-handling-19, April 165 2015. 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, 169 DOI 10.17487/RFC2119, March 1997, 170 . 172 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 173 Encodings and Procedures for Multicast in MPLS/BGP IP 174 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 175 . 177 Authors' Addresses 179 Eric C. Rosen 180 Juniper Networks, Inc. 181 10 Technology Park Drive 182 Westford, Massachusetts 01886 183 United States 185 Email: erosen@juniper.net 186 Thomas Morin 187 Orange 188 2, avenue Pierre-Marzin 189 22307 Lannion Cedex 190 France 192 Email: thomas.morin@orange.com