idnits 2.17.1 draft-zzhang-idr-rt-derived-community-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1160 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-bess-bgp-multicast-controller-05 == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 idr Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Informational February 22, 2021 5 Expires: August 26, 2021 7 Extended Communities Derived from Route Targets 8 draft-zzhang-idr-rt-derived-community-00 10 Abstract 12 This document describes a way to derive an Extended Community from a 13 Route Target and its use cases. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 26, 2021. 32 Copyright Notice 34 Copyright (c) 2021 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 1. Introduction 49 Consider a VPN with 10 PEs. A Route Target (say RT1) [RFC4360] is 50 configured for the VPN and all PEs will import VPN routes with RT1 51 attached. The RT is an Extended Community (say EC1), with its sub- 52 type being 0x02. While RT1 and EC1 have the same encoding, typically 53 when we mention a Route Target, its property of being able to control 54 the route propagation and importation is implied. When we just 55 mention an Extended Community, that property is not implied. 57 Now consider that another BGP route needs to be imported by some but 58 not all those PEs. The route could be of any SAFI/type (does not 59 need to be a VPN prefix), but it needs to be associated with the VPN 60 on those importing PEs. The exact meaning of "association" here does 61 not matter, but the key is that those PEs need to know that the route 62 is related to that VPN. 64 To control the propagation to and importation by those PEs, a 65 different Route Target (say RT3) is attached to the route. For those 66 PE to associate the route with the VPN, an Extended Community (say 67 EC2) is attached. Even though RT1/EC1 is already tied to the VPN, 68 EC2 needs to be different from RT1/EC1, because if EC1 was used, the 69 route would be propagated to and imported by all the 10 PEs. EC2 70 cannot be the same as RT3 either, because there could be other routes 71 to be propagated to and imported by those same set of PEs yet those 72 other routes are not related to the VPN. 74 While EC2 can be any Extended Community (that is not a RT) configured 75 on the originating and receiving PEs to map it to the VPN, it is 76 convenient if EC2 is derived from the RT1/EC1, e.g. the sub-type of 77 RT1/EC1 is changed to a new known value while everything else remains 78 the same. We call this a Route Target derived Extended Community, or 79 RT-derived EC. A new sub-type is assigned specifically for this 80 purpose (see IANA considerations). 82 This document is for information only. Any protol/feature that can 83 take advantages of the convenience of generic RT-derived ECs may use 84 them, or not use them at its own discretion. 86 2. Use Cases 88 The following are a few examples of use cases. To reiterate, these 89 are example scenarios where generic RT-derived ECs could be used 90 (when the routes to which they are attached provide enough context). 91 It is not the intention of this document to mandate that it must be 92 used. 94 2.1. EVPN EVI-RT Extended Community 96 Section 9.5 "EVI-RT Extended Community" of 97 [I-D.ietf-bess-evpn-igmp-mld-proxy] describes a situation similar to 98 the above. As a solution, four EVPN specific EVI-RT ECs are defined, 99 each mapping to a type of Route Target for the corresponding EVPN 100 instance. 102 As a theoretical alternative, a RT-derived EC described in this 103 document could be used instead - just derive a generic EC from the 104 EVI RT. Note that this document does not attempt to change the 105 existing procedures in [I-D.ietf-bess-evpn-igmp-mld-proxy], but 106 merely use it for illustration purposes. 108 2.2. Leaf Discovery with Controller Signaled BGP-MVPN 110 In Section 2 "Alternative to BGP-MVPN" of 111 [I-D.ietf-bess-bgp-multicast-controller], BGP MCAST-TREE SAFI 112 signaling can be used for a controller to program multicast 113 forwarding state in VRFs of ingress/egress PEs, instead of relying on 114 distributed BGP-MVPN signaling. For the controller to learn egress 115 PEs of a VPN customer multicast tree (so that it can build/find a 116 corresponding provider tunnel), egress PEs signal leaf information to 117 the controller via Leaf Auto-Discovery routes. The routes carry a 118 Route Target for the controller (so that only the controller receives 119 them), and an EC derived from the VPN's Route Target (so that the 120 controller knows which VPN they are for). 122 3. Security Considerations 124 To be provided. 126 4. IANA Considerations 128 This document requests IANA to assign a new sub-type "RT-derived-EC" 129 from the following registries: 131 o Transitive Two-Octet AS-Specific Extended Community Sub-Types 133 o Transitive Four-Octet AS-Specific Extended Community Sub-Types 135 o Transitive IPv4-Address-Specific Extended Community Sub-Types 137 o Transitive IPv6-Address-Specific Extended Community Sub-Types 139 o Non-Transitive Opaque Extended Community Sub-Types 141 o EVPN Extended Community Sub-Types 142 The same value is preferred across these registries. 144 If and when additional Extended Community types are defined with a 145 Route Target sub-type, the "RT-derived-EC" sub-type may also be 146 registered for those types, preferably with the same value. With 147 that consideration, it is preferred that the sub-type value is 148 assigned from the higher end of the "first come first serve" area, to 149 increase the probability of assigning the same value for future types 150 of Extended Communities with Route Target sub-type. 152 5. Acknowledgements 154 The authors thank Jeff Haas for his valuable comments and 155 suggestions. 157 6. References 159 6.1. Normative References 161 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 162 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 163 February 2006, . 165 6.2. Informative References 167 [I-D.ietf-bess-bgp-multicast-controller] 168 Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko, 169 "Controller Based BGP Multicast Signaling", draft-ietf- 170 bess-bgp-multicast-controller-05 (work in progress), 171 September 2020. 173 [I-D.ietf-bess-evpn-igmp-mld-proxy] 174 Sajassi, A., Thoria, S., Drake, J., and W. Lin, "IGMP and 175 MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-mld- 176 proxy-06 (work in progress), January 2021. 178 Author's Address 180 Zhaohui Zhang 181 Juniper Networks 183 Email: zzhang@juniper.net