idnits 2.17.1 draft-zzhang-lsr-anycast-affiliation-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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 157: '... Reachability TLVs [RFC7794]. It MAY be advertised with an anycast...' RFC 2119 keyword, line 165: '... Prefix TLVs [RFC7684]. It MAY be advertised with an anycast host...' RFC 2119 keyword, line 171: '... Prefix TLV and Inter-Area-Prefix TLV [RFC8362]. It MAY be advertised...' RFC 2119 keyword, line 179: '...pe in case of IPv6) MAY be attached to...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 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: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lsr Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track 7 March 2022 5 Expires: 8 September 2022 7 Anycast Affiliation Advertisement 8 draft-zzhang-lsr-anycast-affiliation-00 10 Abstract 12 This document specifies the advertisement of addresses affiliated 13 with an anycast address in ISIS/OSPF/BGP, and describes one example 14 use of such advertisement in VxLAN interconnect with EVPN. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 8 September 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.1. ISIS Encoding . . . . . . . . . . . . . . . . . . . . . . 4 52 2.2. OSPF Encoding . . . . . . . . . . . . . . . . . . . . . . 4 53 2.3. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Background 64 [I-D.boutros-bess-vxlan-evpn] describes how Ethernet VPN (EVPN) 65 [RFC7432] can be used to interconnect VXLAN/NVGRE networks over an 66 MPLS/IP network. In the following diagram copied from that draft, a 67 pair of gateways PE1/PE2, which are both VXLAN/NVGRE VTEPs and EVPN 68 PEs, connect a VXLAN/NVGRE site to the EVPN Data Center Interconnect 69 (DCI). 71 +--------------+ 72 | | 73 +---------+ +----+ MPLS +----+ +---------+ 74 +-----+ | |---|PE1 | |PE3 |--| | +-----+ 75 |VTEP1|--| | +----+ +----+ | |--|VTEP3| 76 +-----+ | VXLAN | +----+ +----+ | VXLAN | +-----+ 77 +-----+ | |---|PE2 | |PE4 |--| | +-----+ 78 |VTEP2|--| | +----+Backbone+----+ | |--|VTEP4| 79 +-----+ +---------+ +--------------+ +---------+ +-----+ 81 |<--- Underlay IGP ---->|<-Overlay BGP->|<--- Underlay IGP --->| CP 83 |<----- VXLAN --------->||<------ VXLAN ------->| DP 84 |<----MPLS----->| 86 Legend: CP = Control Plane View DP = Data Plane View 88 PE1/PE2 use a common anycast address as the source address of VXLAN/ 89 NVGRE packets towards other VXLAN/NVGRE VTEPs. This serves two 90 purposes as stated in [I-D.boutros-bess-vxlan-evpn]: 92 * It prevents any flip/flopping in the forwarding tables for the 93 MAC-to-VTEP associations 95 * It enables load-balancing via ECMP for DCI traffic among the 96 multi-homed PEs 98 Notice that load-balancing is only possible with ECMP - a VTEP uses 99 the anycast address as the destination address in its VXLAN/NVGRE 100 packets towards the DCI, and ECMP-based load-balancing can happen on 101 any router from the source VTEP towards PE1/PE2. 103 However, if the source VTEP knows that PE1/PE2's specific non-anycast 104 address that are associated with the anycast address, it can load- 105 balance traffic using those specific addresses, even when there is no 106 ECMP to PE1/PE2. 108 There are two ways for a VTEP to learn the affiliation of an address 109 to an anycast address: 111 * Provisioning on the VTEPs - statically or from a controller 113 * Dynamic advertisement via IGP/BGP from the anycast address 114 "owners" (PE1/PE2) 116 This document specifies the dynamic advertisement of anycast address 117 affiliation via IGP/BGP, which can actually serve other general 118 purposes as well. 120 Even though if a node advertises anycast and non-anycast local 121 addresses using existing methods (e.g. with ISIS's N-bit) then others 122 can derive that those addresses are owned by the same advertiser, it 123 is desired to explicitly announce the non-anycast addresses 124 affiliated with an anycast address for the following reasons: 126 * Just because a node advertises two addresses A and B it does not 127 mean A and B are exchangeable when another node needs to send 128 traffic to it. Explicit association should be known for the 129 source node to choose an "alias" address to send traffic. 131 * The affiliation may have to be one-way - if a node needs to send 132 traffic to an anycast address it can use the affiliated non- 133 anycast addresses (or even a transit node may choose to change the 134 destination address from anycast to an affiliated address) but the 135 other way may not be desired (or allowed at all in the case of 136 transit node changing destination address - otherwise loops could 137 happen). 139 * A node may have different anycast addresses and it may be 140 necessary to associate different non-anycast addresses to 141 different non-anycast addresses. 143 * A node may also withdraw the affiliation advertisement even when 144 all the relevant addresses are still reachable. In that case, 145 only the affiliation is withdrawn, not the reachability. 147 For example, in the above VXLAN-EVPN interconnect scenario, if PE2 148 looses all its EVPN peers, it may withdraw anycast address 149 affiliation advertisement and then the VTEPs can stop sending traffic 150 to it. 152 2. Specifications 154 2.1. ISIS Encoding 156 A new "Anycast Affiliation sub-TLV" is defined for ISIS extended 157 Reachability TLVs [RFC7794]. It MAY be advertised with an anycast 158 host prefix. Its value part includes a list of affiliated local 159 addresses. The number of affiliated addresses is determined from the 160 length of the sub-TLV. 162 2.2. OSPF Encoding 164 A new "Anycast Affiliation sub-TLV" is defined for OSPFv2 Extended 165 Prefix TLVs [RFC7684]. It MAY be advertised with an anycast host 166 prefix. Its value part includes a list of affiliated local 167 addresses. The number of affiliated addresses is determined from the 168 length of the sub-TLV. 170 A new "Anycast Affiliation sub-TLV" is defined for OSPFv3 Intra-Area- 171 Prefix TLV and Inter-Area-Prefix TLV [RFC8362]. It MAY be advertised 172 with an anycast host prefix. Its value part includes a list of 173 affiliated local addresses. The number of affiliated addresses is 174 determined from the length of the sub-TLV. 176 2.3. BGP Encoding 178 IPv4 (or IPv6) Address Specific Extended Communities with an "Anycast 179 Affiliation" sub-type (or type in case of IPv6) MAY be attached to 180 the NLRI of an anycast host prefix, one such extended community for 181 each affiliated address. The Global Administrator field of the 182 extended community is set to the affiliated address, and the Local 183 Administrator field is set to 0. 185 3. Security Considerations 187 To be provided. 189 4. IANA Considerations 191 IANA is requested to allocate the following: 193 * A new sub-TLV type for "Anycast Affiliation" from the ISIS "Sub- 194 TLVs for TLVs 135, 235, 236, and 237" registry [RFC7794] 196 * A new sub-TLV type for "Anycast Affiliation" from the OSPFv2 197 Extended Prefix TLV Sub-TLVs" registry [RFC7684] 199 * A new sub-TLV type for "Anycast Affiliation" from the OSPFv3 200 Extended-LSA sub-TLV registry [RFC8362] 202 * A new sub-type for "Anycast Affiliation" from the Transitive IPv4- 203 Address-Specific Extended Community Sub-Types registry and Non- 204 Transitive IPv4-Address-Specific Extended Community Sub-Types 205 registry 207 * A new type for "Anycast Affiliation" from the Transitive IPv6- 208 Address-Specific Extended Community Types registry and Non- 209 Transitive IPv6-Address-Specific Extended Community Types registry 211 5. Acknowledgements 213 The author thanks Shraddha Hegde for her inputs and comments. 215 6. References 217 6.1. Normative References 219 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 220 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 221 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 222 2015, . 224 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 225 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 226 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 227 March 2016, . 229 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 230 F. Baker, "OSPFv3 Link State Advertisement (LSA) 231 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 232 2018, . 234 6.2. Informative References 236 [I-D.boutros-bess-vxlan-evpn] 237 Boutros, S., Sajassi, A., Salam, S., Cai, D., Thoria, S., 238 Singh, T., Drake, J., and J. Tantsura, "VXLAN DCI Using 239 EVPN", Work in Progress, Internet-Draft, draft-boutros- 240 bess-vxlan-evpn-02, 21 October 2016, 241 . 244 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 245 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 246 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 247 2015, . 249 Author's Address 251 Zhaohui Zhang 252 Juniper Networks 253 Email: zzhang@juniper.net