diff options
Diffstat (limited to 'doc/rfc/rfc7902.txt')
| -rw-r--r-- | doc/rfc/rfc7902.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc7902.txt b/doc/rfc/rfc7902.txt new file mode 100644 index 0000000..370ac78 --- /dev/null +++ b/doc/rfc/rfc7902.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) E. Rosen +Request for Comments: 7902 Juniper Networks, Inc. +Updates: 6514 T. Morin +Category: Standards Track Orange +ISSN: 2070-1721 June 2016 + + + Registry and Extensions for + P-Multicast Service Interface Tunnel Attribute Flags + +Abstract + + The BGP-based control procedures for Multicast Virtual Private + Networks (MVPNs) make use of a BGP attribute known as the + "P-Multicast Service Interface (PMSI) Tunnel" attribute. The + attribute contains a one-octet "Flags" field. The purpose of this + document is to establish an IANA registry for the assignment of the + bits in this field. Since the "Flags" field contains only eight + bits, this document also defines a new BGP Extended Community, + "Additional PMSI Tunnel Attribute Flags", that can be used to carry + additional flags for the "P-Multicast Service Interface (PMSI) + Tunnel" attribute. This document updates RFC 6514. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7902. + + + + + + + + + + + + + + + +Rosen & Morin Standards Track [Page 1] + +RFC 7902 PMSI Tunnel Attribute Flags June 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Extending the "PMSI Tunnel" Attribute "Flags" Field . . . . . 3 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 5. Normative References . . . . . . . . . . . . . . . . . . . . 6 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + +1. Introduction + + A BGP attribute, "P-Multicast Service Interface (PMSI) Tunnel" + attribute is defined in [RFC6514]. This attribute, referred to as + the "PMSI Tunnel" attribute in this document, contains a one-octet + "Flags" field. Only one flag is defined in that RFC, but there is + now a need to define additional flags. However, that RFC did not + create an IANA registry for the assignment of bits in the "Flags" + field. This document creates a registry for that purpose. In + addition, there may be a need to define more than eight flags. + Therefore this document defines a new BGP Extended Community, + "Additional PMSI Tunnel Attribute Flags", that can be used to carry + additional flags for the "PMSI Tunnel" attribute. A registry is also + created for this Extended Community, allowing IANA to assign flag + bits from the Extended Community's six-octet value field. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + +Rosen & Morin Standards Track [Page 2] + +RFC 7902 PMSI Tunnel Attribute Flags June 2016 + + +2. Extending the "PMSI Tunnel" Attribute "Flags" Field + + In [RFC6514], only a single octet in the "PMSI Tunnel" attribute is + defined to carry bit flags. This allows eight flags, which is + unlikely to be sufficient for all future applications. + + This document defines a new Transitive Opaque Extended Community + ([RFC4360] [RFC7153]), "Additional PMSI Tunnel Attribute Flags". It + also defines a new bit flag in the "PMSI Tunnel" attribute "Flags" + field, called the "Extension" flag. + + The "Additional PMSI Tunnel Attribute Flags" Extended Community MUST + NOT be carried by a given BGP UPDATE message unless the following + conditions both hold: + + o the given BGP UPDATE message is also carrying a "PMSI Tunnel" + attribute, and + + o the "Extension" flag of that "PMSI Tunnel" attribute's "Flags" + field is set. + + The six-octet value field of the "Additional PMSI Tunnel Attribute + Flags" Extended Community is considered to be a string of 48 one-bit + flags. As shown in Figure 1, the leftmost bit (the most significant + bit of the most significant octet) is bit 0, and the rightmost bit + (the least significant bit of the least significant octet) is bit 47. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 3 4 + 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Value Field of the "Additional PMSI + Tunnel Attribute Flags" Extended Community + + A BGP speaker MUST NOT attach more than one "Additional PMSI Tunnel + Attribute Flags" Extended Community to a given BGP UPDATE. If a + given BGP UPDATE already contains an "Additional PMSI Tunnel + Attribute Flags" Extended Community, a BGP speaker MUST NOT attach + any additional such Extended Communities. + + + + +Rosen & Morin Standards Track [Page 3] + +RFC 7902 PMSI Tunnel Attribute Flags June 2016 + + + If a BGP speaker receives a BGP UPDATE with more than one "Additional + PMSI Tunnel Attribute Flags" Extended Communities attached, only the + flag settings in first occurrence of the Extended Community are + significant. Flag settings in subsequent occurrences of the Extended + Community MUST be ignored. When propagating the UPDATE, all + instances of the Extended Community other than the first SHOULD be + removed. + + Suppose a BGP speaker receives an UPDATE message that contains a + "PMSI Tunnel" attribute, but does not contain an "Additional PMSI + Tunnel Attribute Flags" Extended Community. If the "Extension" flag + of the "PMSI Tunnel" attribute is set, the UPDATE is considered to be + malformed, and the "treat-as-withdraw" procedure of [RFC7606] MUST be + applied. + + If a BGP speaker receives an UPDATE message that contains one or more + "Additional PMSI Tunnel Attribute Flags" Extended Communities, but + either (a) that UPDATE message does not contain a "PMSI Tunnel" + attribute, or (b) the "Extension" flag of the "PMSI Tunnel" attribute + is not set, then the Extended Community(ies) SHOULD be removed and + SHOULD NOT be redistributed. The BGP UPDATE message MUST be + processed (and if necessary, redistributed) as if the Extended + Community(ies) had not been present. + + A BGP speaker that supports the current document, but does not + recognize a particular flag (either in the" PMSI Tunnel" attribute + "Flags" field or in the "Additional PMSI Tunnel Attribute Flags" + Extended Community) MUST simply ignore that flag. If the BGP speaker + propagates either the "PMSI Tunnel" attribute, the "Additional PMSI + Tunnel Attribute Flags" Extended Community, or both along with the + UPDATE message, it SHOULD leave the setting of the flag unchanged. + + It is possible that a particular application will require all members + of a particular set of BGP speakers to support a particular flag. + How it is determined whether all such BGP speakers support that flag + is outside the scope of this document. + + In some situations, a BGP speaker may need to modify or replace the + "PMSI Tunnel" attribute before propagating an UPDATE. If the + "Extension" flag of the "PMSI Tunnel" attribute was set before the + attribute is modified or replaced, but that flag is no longer set + after the attribute is modified or replaced, any "Additional PMSI + Tunnel Attribute Flags" Extended Communities MUST be removed before + the UPDATE is propagated. If the "PMSI Tunnel" attribute is removed + entirely before an UPDATE is propagated, the "Additional PMSI Tunnel + Attribute Flags" Extended Communities (if any) MUST also be removed. + + + + + +Rosen & Morin Standards Track [Page 4] + +RFC 7902 PMSI Tunnel Attribute Flags June 2016 + + +3. IANA Considerations + + IANA has created a new registry called "P-Multicast Service Interface + (PMSI) Tunnel Attribute Flags" in the "Border Gateway Protocol (BGP) + Parameters" registry. + + Per Section 5 of [RFC6514], a "PMSI Tunnel" attribute contains a + "Flags" octet. The "Flags" field is a single octet, with bits + numbered, left-to-right, from 0 to 7. IANA has initialized the + registry as follows: + + Bit Position Description Reference + (left to right) + 0 unassigned + 1 Extension This document + 2 unassigned + 3 unassigned + 4 unassigned + 5 unassigned + 6 unassigned + 7 Leaf Information Required (L) RFC 6514 + + "PMSI Tunnel" Attribute Flags + + The registration procedure for this registry is Standards Action. + + IANA has also assigned the codepoint 0x07 from the "First Come, First + Served" range of the "Transitive Opaque Extended Community Sub-Types" + registry for "Additional PMSI Tunnel Attribute Flags". + + IANA has established a registry for the bit flags carried in the + "Additional PMSI Tunnel Attribute Flags" Extended Community. The + bits are numbered 0-47, with 0 being the most significant bit and 47 + being the least significant bit. The registration policy for this + registry is "Standards Action". + + The initial registry should be as follows: + + Bit Flag Name Reference + + 0-47 Unassigned + + Additional "PMSI Tunnel" Attribute Flags + + + + + + + + +Rosen & Morin Standards Track [Page 5] + +RFC 7902 PMSI Tunnel Attribute Flags June 2016 + + +4. Security Considerations + + This document establishes an IANA registry, and defines a new + Transitive Opaque Extended Community ([RFC4360], [RFC7153]). + + Establishment of an IANA registry does not raise any security + considerations. + + While this document defines a new Extended Community for carrying bit + flags, it does not define any of the bit flags in that Extended + Community. Therefore, no security considerations are raised. + + This document defines a new flag, the "Extension" flag, in the "PMSI + Tunnel" attribute. If a particular UPDATE contains a "PMSI Tunnel" + attribute with this flag set, but the UPDATE does not contain an + "Additional PMSI Tunnel Attribute Flags" Extended Community, then the + UPDATE is considered to be malformed, and the "treat-as-withdraw" + procedure of [RFC7606] is invoked. Thus, one can cause an UPDATE to + be treated as a withdrawal by incorrectly setting this bit. + +5. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended + Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, + February 2006, <http://www.rfc-editor.org/info/rfc4360>. + + [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP + Encodings and Procedures for Multicast in MPLS/BGP IP + VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, + <http://www.rfc-editor.org/info/rfc6514>. + + [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP + Extended Communities", RFC 7153, DOI 10.17487/RFC7153, + March 2014, <http://www.rfc-editor.org/info/rfc7153>. + + [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. + Patel, "Revised Error Handling for BGP UPDATE Messages", + RFC 7606, DOI 10.17487/RFC7606, August 2015, + <http://www.rfc-editor.org/info/rfc7606>. + + + + + + + +Rosen & Morin Standards Track [Page 6] + +RFC 7902 PMSI Tunnel Attribute Flags June 2016 + + +Acknowledgments + + The authors wish to thank Martin Vigoureux for his review of this + document. We also thank Christian Huitema and Alexey Melnikov for + their review and comments. + +Authors' Addresses + + Eric C. Rosen + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, Massachusetts 01886 + United States + + Email: erosen@juniper.net + + + Thomas Morin + Orange + 2, avenue Pierre-Marzin + 22307 Lannion Cedex + France + + Email: thomas.morin@orange.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosen & Morin Standards Track [Page 7] + |