idnits 2.17.00 (12 Aug 2021) /tmp/idnits12091/draft-sun-bess-vpn-orf-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 1300 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: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Chunxia Sun 2 Intended status: Proposed Standard Yaokun Zhang 3 Donald Eastlake 3rd 4 Huawei 5 Expires: April 21, 2019 October 22, 2018 7 Controlling VPN Routes More Precisely by ORF Extension 8 draft-sun-bess-vpn-orf-extension-00 10 Abstract 12 RFC 4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow 13 BGP speakers to exchange Route Target reachability information which 14 can be used to build a route distribution graph in order to limit the 15 propagation of Virtual Private Network (VPN) Network Layer 16 Reachability Information (NLRI) between different autonomous systems 17 or distinct clusters of the same autonomous system. 19 However, according to RFC 4684, in some scenarios, more routes will 20 be sent than need to be sent. 22 This document extends RFC 4684. This extension allows a BGP speaker 23 to advertise VPN routes more precisely. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Distribution of this document is unlimited. Comments should be sent 31 to the authors or the BESS working group mailing list: bess@ietf.org. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 45 Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Internet-Draft VPN ORF Extension 50 Table of Contents 52 1. Introduction............................................3 53 1.1 Requirements Language..................................3 54 1.2 Terminology............................................3 56 2. Solution................................................5 57 3. BGP Encoding............................................6 59 4. Security Considerations.................................7 60 5. IANA Considerations.....................................7 62 Normative References.......................................8 63 Informative References.....................................8 65 Acknowledgments............................................8 66 Authors' Addresses.........................................9 68 Internet-Draft VPN ORF Extension 70 1. Introduction 72 [RFC4684] defines Multi-Protocol BGP (MP-BGP) procedures that allow 73 BGP speakers to exchange Route Target reachability information which 74 can be used to build a route distribution graph in order to limit the 75 propagation of Virtual Private Network (VPN) Network Layer 76 Reachability Information (NLRI) between different autonomous systems 77 or distinct clusters of the same autonomous system. 79 However, according to the extension of BGP protocol by [RFC4684], in 80 some scenarios, for example, when the same route targets exist in 81 different BGP address families, more routes will be sent than need to 82 be sent, which violates the original intention of the ORF 83 implementation. 85 This document extends [RFC4684]. This extension allows a BGP speaker 86 to advertise VPN routes more precisely when BGP speaker has the same 87 route target in different address families. 89 1.1 Requirements Language 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 1.2 Terminology 99 AFI: Address Family Identifier(a BGP address type) 101 SAFI: Subsequence Address Family Identifier (a BGP address sub-type) 103 BGP: Border Gateway Protocol 105 VPN: Virtual Private Network 107 PE: Provider Edge device 109 CE: Customer Edge(router) 111 EVPN: Ethernet Virtual Private Network 113 L3VPN: Layer 3 Virtual Private Network 115 Internet-Draft VPN ORF Extension 117 iBGP: Internal BGP (i.e., a BGP peering session that connects two 118 routers within an autonomous system) 120 MP-BGP: MultiProtocol-Border Gateway Protocol 122 MPLS: MultiProtocol Label Switching 124 NLRI: Network Layer Reachability Information 126 ORF: Outbound Route Filtering 128 RT: Route Target 130 Internet-Draft VPN ORF Extension 132 2. Solution 134 In the Section 4 of [RFC4684], the packet structure of the ORF route 135 is defined. The ORF route prefix carries only the original AS and 136 route-target information, and does not carry the address family 137 information corresponding to the route-target. 139 Let us give an example of the problem of route advertisement in 140 [RFC4684]. For example, RTA and RTB are neighbors in EVPN and 141 neighbors in L3VPN. The route-target of the EVPN instance on RTA is 142 100:1, the route- target of the L3VPN instance on RTA is 200:1, and 143 the route-target of the EVPN instance on RTB is 100:1, the route- 144 target of the L3VPN instance on RTB is 100:1. The ORF capability is 145 enabled on both RTA and RTB. After the neighbor relationship between 146 RTA and RTB is established, RTA sends ORF routes to inform RTB routes 147 with a route- target of 100:1 and 200:1 are required. After receiving 148 the ORF routes of RTA, RTB sends the routes with the route-target of 149 100:1 to RTA, including the EVPN routes with the route-target of 150 100:1 and L3VPN routes with route-target of 100:1. In fact, RTA is 151 not required for L3VPN routes with route-target of 100:1. 153 In order to solve the problem above, [RFC4684] is extended, the RT- 154 ORF-DOMAIN attribute is added to the ORF routes, and the address 155 families corresponding to the route target is carried in the 156 attribute, for example: EVPN, VPNv4, etc.; 158 In the above example, the ORF routes sent by RTA to RTB carry the 159 information that RTA wants to receive the routes of EVPN address 160 family with the route target of 100:1 and the routes of VPNv4 address 161 family with the route target of 200:1. After receiving the ORF routes 162 from RTA, RTB will only send the routes of the EVPN address family 163 with the route target of 100:1 to RTA. 165 Internet-Draft VPN ORF Extension 167 3. BGP Encoding 169 [RFC4684] defines the packet structure of the ORF route, including 170 the route prefix and attributes. This document extends [RFC4684] and 171 adds the RT-ORF-DOMAIN attribute to the ORF route. This attribute is 172 composed as follows: 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Attr. Flags |Attr. Type Code| 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | AFI | SAFI | 181 | AFI | SAFI | 182 | ...... | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 RT-ORF-DOMAIN is an optional transitive attribute, and the attribute 186 type is to be assigned. The role of this attribute has been described 187 in Section 2. 189 Internet-Draft VPN ORF Extension 191 4. Security Considerations 193 TBD 195 5. IANA Considerations 197 TBD 199 Internet-Draft VPN ORF Extension 201 Normative References 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, DOI 205 10.17487/RFC2119, March 1997, . 208 [RFC4684] R. Bonica, " Constrained Route Distribution for Border 209 Gateway Protocol/MultiProtocol Label Switching 210 (BGP/MPLS)Internet Protocol (IP) Virtual Private Networks 211 (VPNs) ", RFC 4684, November 2006. 213 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 214 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 215 2017, . 217 Informative References 219 TBD 221 Acknowledgments 223 The authors would like to thank the following for their valuable 224 contributions of this document: 226 TBD 228 Internet-Draft VPN ORF Extension 230 Authors' Addresses 232 Chunxia Sun 233 Huawei Technologies 234 Huawei Bld., No.156 Beiqing Rd. 235 Beijing 100095 236 China 238 Email: sunchunxia@huawei.com 240 Yaokun Zhang 241 Huawei Technologies 242 Huawei Bld., No.156 Beiqing Rd. 243 Beijing 100095 244 China 246 Email: zhangyaokun@huawei.com 248 Donald Eastlake 3rd 249 Huawei Technologies 250 1424 Pro Shop Court 251 Davenport, FL 33896 252 USA 254 Phone: +1-508-333-2270 255 Email: Donald.Eastlake@huawei.com 257 Internet-Draft VPN ORF Extension 259 Copyright, Disclaimer, and Additional IPR Provisions 261 Copyright (c) 2018 IETF Trust and the persons identified as the 262 document authors. All rights reserved. 264 This document is subject to BCP 78 and the IETF Trust's Legal 265 Provisions Relating to IETF Documents 266 (http://trustee.ietf.org/license-info) in effect on the date of 267 publication of this document. Please review these documents 268 carefully, as they describe your rights and restrictions with respect 269 to this document. Code Components extracted from this document must 270 include Simplified BSD License text as described in Section 4.e of 271 the Trust Legal Provisions and are provided without warranty as 272 described in the Simplified BSD License.