| Internet-Draft | Hierarchical RR RT-Constraints | March 2023 |
| Mohanty, et al. | Expires 8 September 2023 | [Page] |
Route Target Constraints (RTC) is used to build a VPN route distribution graph such that routers only receive VPN routes corresponding to specified route-targets (RT) that they are interested in. This is done by exchanging the route-targets as routes in the RTC address-family and a corresponding "RT filter" is installed that influences the VPN route advertisement. In networks employing hierarchical Route Reflectors (RR) the use of RTC can lead to incorrect VPN route distribution and loss in connectivity as detailed in an earlier draft . Two solutions were provided to overcome the problem.¶
This draft presents a method with suggested modifications to the RTC RFC in order to solve the hierarchical RR RTC problem in an efficient manner.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 September 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶
Hierarchical RR [RFC4456] deployments with VPN [RFC4364] working in conjunction with RTC [RFC4684] may result in sub-optimal and incorrect VPN route distribution that is nicely described in [I-D.ietf-idr-rtc-hierarchical-rr]. The root reason for this is the way the RR rules for RTC are defined in [RFC4684]. The authors of [I-D.ietf-idr-rtc-hierarchical-rr] furnish two solutions for the problem, one based on add-paths and the other based on diverse-paths constructs. In this memo, we present another another solution to the very same problem.¶
When advertising RT membership NLRI to a route-reflector client, Section 3.2 of [RFC4684] advocates the advertising RR to set the ORIGINATOR_ID attribute [RFC4456] to its own router-id, and the Next-hop attribute to be set to the local address for that session. However, this creates the issue in hierarchical RR setups as explained in [I-D.ietf-idr-rtc-hierarchical-rr]. Fig. 1 represents the same Figure as in [I-D.ietf-idr-rtc-hierarchical-rr]. When RR-2 and RR-3 advertise RT-1 to RR-1, the latter will choose one of the routes to be best and will advertise the same to RR-2 and RR-3 respectively after setting the ORIGINATOR_ID and next-hop to itself. Note that RR-1 will also add its own CLUSTER_ID [RFC4456]to the CLUSTER_LIST but importantly not overwrite the CLUSTER_ID of the sender. This leads to the issue explained in [I-D.ietf-idr-rtc-hierarchical-rr].¶
In the Fig 1, when RR-1 chooses the route from RR-2 as the best route, and formats the next-hop and ORIGINATOR_ID as explained above and then advertises the route to RR-2, RR-2 will drop the route reflected from RR-1 because of the CLUSTER_ID check.¶
+---------------------------------+
| +----+ |
| Clu-1 |RR-1| |
| /+----+\ |
| / \ |
| +----+ +----+ |
| Clu-2 |RR-2| |RR-3| Clu-3 |
| +-/--+ +/--\+ |
| / / \ |
| +----+ +----+ +----+ |
| |PE-1| |PE-2| |PE-3| |
| +----+ +----+ +----+ |
| | | | |
+-------|----------|---------|----+
RT-1 | RT-1 | | RT-1
+--------+ +--------+ +--------+
| VPN-1 | | VPN-1 | | VPN-1 |
+--------+ +--------+ +--------+
Figure 1 Hierarchical RR Setup with RTC
RR-2 will therefore not form the outbound filter of RT-1 towards RR-1 which means that after convergence RR-2 will not advertise VPN routes to RR-1 anymore. This leads to an incorrect VPN route distribution across the network.¶
In the scenario of Fig 2. CE-1 is multi-homed to PE-1 and PE-2 and wants to communicate with CE-2 which is behind PE-4. As explained earlier, because RR-1 chooses RR-2 path as best in the RTC family, RR-1 is only receiving the VPN route from RR-3 (and not RR-2) in the steady state.¶
+---------------------------------+
| +----+ +-----+ | +------------+
| Clu-1 |RR-1| ---|PE-4 |- - -| VPN-1 (CE2)|
| /+----+\ +-----+ | +------------+
| / \ |
| +----+ +----+ |
| Clu-2 |RR-2| |RR-3| Clu-3 |
| +-/--+ +--\-+ |
| / \ |
| +----+ +----+ |
| |PE-1| |PE-2| |
| +----+ +--/-+ |
| \ / |
+----------\-----------/----------+
\ RT-1 /
+--------+ ----|
| VPN-1 (CE1) |
--------------|
Figure 2 Hierarchical RR Setup with RTC with dual-homed CE
Notice that even though the link between between RR-3 and RR-1 comes down, The RR-2 PATH still remains as best in the RTC address-family at RR-1 and the VPN route advertisements to RR-1 from RR-2 still continue to be blocked. Thus even though there is an alternative connectivity from CE-1 to PE-4 via PE-1, RR-2 and RR-1, the BGP VPN routes cannot be sent. In fact CE-1 is completely cut-off from rest of the network. Generalizing, it means that in a hierarchical RR with only a single first-level RR as its client, the solution is completely broken. Notice that without RTC, RR-1 would have both VPN paths and the loss of connectivity to RR-3 would just result in local convergence at RR-1 subject to the time when the path from RR-2 becomes best.¶
The solutions presented in [I-D.ietf-idr-rtc-hierarchical-rr] are based on¶
In the next section, we provide a solution, that does not require add-path and also improves upon [RFC4684] while solving this hierarchical RR issue in RTC.¶
A problem that [RFC4684] does not address is limiting the number for VPN routes advertised to AN RR when only one client advertises RTC routes. Consider in Figure 1 that PE-1 is the only one advertising a RTC route to RR-2. RR-2 will advertise back the route towards PE-1 (with next-hop/ORIGINATOR_ID rewriting to avoid PE-1 discarding the route). PE-1 will advertise VPN routes towards RR-1, which is unnecessary and wastes resources on RR-1.¶
In the description that follows we define Attribute diversity to mean RTC routes with different ORIGINATOR_ID attribute (or router-id of the peer it is received from if ORIGINATOR_ID does not exist), or different first CLUSTER_ID inside the CLUSTER_LIST (an empty CLUSTER_ID is different to any other non-empty CLUSTER_ID). Diversity for ORIGINATOR_ID is typically used for first level RRs, diversity for CLUSTER_LIST is typically used for higher level RRs.¶
Both diversity attributes can be used in combination when the RR has a mix of clients (that are themselves RRs and non-RRs). The underlying assumptions for looking at CLUSTER_ID for attribute diversity is that any clients that are also route-reflectors and have the same CLUSTER_ID, will themselves have the same set of clients. Imagine a a higher level RR receiving the same route from two lower level RRs with the same CLUSTER_ID. It will not reflect back the RTC if only the same CLUSTER_ID is received from its clients (as first CLUSTER_ID in the CLUSTER_LIST).¶
The following rule modifies the [RFC4684].¶
The rule above will apply as well to a top level RR, guaranteeing that top level RR does not have unnecessary routes.¶
We need to take care that when reflecting back a RTC route to the advertising client, this client does not discard the update. RFC 4684 mandates to overwrite next-hop to self and the ORIGINATOR_ID to our local router-id when advertising RTC route a route reflector client (section 3.2, rule (i) ). This rule can be extended to take care of the case where the reflection happens at a higher level RR (See Rule(1) below). Additionally, no attribute overwriting is deemed necessary when reflecting a RTC route from client to non-client. Thus, the following rule is added to RFC 4684.¶
With the Rule 1. since we are over-writing the cluster-id, the receiver will accept the route. With Rule 2., in the above Fig. 1 and 2 when RR-2 receives the update from RR-1, it will accept the route and will treat it as "Received-only". However, although the route will not be eligible for advertisement, but since this route is accepted, the VPN filter is installed and VPN routes will be advertised from RR-2 to RR-1. Both rules are exclusive of each other.¶
With the procedures it is not necessary for the RR to know in which level it is operating. The above rules are compatible. We always advertise best-path for any rule and it is easily seen that RR-2 will accept the RT Constraint path advertised from RR-1 . Since the path is accepted, the RT Filter at RR-2 will pass the VPN routes, and the problem scenarios are resolved accordingly.¶
With this specification in the RT-Constraint address-family, we solve both the incorrect and sub-optimal issues as mentioned above. There is no need for add-paths. We can also optimize over [RFC4684] on RTC advertisements based on diversity of ORIGINATOR_ID and CLUSTER_ID so that a higher level RR does not have to be populated with VPN routes with a specific RT if that RT is not present in other clusters.¶
None.¶
This document raises no new security issues for RT Constraints.¶
The authors would like to thank Swadesh Agrawal and M. Mirza for useful discussions related to hierarchical RR RTC.¶