idnits 2.17.1 draft-dong-idr-rtc-hierarchical-rr-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 : ---------------------------------------------------------------------------- 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 (November 25, 2014) is 3433 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 (-15) exists of draft-ietf-idr-add-paths-10 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: May 29, 2015 R. Raszuk 6 Mirantis Inc. 7 November 25, 2014 9 Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios 10 draft-dong-idr-rtc-hierarchical-rr-02 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 build 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 May 29, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Add-path Based Solution . . . . . . . . . . . . . . . . . 4 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 71 Appendix A. Another Possible Solution . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 The Route Target (RT) Constrain mechanism specified in [RFC4684] is 77 used to build a route distribution graph in order to restrict the 78 propagation of Virtual Private Network (VPN) routes. In network 79 scenarios where hierarchical route reflection (RR) is used, the 80 existing advertisment rules of RT membership information as defined 81 in section 3.2 of [RFC4684] cannot guarantee a correct route 82 distribution graph. 84 This document describes the problem scenario and proposes a solution 85 to address the RT-Constrain issue in hierarchical RR scenarios. 87 2. Problem Statement 88 +---------------------------------+ 89 | +----+ | 90 | Clu-1 |RR-1| | 91 | /+----+\ | 92 | / \ | 93 | +----+ +----+ | 94 | Clu-2 |RR-2| |RR-3| Clu-3 | 95 | +-/--+ +/--\+ | 96 | / / \ | 97 | +----+ +----+ +----+ | 98 | |PE-1| |PE-2| |PE-3| | 99 | +----+ +----+ +----+ | 100 | | | | | 101 +-------|----------|---------|----+ 102 RT-1 | RT-1 | | RT-1 103 +--------+ +--------+ +--------+ 104 | VPN-1 | | VPN-1 | | VPN-1 | 105 +--------+ +--------+ +--------+ 106 Figure 1. RT-Constrain with Hierarchical RR 108 As shown in Figure 1, hierarchical RRs are deployed in the network, 109 RR-2 and RR-3 are route-reflectors of their connecting PEs, and are 110 also the clients of RR-1. If each PE advertises RT membership 111 information of RT-1 to the upstream RR, after the best path 112 selection, both RR-2 and RR-3 would create the CLUSTER_LIST 113 attribute, prepend their local CLUSTER_ID and then advertise the best 114 path to RR-1 and their clients respectively. 116 On receipt of the RT-Constrain routes from RR-2 and RR-3, RR-1 will 117 select one of the received routes as the best route, here assume the 118 route received from RR-2 is selected by RR-1 as the best path. Then 119 RR-1 needs to advertise the best path to both RR-2 and RR-3 to create 120 the route distribution graph of VPN-1. RR-1 would prepend its 121 CLUSTER_ID to the CLUSTER_LIST of the path, and according to the 122 rules in Section 3.2 of [RFC4684], it sets the ORIGINATOR_ID to its 123 own router-id, and the NEXT_HOP to the local address for the session. 124 Then RR-1 would advertise this route to both RR-2 and RR-3. On 125 receipt of the RT-Constrain route from RR-1, RR-2 checks the 126 CLUSTER_LIST and find its own CLUSTER_ID in the list, so this route 127 will be ignored by RR-2. As a result, RR-2 will not form the 128 outbound filter of RT-1 towards RR-1, hence will not advertise VPN 129 routes with RT-1 to RR-1. 131 3. Proposed Solution 132 3.1. Add-path Based Solution 134 During the discussion in the IDR working group, the add-path based 135 solution is proposed. It makes use of the add-path mechanism as 136 defined in [I-D.ietf-idr-add-paths] for RTC route advertisement. The 137 solution is summerized as follows: 139 o The route-reflector clients which themselves are also route- 140 reflectors SHOULD be identified, then BGP add-paths 141 [I-D.ietf-idr-add-paths] SHOULD be enabled for RT membership NLRI 142 on the BGP sessions between the higher layer RR and the lower 143 layer RRs to ensure that sufficient RT-Constrain routes can be 144 advertised by the higher layer RR to the lower layer RRs to pass 145 BGP loop detection. In this case normal BGP path advertisement 146 rules as defined in [RFC4271] SHOULD be applied. The number of 147 RT-Constrain routes to be advertised is a local decision of 148 operators. 150 o When advertising an RT membership NLRI to a route-reflector client 151 which is not a lower layer RR, the advertisement rule as defined 152 in section 3.2 of [RFC4684] SHOULD be applied. 154 With the above advertisement rule, RR-1 in figure 1 SHOULD advertise 155 to RR-2 the RT-Constrain routes received from both RR-2 and RR-3, 156 then the RTC route from RR-3 will pass the BGP loop detection on RR- 157 2, thus the route distribution graph can be set up correctly. 159 4. IANA Considerations 161 This document makes no request of IANA. 163 5. Security Considerations 165 This document does not change the security properties of BGP based 166 VPNs and [RFC4684]. 168 6. Acknowledgements 170 The authors would like to thank Yaqun Xiao for the discussion about 171 RT-Constrain in hierarchical RR scenario. Many people have made 172 valuable comments and suggestions, including Susan Hares, Jeffrey 173 Haas, Stephane Litkowski, Vitkovsky Adam, Xiaohu Xu, Uttaro James, 174 Shyam Sethuram and Saikat Ray. 176 7. Normative References 178 [I-D.ietf-idr-add-paths] 179 Walton, D., Retana, A., Chen, E., and J. Scudder, 180 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 181 add-paths-10 (work in progress), October 2014. 183 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 184 Requirement Levels", BCP 14, RFC 2119, March 1997. 186 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 187 Protocol 4 (BGP-4)", RFC 4271, January 2006. 189 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 190 R., Patel, K., and J. Guichard, "Constrained Route 191 Distribution for Border Gateway Protocol/MultiProtocol 192 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 193 Private Networks (VPNs)", RFC 4684, November 2006. 195 Appendix A. Another Possible Solution 197 This section provides another possible solution which was discussed 198 among authors and IDR participants. 200 Since the advertisement of RT-Constrain route is to set up a route 201 distribution graph and not to guide the data packet forwarding, 202 actually all the available RT-Constrain routes should be considered 203 in setting up the route distribution graph, not just the best one. 204 Thus the following advertisment rule for RT membership information is 205 proposed to replace the rule i and ii in section 3.2 [RFC4684]: 207 o When advertising an RT membership NLRI to a route-reflector peer 208 (either client or non-client), if the best path as selected by the 209 path selection procedure described in Section 9.1 of [RFC4271] is 210 the path received from this peer, and there are alternative paths 211 received from other peers, then the most disjoint alternative 212 route SHOULD be advertised to this peer. The most disjoint 213 alternative path is the path whose CLUSTER_LIST and ORIGINATOR_ID 214 attributes are diverse from the attributes of the best path. 216 With the above advertisement rule, RR-1 in figure 1 would advertise 217 to RR-2 the RT-Constrain route received from RR-3, although the best 218 route is received from RR-2. Thus RR-2 will not discard the RT- 219 constrain route received from RR-1, and the route distribution graph 220 can be set up correctly. 222 Authors' Addresses 224 Jie Dong 225 Huawei Technologies 226 Huawei Campus, No. 156 Beiqing Rd. 227 Beijing 100095 228 China 230 Email: jie.dong@huawei.com 232 Mach(Guoyi) Chen 233 Huawei Technologies 234 Huawei Campus, No. 156 Beiqing Rd. 235 Beijing 100095 236 China 238 Email: mach.chen@huawei.com 240 Robert Raszuk 241 Mirantis Inc. 242 615 National Ave. #100 243 Mt View, CA 94043 244 USA 246 Email: robert@raszuk.net