draft-ietf-idr-rtc-hierarchical-rr-01.txt   draft-ietf-idr-rtc-hierarchical-rr-02.txt 
Network Working Group J. Dong Network Working Group J. Dong
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: December 27, 2015 R. Raszuk Expires: December 2, 2016 R. Raszuk
Mirantis Inc. Bloomberg LP
June 25, 2015 May 31, 2016
Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios
draft-ietf-idr-rtc-hierarchical-rr-01 draft-ietf-idr-rtc-hierarchical-rr-02
Abstract Abstract
The Route Target (RT) Constrain mechanism specified in RFC 4684 is The Route Target (RT) Constrain mechanism specified in RFC 4684 is
used to build a route distribution graph in order to restrict the used to build a route distribution graph in order to restrict the
propagation of Virtual Private Network (VPN) routes. In network propagation of Virtual Private Network (VPN) routes. In network
scenarios where hierarchical route reflection (RR) is used, the scenarios where hierarchical route reflection (RR) is used, the
existing RT-Constrain mechanism cannot build a correct route existing RT-Constrain mechanism cannot guarantee a correct route
distribution graph. This document describes the problem scenario and distribution graph. This document describes the problem scenario and
proposes a solution to address the RT-Constrain issue in hierarchical proposes a solution to address the RT-Constrain issue in hierarchical
RR scenarios. RR scenarios.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2015. This Internet-Draft will expire on December 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
3. Potential Solutions . . . . . . . . . . . . . . . . . . . . . 3 3. Potential Solutions . . . . . . . . . . . . . . . . . . . . . 3
3.1. Add-path Based Solution . . . . . . . . . . . . . . . . . 4 3.1. Add-path Based Solution . . . . . . . . . . . . . . . . . 4
3.2. Disjoint Alternate Path Solution . . . . . . . . . . . . 4 3.2. Disjoint Alternate Path Solution . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The Route Target (RT) Constrain mechanism specified in [RFC4684] is The Route Target (RT) Constrain mechanism specified in [RFC4684] is
used to build a route distribution graph in order to restrict the used to build a route distribution graph in order to restrict the
propagation of Virtual Private Network (VPN) routes. In network propagation of Virtual Private Network (VPN) routes. In network
scenarios where hierarchical route reflection (RR) is used, the scenarios where hierarchical route reflection (RR) is used, the
existing advertisment rules of RT membership information as defined existing advertisment rules of RT membership information as defined
in section 3.2 of [RFC4684] cannot guarantee a correct route in section 3.2 of [RFC4684] cannot guarantee a correct route
skipping to change at page 3, line 34 skipping to change at page 3, line 34
As shown in Figure 1, hierarchical RRs are deployed in the network, As shown in Figure 1, hierarchical RRs are deployed in the network,
RR-2 and RR-3 are route-reflectors of their connecting PEs, and are RR-2 and RR-3 are route-reflectors of their connecting PEs, and are
also the clients of RR-1. If each PE advertises RT membership also the clients of RR-1. If each PE advertises RT membership
information of RT-1 to the upstream RR, after the best path information of RT-1 to the upstream RR, after the best path
selection, both RR-2 and RR-3 would create the CLUSTER_LIST selection, both RR-2 and RR-3 would create the CLUSTER_LIST
attribute, prepend their local CLUSTER_ID and then advertise the best attribute, prepend their local CLUSTER_ID and then advertise the best
path to RR-1 and their clients respectively. path to RR-1 and their clients respectively.
On receipt of the RT-Constrain routes from RR-2 and RR-3, RR-1 will On receipt of the RT-Constrain routes from RR-2 and RR-3, RR-1 will
select one of the received routes as the best route, here assume the select one of the received routes as the best route, here assume the
route received from RR-2 is selected by RR-1 as the best path. Then route received from RR-2 is selected by RR-1 as the best route. Then
RR-1 needs to advertise the best path to both RR-2 and RR-3 to create RR-1 needs to advertise the best RT-Constrain route to both RR-2 and
the route distribution graph of VPN-1. RR-1 would prepend its RR-3 to create the route distribution graph of VPN-1. RR-1 would
CLUSTER_ID to the CLUSTER_LIST of the path, and according to the prepend its CLUSTER_ID to the CLUSTER_LIST of the path, and according
rules in Section 3.2 of [RFC4684], it sets the ORIGINATOR_ID to its to the rules in Section 3.2 of [RFC4684], it sets the ORIGINATOR_ID
own router-id, and the NEXT_HOP to the local address for the session. to its own router-id, and the NEXT_HOP to the local address for the
Then RR-1 would advertise this route to both RR-2 and RR-3. On session. Then RR-1 would advertise this route to both RR-2 and RR-3.
receipt of the RT-Constrain route from RR-1, RR-2 checks the On receipt of the RT-Constrain route from RR-1, RR-2 checks the
CLUSTER_LIST and find its own CLUSTER_ID in the list, so this route CLUSTER_LIST and find its own CLUSTER_ID in the list, so this route
will be ignored by RR-2. As a result, RR-2 will not form the will be ignored by RR-2. As a result, RR-2 will not form the
outbound filter of RT-1 towards RR-1, hence will not advertise VPN outbound filter of RT-1 towards RR-1, hence it will not advertise the
routes with RT-1 to RR-1. VPN routes of VPN-1 to RR-1.
3. Potential Solutions 3. Potential Solutions
This document specifies 2 potential solutions for the RTC issue in This document specifies 2 potential solutions for the RTC issue in
hierarchical RR scenario. In a future revision one solution would be hierarchical RR scenario. In a later revision, one solution will to
selected based on the decision of IDR working group. be selected based on the decision of the IDR working group.
3.1. Add-path Based Solution 3.1. Add-path Based Solution
This section provides one possible solution which is based on the This section provides one possible solution which is based on the
add-path mechanism defined in [I-D.ietf-idr-add-paths]. It makes use add-path mechanism defined in [I-D.ietf-idr-add-paths]. It makes use
of the add-path mechanism for RTC route advertisement between the of the add-path mechanism for RTC route advertisement between the
hierarchical RRs. The solution is summerized as follows: hierarchical RRs. The solution is summerized as follows:
o The route-reflector clients which themselves are also route- o The route-reflector clients which themselves are also route-
reflectors SHOULD be identified, then BGP add-paths reflectors SHOULD be identified, then BGP add-paths
skipping to change at page 5, line 36 skipping to change at page 5, line 36
Constrain issue in hierarchical RR scenario. Many people have made Constrain issue in hierarchical RR scenario. Many people have made
valuable comments and suggestions, including Susan Hares, Jeffrey valuable comments and suggestions, including Susan Hares, Jeffrey
Haas, Stephane Litkowski, Vitkovsky Adam, Xiaohu Xu, Uttaro James, Haas, Stephane Litkowski, Vitkovsky Adam, Xiaohu Xu, Uttaro James,
Shyam Sethuram, Saikat Ray and Bruno Decraene. Shyam Sethuram, Saikat Ray and Bruno Decraene.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Protocol 4 (BGP-4)", RFC 4271, January 2006. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006. Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <http://www.rfc-editor.org/info/rfc4684>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-10 (work in progress), October 2014. add-paths-15 (work in progress), May 2016.
Authors' Addresses Authors' Addresses
Jie Dong Jie Dong
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Robert Raszuk Robert Raszuk
Mirantis Inc. Bloomberg LP
615 National Ave. #100 731 Lexington Ave
Mt View, CA 94043 New York City, NY 10022
USA USA
Email: robert@raszuk.net Email: robert@raszuk.net
 End of changes. 14 change blocks. 
28 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/