idnits 2.17.1 draft-zzhang-idr-bgp-rt-constrains-extension-00.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 RFC4684, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4684, updated by this document, for RFC5378 checks: 2004-06-02) -- 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 (July 12, 2020) is 1385 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) == Missing Reference: 'I-D.ietf-idr-bgp-ipv6-rt-constrain' is mentioned on line 105, but not defined == Missing Reference: 'I-D.zzhang-idr-bitmask-route-target' is mentioned on line 97, but not defined == Unused Reference: 'I-D.ietf-idr-wide-bgp-communities' is defined on line 179, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-idr-wide-bgp-communities-05 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 idr Z. Zhang 3 Internet-Draft J. Haas 4 Updates: 4684 (if approved) Juniper Networks 5 Intended status: Standards Track July 12, 2020 6 Expires: January 13, 2021 8 Route Target Constrain Extension 9 draft-zzhang-idr-bgp-rt-constrains-extension-00 11 Abstract 13 This document specifies the extensions to Route Target Constrain 14 mechanism so that it works with various types of Route Targets of 15 arbitrary lengths. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 21 "OPTIONAL" in this document are to be interpreted as described in BCP 22 14 [RFC2119] [RFC8174] when, and only when, they appear in all 23 capitals, as shown here. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 13, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 66 6.2. Informative References . . . . . . . . . . . . . . . . . 4 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 The importation and propagation of BGP routes can be controled using 72 Route Targets [RFC4364] and Route Target Constrains [RFC4684]. 74 A Route Target (RT) could be an 8-octet BGP Extended Community (EC) 75 or a 20-octet IPv6 Address Sepcfic EC, though the RT Constrain 76 mechanism specified in [RFC4684] was designed for the 8-octet RTs 77 only. 79 [I-D.ietf-idr-bgp-ipv6-rt-constrain] extends the mechanism to handle 80 IPv6 Address Specific RTs by allowing the NLRI prefix to be of 0 to 81 24 octets (vs. 0 to 12 octets as in [RFC4684]): 83 +-------------------------------+ 84 | origin as (4 octets) | 85 +-------------------------------+ 86 | route target (8 or 20 octets)| 87 ~ ~ 88 | | 89 +-------------------------------+ 91 There is a limitation with the approach in [I-D.ietf-idr-bgp-ipv6-rt- 92 constrain] - when the prefix is not more than 12 octets, there is no 93 way to determine if the route target part is a partial IPv6 Address 94 Sepcific RT or a full/partial AS or IPv4 Address Specific RT. 96 Additional types of RTs of arbitrary lengths could also be defined, 97 e.g. [I-D.zzhang-idr-bitmask-route-target]. To extend the RT 98 Constrain mechanisms in a generic way so that any forseeable types of 99 RTs can be used, this document proposes the extensions specified in 100 the following section. 102 While the extended mechnism specified in this document can be used 103 for existing RTs including IPv6 Address Specific RTs, it is not the 104 intention of this document to replace or obsolete the mechansim 105 defined in [I-D.ietf-idr-bgp-ipv6-rt-constrain], given its current 106 status and potential existing implementations and deployments. An 107 operator may choose either way as long as there is no ambiguity. 109 2. Specification 111 To advertise Route Target Membership with various types of RTs, a new 112 NLRI encoding with a new SAFI "Extended Route Target constrains" is 113 used as following: 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Origin AS | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Path Attr Type | Route Target ~ 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 ~ Route Target (continued, variable length ) ~ 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 The one-octet "Path Attr Type" indicates the category of Route Target 126 that follows it, using the type of BGP Path Attribute for the RT. 127 For example, the "Path Attr Type" is 16 (Extended Community) for 128 regular RTs, 25 (IPv6 Address Specific Extended Community) for IPv6 129 Address Specific RTs, or 34 (BGP Community Container Attribute) for 130 any RT defined as a BGP Community Container (e.g. [I-D.zzhang-idr- 131 bitmask-route-target]). 133 Similar to [RFC4684], except for the default route target, which is 134 encoded as a zero-length prefix, the minimum prefix length is 40 bits 135 - the Origin AS field and the Path Attr Type field cannot be 136 interpreted as a prefix. Route targets MAY then be expressed as 137 prefixes, where, for instance, a prefix would encompass all regular 138 or IPv6 Address Specific RTs assigned by a given Global 139 Administrator. Semantics of adverising Route Target Membership for 140 other types of RTs as prefixes MUST be defined with the specfication 141 of those types of RTs. 143 3. Security Considerations 145 This document does not change security aspects as discussed in 146 [RFC4684]. 148 4. IANA Considerations 150 This document requests IANA to assign a new SAFI "Extended Route 151 Target constrains". 153 5. Acknowledgements 155 The authors thank John Scudder for his comments and suggestions. 157 6. References 159 6.1. Normative References 161 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 162 Requirement Levels", BCP 14, RFC 2119, 163 DOI 10.17487/RFC2119, March 1997, 164 . 166 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 167 R., Patel, K., and J. Guichard, "Constrained Route 168 Distribution for Border Gateway Protocol/MultiProtocol 169 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 170 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 171 November 2006, . 173 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 174 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 175 May 2017, . 177 6.2. Informative References 179 [I-D.ietf-idr-wide-bgp-communities] 180 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 181 and P. Jakma, "BGP Community Container Attribute", draft- 182 ietf-idr-wide-bgp-communities-05 (work in progress), July 183 2018. 185 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 186 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 187 2006, . 189 Authors' Addresses 191 Zhaohui Zhang 192 Juniper Networks 194 EMail: zzhang@juniper.net 196 Jeffrey Haas 197 Juniper Networks 199 EMail: jhaas@juniper.net