idnits 2.17.1 draft-ietf-idr-rtc-hierarchical-rr-03.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 (July 3, 2017) is 2489 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dong 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 4, 2018 R. Raszuk 6 Bloomberg LP 7 July 3, 2017 9 Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios 10 draft-ietf-idr-rtc-hierarchical-rr-03 12 Abstract 14 The Route Target (RT) Constrain mechanism specified in RFC 4684 is 15 used to build a route distribution graph in order to restrict the 16 propagation of Virtual Private Network (VPN) routes. In network 17 scenarios where hierarchical route reflection (RR) is used, the 18 existing RT-Constrain mechanism cannot guarantee a correct route 19 distribution graph. This document describes the problem scenario and 20 proposes a solution to address the RT-Constrain issue in hierarchical 21 RR scenarios. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 4, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 65 3. Potential Solutions . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Add-path Based Solution . . . . . . . . . . . . . . . . . 4 67 3.2. Disjoint Alternate Path Solution . . . . . . . . . . . . 4 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 7.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 The Route Target (RT) Constrain mechanism specified in [RFC4684] is 79 used to build a route distribution graph in order to restrict the 80 propagation of Virtual Private Network (VPN) routes. In network 81 scenarios where hierarchical route reflection (RR) is used, the 82 existing advertisment rules of RT membership information as defined 83 in section 3.2 of [RFC4684] cannot guarantee a correct route 84 distribution graph. 86 This document describes the problem scenario and proposes a solution 87 to address the RT-Constrain issue in hierarchical RR scenarios. 89 2. Problem Statement 90 +---------------------------------+ 91 | +----+ | 92 | Clu-1 |RR-1| | 93 | /+----+\ | 94 | / \ | 95 | +----+ +----+ | 96 | Clu-2 |RR-2| |RR-3| Clu-3 | 97 | +-/--+ +/--\+ | 98 | / / \ | 99 | +----+ +----+ +----+ | 100 | |PE-1| |PE-2| |PE-3| | 101 | +----+ +----+ +----+ | 102 | | | | | 103 +-------|----------|---------|----+ 104 RT-1 | RT-1 | | RT-1 105 +--------+ +--------+ +--------+ 106 | VPN-1 | | VPN-1 | | VPN-1 | 107 +--------+ +--------+ +--------+ 108 Figure 1. RT-Constrain with Hierarchical RR 110 As shown in Figure 1, hierarchical RRs are deployed in the network, 111 RR-2 and RR-3 are route-reflectors of their connecting PEs, and are 112 also the clients of RR-1. If each PE advertises RT membership 113 information of RT-1 to the upstream RR, after the best path 114 selection, both RR-2 and RR-3 would create the CLUSTER_LIST 115 attribute, prepend their local CLUSTER_ID and then advertise the best 116 path to RR-1 and their clients respectively. 118 On receipt of the RT-Constrain routes from RR-2 and RR-3, RR-1 will 119 select one of the received routes as the best route, here assume the 120 route received from RR-2 is selected by RR-1 as the best route. Then 121 RR-1 needs to advertise the best RT-Constrain route to both RR-2 and 122 RR-3 to create the route distribution graph of VPN-1. RR-1 would 123 prepend its CLUSTER_ID to the CLUSTER_LIST of the path, and according 124 to the rules in Section 3.2 of [RFC4684], it sets the ORIGINATOR_ID 125 to its own router-id, and the NEXT_HOP to the local address for the 126 session. Then RR-1 would advertise this route to both RR-2 and RR-3. 127 On receipt of the RT-Constrain route from RR-1, RR-2 checks the 128 CLUSTER_LIST and find its own CLUSTER_ID in the list, so this route 129 will be ignored by RR-2. As a result, RR-2 will not form the 130 outbound filter of RT-1 towards RR-1, hence it will not advertise the 131 VPN routes of VPN-1 to RR-1. 133 3. Potential Solutions 135 This document specifies 2 potential solutions for the RTC issue in 136 hierarchical RR scenario. In a later revision, one solution will to 137 be selected based on the decision of the IDR working group. 139 3.1. Add-path Based Solution 141 This section provides one possible solution which is based on the 142 add-path mechanism defined in [RFC7911]. It makes use of the add- 143 path mechanism for RTC route advertisement between the hierarchical 144 RRs. The solution is summerized as follows: 146 o The route-reflector clients which themselves are also route- 147 reflectors SHOULD be identified, then BGP add-paths [RFC7911] 148 SHOULD be enabled for RT membership NLRI on the BGP sessions 149 between the higher layer RR and the lower layer RRs to ensure that 150 sufficient RT-Constrain routes can be advertised by the higher 151 layer RR to the lower layer RRs to pass BGP loop detection. In 152 this case normal BGP path advertisement rules as defined in 153 [RFC4271] SHOULD be applied. The number of RT-Constrain routes to 154 be advertised with add-path mechanism is a local decision of 155 operators. To ensure that sufficient RT-Constrain routes are 156 advertised to build the distribution graph, the recommended add- 157 path number is the maximum number of the BGP client sessions in 158 the same cluster plus 1. 160 o When advertising an RT membership NLRI to a route-reflector client 161 which is not a lower layer RR, the advertisement rule as defined 162 in section 3.2 of [RFC4684] SHOULD be applied. 164 With the above advertisement rule, RR-1 in figure 1 SHOULD advertise 165 to RR-2 the RT-Constrain routes received from both RR-2 and RR-3, 166 then the RTC route from RR-3 will pass the BGP loop detection on RR- 167 2, thus the route distribution graph can be set up correctly. 169 3.2. Disjoint Alternate Path Solution 171 This section specifies another possible solution which proposes some 172 modification to the intra-AS advertisement rule of RTC route. 174 Since the advertisement of RT-Constrain route is to set up a route 175 distribution graph and not to guide the data packet forwarding, 176 actually all the available RT-Constrain routes should be considered 177 in setting up the route distribution graph, not just the best one. 178 Thus the following advertisment rule for RT membership information is 179 proposed to replace the rule i and ii in section 3.2 of [RFC4684]: 181 o When advertising an RT membership NLRI to a route-reflector peer 182 (either client or non-client), if the best path as selected by the 183 path selection procedure described in Section 9.1 of [RFC4271] is 184 the path received from this peer, and there are alternative paths 185 received from other peers, then the most disjoint alternative 186 route SHOULD be advertised to this peer. The most disjoint 187 alternative path is the path whose CLUSTER_LIST and ORIGINATOR_ID 188 attributes are diverse from the attributes of the best path. 190 With the above advertisement rule, RR-1 in figure 1 would advertise 191 to RR-2 the RT-Constrain route received from RR-3, which is the most 192 disjoint alternative route compared with the best route received from 193 RR-2. In this way, RR-2 will not discard the RT-constrain route 194 received from RR-1, and the route distribution graph can be set up 195 correctly. 197 4. IANA Considerations 199 This document makes no request of IANA. 201 5. Security Considerations 203 This document does not change the security properties of BGP based 204 VPNs and [RFC4684]. 206 6. Acknowledgements 208 The authors would like to thank Yaqun Xiao for the discussion of RT- 209 Constrain issue in hierarchical RR scenario. Many people have made 210 valuable comments and suggestions, including Susan Hares, Jeffrey 211 Haas, Stephane Litkowski, Vitkovsky Adam, Xiaohu Xu, Uttaro James, 212 Shyam Sethuram, Saikat Ray and Bruno Decraene. 214 7. References 216 7.1. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, 220 DOI 10.17487/RFC2119, March 1997, 221 . 223 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 224 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 225 DOI 10.17487/RFC4271, January 2006, 226 . 228 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 229 R., Patel, K., and J. Guichard, "Constrained Route 230 Distribution for Border Gateway Protocol/MultiProtocol 231 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 232 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 233 November 2006, . 235 7.2. Informative References 237 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 238 "Advertisement of Multiple Paths in BGP", RFC 7911, 239 DOI 10.17487/RFC7911, July 2016, 240 . 242 Authors' Addresses 244 Jie Dong 245 Huawei Technologies 246 Huawei Campus, No. 156 Beiqing Rd. 247 Beijing 100095 248 China 250 Email: jie.dong@huawei.com 252 Mach(Guoyi) Chen 253 Huawei Technologies 254 Huawei Campus, No. 156 Beiqing Rd. 255 Beijing 100095 256 China 258 Email: mach.chen@huawei.com 260 Robert Raszuk 261 Bloomberg LP 262 731 Lexington Ave 263 New York City, NY 10022 264 USA 266 Email: robert@raszuk.net