idnits 2.17.1 draft-dong-idr-rtc-hierarchical-rr-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 date (June 19, 2014) is 3592 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: December 21, 2014 June 19, 2014 7 Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios 8 draft-dong-idr-rtc-hierarchical-rr-00 10 Abstract 12 The Route Target (RT) Constrain mechanism specified in RFC 4684 is 13 used to build a route distribution graph in order to restrict the 14 propagation of Virtual Private Network (VPN) routes. In network 15 scenarios where hierarchical route reflection (RR) is used, the 16 existing RT-Constrain mechanism cannot build a correct route 17 distribution graph. This document refines the route distribution 18 rules of RT-Constrain to address the hierarchical RR scenarios. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 21, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 65 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 68 1. Introduction 70 The Route Target (RT) Constrain mechanism specified in RFC 4684 is 71 used to build a route distribution graph in order to restrict the 72 propagation of Virtual Private Network (VPN) routes. In network 73 scenarios where hierarchical route reflection (RR) is used, the 74 existing RT-Constrain mechanism cannot build a correct route 75 distribution graph. 77 +---------------------------------+ 78 | +----+ | 79 | Clu-1 |RR-1| | 80 | /+----+\ | 81 | / \ | 82 | +----+ +----+ | 83 | Clu-2 |RR-2| |RR-3| Clu-3 | 84 | +-/--+ +/--\+ | 85 | / / \ | 86 | +----+ +----+ +----+ | 87 | |PE-1| |PE-2| |PE-3| | 88 | +----+ +----+ +----+ | 89 | | | | | 90 +-------|----------|---------|----+ 91 RT-1 | RT-1 | | RT-1 92 +--------+ +--------+ +--------+ 93 | VPN-1 | | VPN-1 | | VPN-1 | 94 +--------+ +--------+ +--------+ 95 Figure 1. RT-Constrain with Hierarchical RR 97 As shown in Figure 1, hierarchical RRs are deployed in the network, 98 RR-2 and RR-3 are route-reflectors of their connecting PEs, and are 99 also the clients of RR-1. If each PE advertises RT membership 100 information of RT-1 to the upstream RR, after the best path 101 selection, both RR-2 and RR-3 would create the CLUSTER_LIST 102 attribute, prepend their local CLUSTER_ID and then advertise the best 103 path to RR-1 and their clients respectively. 105 On receipt of the RT-Constrain routes from RR-2 and RR-3, RR-1 will 106 select one of the received routes as the best route, assume the route 107 received from RR-2 is selected by RR-1 as the best path. Then RR-1 108 needs to advertise the best path to both RR-2 and RR-3 to create the 109 route distribution graph of VPN-1. RR-1 would prepend its CLUSTER_ID 110 to the CLUSTER_LIST of the path, and according to the rules in 111 Section 3.2 of [RFC4684], it sets the ORIGINATOR_ID to its own 112 router-id, and the NEXT_HOP to the local address for the session. 113 Then RR-1 would advertise this route to both RR-2 and RR-3. On 114 receipt of the RT-Constrain route from RR-1, RR-2 checks the 115 CLUSTER_LIST and find its own CLUSTER_ID in the list, so this route 116 will be ignored by RR-2. As a result, RR-2 will not form the 117 outbound filter of RT-1 towards RR-1, hence will not advertise VPN 118 routes with RT-1 to RR-1. 120 2. Proposed Solution 122 The problem described in the above section is that the best path is 123 sent back to the BGP speaker which advertised the path and get 124 discarded due to the BGP loop detection mechanisms. Since the 125 advertisement of RT-Constrain route is to set up a route distribution 126 graph and not to guide the data packet forwarding, all the available 127 paths can be considered in setting up the route distribution graph, 128 not just the best path. Thus in addition to the rules specified in 129 section 3.2 of [RFC4684], the following rule applies in the 130 advertisement of RT-Constrain routes: 132 o When advertising an RT membership NLRI to a route-reflector 133 client, if the best route as selected by the path selection 134 procedure described in Section 9.1 of [RFC4271] is the path 135 received from this client, and there are alternative paths 136 received from other peers, the most disjoint alternative route 137 SHOULD be advertised to that client; The most disjoint alternative 138 path is the path whose CLUSTER_LIST and ORIGINATOR_ID attributes 139 are different from the attributes of the best path. 141 With this additional rule, RR-1 in Figure 1 would advertise to RR-2 142 the RT-Constrain route received from RR-3, although the best route is 143 received from RR-2. Thus RR-2 will not discard the RT-constrain 144 route received from RR-1, and the route distribution graph can be set 145 up completely. 147 3. IANA Considerations 149 This document makes no request of IANA. 151 4. Security Considerations 153 This document does not change the security properties of BGP based 154 VPNs and [RFC4684]. 156 5. Acknowledgements 158 The authors would like to thank Yaqun Xiao for the discussion about 159 RT-Constrain in hierarchical RR scenario. 161 6. Normative References 163 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 164 Requirement Levels", BCP 14, RFC 2119, March 1997. 166 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 167 Protocol 4 (BGP-4)", RFC 4271, January 2006. 169 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 170 R., Patel, K., and J. Guichard, "Constrained Route 171 Distribution for Border Gateway Protocol/MultiProtocol 172 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 173 Private Networks (VPNs)", RFC 4684, November 2006. 175 Authors' Addresses 177 Jie Dong 178 Huawei Technologies 179 Huawei Campus, No. 156 Beiqing Rd. 180 Beijing 100095 181 China 183 Email: jie.dong@huawei.com 184 Mach(Guoyi) Chen 185 Huawei Technologies 186 Huawei Campus, No. 156 Beiqing Rd. 187 Beijing 100095 188 China 190 Email: mach.chen@huawei.com