idnits 2.17.00 (12 Aug 2021) /tmp/idnits50944/draft-zzhang-idr-rt-derived-community-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (4 March 2022) is 71 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) == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-19 == Outdated reference: A later version (-09) exists of draft-ietf-bess-bgp-multicast-controller-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 idr Z. Zhang 3 Internet-Draft J. Haas 4 Intended status: Standards Track Juniper Networks 5 Expires: 5 September 2022 K. Patel 6 Arrcus 7 4 March 2022 9 Extended Communities Derived from Route Targets 10 draft-zzhang-idr-rt-derived-community-02 12 Abstract 14 This document specifies a way to derive an Extended Community from a 15 Route Target and describes some example use cases. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 5 September 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. EVPN EVI-RT Extended Community . . . . . . . . . . . . . 3 53 2.2. Leaf Discovery with Controller Signaled BGP-MVPN . . . . 3 54 2.3. Translated Route-target Extended Communities in 55 [I-D.ietf-idr-legacy-rtc] . . . . . . . . . . . . . . . . 4 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 4. IANA Assignments . . . . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 5.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 Consider a VPN with 10 PEs. A Route Target (say RT1) [RFC4360] is 66 configured for the VPN and all PEs will import VPN routes with RT1 67 attached. The RT is an Extended Community (say EC1), with its sub- 68 type being 0x02. While RT1 and EC1 have the same encoding, typically 69 when we mention a Route Target, its property of being able to control 70 the route propagation and importation is implied. When we just 71 mention an Extended Community, that property is not implied. 73 Now consider that another BGP route needs to be imported by some but 74 not all those PEs. The route could be of any SAFI/type (does not 75 need to be a VPN prefix), but it needs to be associated with the VPN 76 on those importing PEs. The exact meaning of "association" here does 77 not matter, but the key is that those PEs need to know that the route 78 is related to that VPN. 80 To control the propagation to and importation by those PEs, a 81 different Route Target (say RT3) is attached to the route. For those 82 PE to associate the route with the VPN, an Extended Community (say 83 EC2) is attached. Even though RT1/EC1 is already associated with the 84 VPN, EC2 needs to be different from RT1/EC1, because if EC1 was used, 85 the route would be propagated to and imported by all the 10 PEs. EC2 86 cannot be the same as RT3 either, because there could be other routes 87 to be propagated to and imported by those same set of PEs yet those 88 other routes are not related to the VPN. 90 While EC2 can be any Extended Community (that is not a RT) configured 91 on the originating and receiving PEs to map it to the VPN, it is 92 convenient if EC2 is derived from the RT1/EC1, e.g. the sub-type of 93 RT1/EC1 is changed to a new known value while everything else remains 94 the same. We call this a Route Target derived Extended Community, or 95 RT-derived EC. A new sub-type is assigned specifically for this 96 purpose (see IANA considerations). 98 This document only specifies a way to derive an Extended Community 99 from a Route Target Extended Community using IANA-assigned Extended 100 Community sub-types (or Extended Community Type in case of IPv6- 101 Address-Specific Extended Community). Any protocol/feature that can 102 take advantages of the convenience of generic derivation may use 103 them, or not use them at its own discretion, and how they are used is 104 outside the scope of this document. 106 2. Use Cases 108 The following are a few examples of use cases. To reiterate, these 109 are example scenarios where generic RT-derived ECs could be used 110 (when the routes to which they are attached provide enough context). 111 It is not the intention of this document to mandate that it must be 112 used. 114 2.1. EVPN EVI-RT Extended Community 116 Section 9.5 "EVI-RT Extended Community" of 117 [I-D.ietf-bess-evpn-igmp-mld-proxy] describes a situation similar to 118 the above. As a solution, four EVPN specific EVI-RT ECs are defined, 119 each mapping to a type of Route Target for the corresponding EVPN 120 instance. 122 As a theoretical alternative, a RT-derived EC described in this 123 document could be used instead - just derive a generic EC from the 124 EVI RT. Note that this document does not attempt to change the 125 existing procedures in [I-D.ietf-bess-evpn-igmp-mld-proxy], but 126 merely use it for illustration purposes. 128 2.2. Leaf Discovery with Controller Signaled BGP-MVPN 130 In Section 2 "Alternative to BGP-MVPN" of 131 [I-D.ietf-bess-bgp-multicast-controller], BGP MCAST-TREE SAFI 132 signaling can be used for a controller to program multicast 133 forwarding state in VRFs of ingress/egress PEs, instead of relying on 134 distributed BGP-MVPN signaling. For the controller to learn egress 135 PEs of a VPN customer multicast tree (so that it can build/find a 136 corresponding provider tunnel), egress PEs signal leaf information to 137 the controller via Leaf Auto-Discovery routes. The routes carry a 138 Route Target for the controller (so that only the controller receives 139 them), and an EC derived from the VPN's Route Target (so that the 140 controller knows which VPN they are for). 142 2.3. Translated Route-target Extended Communities in [I-D.ietf-idr- 143 legacy-rtc] 145 In Section 3.1 of [I-D.ietf-idr-legacy-rtc], a similar mechanism is 146 described, as quoted below: 148 "The translation of the IRTs is necessary in order to refrain from 149 importing "route-filter" VRF routes into VPN VRFs that would 150 import the same route-targets. The translation of the IRTS is 151 done as follows. For a given IRT, the equivalent translated RT 152 (TRT) is constructed by means of swapping the value of the high- 153 order octet of the Type field for the IRT (as defined in 154 [RFC4360])." 156 3. Security Considerations 158 This document specifies a way to derive an Extended Community from a 159 Route Target Extended Community and does not specify how derived 160 Extended Communities are used. As a result, this document does not 161 need security considerations. Any potential security concerns need 162 be addressed by documents that specify the actual usage. 164 4. IANA Assignments 166 IANA has assign a new sub-type "RT-derived-EC" with value 0x15 in the 167 following registries: 169 * Transitive Two-Octet AS-Specific Extended Community Sub-Types 171 * Transitive Four-Octet AS-Specific Extended Community Sub-Types 173 * Transitive IPv4-Address-Specific Extended Community Sub-Types 175 * Non-Transitive Opaque Extended Community Sub-Types 177 * EVPN Extended Community Sub-Types 179 IANA has also assigned a new type "RT-derived-EC" with value 0x0015 180 in the following registry: 182 * Transitive IPv6-Address-Specific Extended Community Types 183 If and when additional Extended Community types are defined with a 184 Route Target sub-type, the "RT-derived-EC" sub-type may also be 185 registered for those new types, preferably with the same value. 187 5. References 189 5.1. Normative References 191 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 192 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 193 February 2006, . 195 5.2. Informative References 197 [I-D.ietf-bess-evpn-igmp-mld-proxy] 198 Sajassi, A., Thoria, S., Mishra, M., Drake, J., and W. 199 Lin, "IGMP and MLD Proxy for EVPN", Work in Progress, 200 Internet-Draft, draft-ietf-bess-evpn-igmp-mld-proxy-19, 4 201 March 2022, . 204 [I-D.ietf-bess-bgp-multicast-controller] 205 Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko, 206 "Controller Based BGP Multicast Signaling", Work in 207 Progress, Internet-Draft, draft-ietf-bess-bgp-multicast- 208 controller-07, 12 July 2021, 209 . 212 [I-D.ietf-idr-legacy-rtc] 213 Mohapatra, P., Sreekantiah, A., Patel, K., Pithawala, B., 214 and A. Lo, "Automatic Route Target Filtering for legacy 215 PEs", Work in Progress, Internet-Draft, draft-ietf-idr- 216 legacy-rtc-08, 12 September 2017, 217 . 220 Authors' Addresses 222 Zhaohui Zhang 223 Juniper Networks 224 Email: zzhang@juniper.net 226 Jeff Haas 227 Juniper Networks 228 Email: jhaas@juniper.net 229 Keyur Patel 230 Arrcus 231 Email: keyur@arrcus.com