idnits 2.17.1 draft-dong-idr-rtc-hierarchical-rr-01.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 an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3470 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: 1 error (**), 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: April 30, 2015 R. Raszuk 6 Mirantis Inc. 7 October 27, 2014 9 Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios 10 draft-dong-idr-rtc-hierarchical-rr-01 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 provides candidate solutions to 20 address RT-Constrain issue in hierarchical RR scenarios. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 30, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Proposed Candidate Solutions . . . . . . . . . . . . . . . . 3 64 2.1. Candidate Solution 1 . . . . . . . . . . . . . . . . . . 4 65 2.2. Candidate Solution 2 . . . . . . . . . . . . . . . . . . 4 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Problem Statement 74 The Route Target (RT) Constrain mechanism specified in [RFC4684] is 75 used to build a route distribution graph in order to restrict the 76 propagation of Virtual Private Network (VPN) routes. In network 77 scenarios where hierarchical route reflection (RR) is used, the 78 existing advertisment rules of RT membership information as defined 79 in section 3.2 of [RFC4684] cannot guarantee a correct route 80 distribution graph. 82 +---------------------------------+ 83 | +----+ | 84 | Clu-1 |RR-1| | 85 | /+----+\ | 86 | / \ | 87 | +----+ +----+ | 88 | Clu-2 |RR-2| |RR-3| Clu-3 | 89 | +-/--+ +/--\+ | 90 | / / \ | 91 | +----+ +----+ +----+ | 92 | |PE-1| |PE-2| |PE-3| | 93 | +----+ +----+ +----+ | 94 | | | | | 95 +-------|----------|---------|----+ 96 RT-1 | RT-1 | | RT-1 97 +--------+ +--------+ +--------+ 98 | VPN-1 | | VPN-1 | | VPN-1 | 99 +--------+ +--------+ +--------+ 100 Figure 1. RT-Constrain with Hierarchical RR 102 As shown in Figure 1, hierarchical RRs are deployed in the network, 103 RR-2 and RR-3 are route-reflectors of their connecting PEs, and are 104 also the clients of RR-1. If each PE advertises RT membership 105 information of RT-1 to the upstream RR, after the best path 106 selection, both RR-2 and RR-3 would create the CLUSTER_LIST 107 attribute, prepend their local CLUSTER_ID and then advertise the best 108 path to RR-1 and their clients respectively. 110 On receipt of the RT-Constrain routes from RR-2 and RR-3, RR-1 will 111 select one of the received routes as the best route, here assume the 112 route received from RR-2 is selected by RR-1 as the best path. Then 113 RR-1 needs to advertise the best path to both RR-2 and RR-3 to create 114 the route distribution graph of VPN-1. RR-1 would prepend its 115 CLUSTER_ID to the CLUSTER_LIST of the path, and according to the 116 rules in Section 3.2 of [RFC4684], it sets the ORIGINATOR_ID to its 117 own router-id, and the NEXT_HOP to the local address for the session. 118 Then RR-1 would advertise this route to both RR-2 and RR-3. On 119 receipt of the RT-Constrain route from RR-1, RR-2 checks the 120 CLUSTER_LIST and find its own CLUSTER_ID in the list, so this route 121 will be ignored by RR-2. As a result, RR-2 will not form the 122 outbound filter of RT-1 towards RR-1, hence will not advertise VPN 123 routes with RT-1 to RR-1. 125 2. Proposed Candidate Solutions 126 2.1. Candidate Solution 1 128 The problem described in the above section is that the best RT- 129 Constrain route is sent back to the BGP speaker which advertised the 130 route, and get discarded due to the BGP loop detection mechanisms. 131 Since the advertisement of RT-Constrain route is to set up a route 132 distribution graph and not to guide the data packet forwarding, 133 actually all the available RT-Constrain routes should be considered 134 in setting up the route distribution graph, not just the best one. 135 Thus the following advertisment rule for RT membership information is 136 proposed to replace the rule i and ii in section 3.2 [RFC4684]: 138 o When advertising an RT membership NLRI to a route-reflector peer 139 (either client or non-client), if the best path as selected by the 140 path selection procedure described in Section 9.1 of [RFC4271] is 141 the path received from this peer, and there are alternative paths 142 received from other peers, then the most disjoint alternative 143 route SHOULD be advertised to this peer. The most disjoint 144 alternative path is the path whose CLUSTER_LIST and ORIGINATOR_ID 145 attributes are diverse from the attributes of the best path. 147 With the above advertisement rule, RR-1 in figure 1 would advertise 148 to RR-2 the RT-Constrain route received from RR-3, although the best 149 route is received from RR-2. Thus RR-2 will not discard the RT- 150 constrain route received from RR-1, and the route distribution graph 151 can be set up correctly. 153 2.2. Candidate Solution 2 155 During the discussion in the IDR working group, another candidate 156 solution is proposed. It is based on the use of BGP add-paths as 157 defined in [I-D.ietf-idr-add-paths]. The solution is summerized as 158 follows: 160 o The route-reflector clients which themselves are also route- 161 reflectors SHOULD be identified, then BGP add-paths 162 [I-D.ietf-idr-add-paths] SHOULD be enabled for RT membership NLRI 163 on the BGP sessions between the higher layer RR and the lower 164 layer RRs to ensure that sufficient RT-Constrain routes can be 165 advertised by the higher layer RR to the lower layer RRs to pass 166 BGP loop detection. In this case normal BGP path advertisement 167 rules as defined in [RFC4271] SHOULD be applied. The number of 168 RT-Constrain routes to be advertised is a local decision of 169 operators. 171 o When advertising an RT membership NLRI to a route-reflector client 172 which is not a lower layer RR, the advertisement rule as defined 173 in section 3.2 of [RFC4684] SHOULD be applied. 175 With the above advertisement rule, RR-1 in figure 1 SHOULD advertise 176 to RR-2 the RT-Constrain routes received from both RR-2 and RR-3, 177 then the route from RR-3 will pass the BGP loop detection on RR-2, 178 thus the route distribution graph can be set up correctly. 180 3. IANA Considerations 182 This document makes no request of IANA. 184 4. Security Considerations 186 This document does not change the security properties of BGP based 187 VPNs and [RFC4684]. 189 5. Acknowledgements 191 The authors would like to thank Yaqun Xiao for the discussion about 192 RT-Constrain in hierarchical RR scenario. Many people have made 193 valuable comments and suggestions, including Susan Hares, Jeffrey 194 Haas, Stephane Litkowski, Vitkovsky Adam, Xiaohu Xu, Uttaro James and 195 Shyam Sethuram. 197 6. Normative References 199 [I-D.ietf-idr-add-paths] 200 Walton, D., Retana, A., Chen, E., and J. Scudder, 201 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 202 add-paths-10 (work in progress), October 2014. 204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 205 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 208 Protocol 4 (BGP-4)", RFC 4271, January 2006. 210 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 211 R., Patel, K., and J. Guichard, "Constrained Route 212 Distribution for Border Gateway Protocol/MultiProtocol 213 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 214 Private Networks (VPNs)", RFC 4684, November 2006. 216 Authors' Addresses 217 Jie Dong 218 Huawei Technologies 219 Huawei Campus, No. 156 Beiqing Rd. 220 Beijing 100095 221 China 223 Email: jie.dong@huawei.com 225 Mach(Guoyi) Chen 226 Huawei Technologies 227 Huawei Campus, No. 156 Beiqing Rd. 228 Beijing 100095 229 China 231 Email: mach.chen@huawei.com 233 Robert Raszuk 234 Mirantis Inc. 235 615 National Ave. #100 236 Mt View, CA 94043 237 USA 239 Email: robert@raszuk.net