draft-ietf-idr-rtc-hierarchical-rr-02.txt   draft-ietf-idr-rtc-hierarchical-rr-03.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 2, 2016 R. Raszuk Expires: January 4, 2018 R. Raszuk
Bloomberg LP Bloomberg LP
May 31, 2016 July 3, 2017
Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios
draft-ietf-idr-rtc-hierarchical-rr-02 draft-ietf-idr-rtc-hierarchical-rr-03
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 guarantee 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
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 2, 2016. This Internet-Draft will expire on January 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 4, line 8 skipping to change at page 4, line 8
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 later revision, one solution will to hierarchical RR scenario. In a later revision, one solution will to
be selected based on the decision of the 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 [RFC7911]. It makes use of the add-
of the add-path mechanism for RTC route advertisement between the path mechanism for RTC route advertisement between the hierarchical
hierarchical RRs. The solution is summerized as follows: 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 [RFC7911]
[I-D.ietf-idr-add-paths] SHOULD be enabled for RT membership NLRI SHOULD be enabled for RT membership NLRI on the BGP sessions
on the BGP sessions between the higher layer RR and the lower between the higher layer RR and the lower layer RRs to ensure that
layer RRs to ensure that sufficient RT-Constrain routes can be sufficient RT-Constrain routes can be advertised by the higher
advertised by the higher layer RR to the lower layer RRs to pass layer RR to the lower layer RRs to pass BGP loop detection. In
BGP loop detection. In this case normal BGP path advertisement this case normal BGP path advertisement rules as defined in
rules as defined in [RFC4271] SHOULD be applied. The number of [RFC4271] SHOULD be applied. The number of RT-Constrain routes to
RT-Constrain routes to be advertised with add-path mechanism is a be advertised with add-path mechanism is a local decision of
local decision of operators. To ensure that sufficient RT- operators. To ensure that sufficient RT-Constrain routes are
Constrain routes are advertised to build the distribution graph, advertised to build the distribution graph, the recommended add-
the recommended add-path number is the maximum number of the BGP path number is the maximum number of the BGP client sessions in
client sessions in the same cluster plus 1. the same cluster plus 1.
o When advertising an RT membership NLRI to a route-reflector client o When advertising an RT membership NLRI to a route-reflector client
which is not a lower layer RR, the advertisement rule as defined which is not a lower layer RR, the advertisement rule as defined
in section 3.2 of [RFC4684] SHOULD be applied. in section 3.2 of [RFC4684] SHOULD be applied.
With the above advertisement rule, RR-1 in figure 1 SHOULD advertise With the above advertisement rule, RR-1 in figure 1 SHOULD advertise
to RR-2 the RT-Constrain routes received from both RR-2 and RR-3, to RR-2 the RT-Constrain routes received from both RR-2 and RR-3,
then the RTC route from RR-3 will pass the BGP loop detection on RR- then the RTC route from RR-3 will pass the BGP loop detection on RR-
2, thus the route distribution graph can be set up correctly. 2, thus the route distribution graph can be set up correctly.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
[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, DOI 10.17487/RFC4684, Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
November 2006, <http://www.rfc-editor.org/info/rfc4684>. November 2006, <http://www.rfc-editor.org/info/rfc4684>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-idr-add-paths] [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- DOI 10.17487/RFC7911, July 2016,
add-paths-15 (work in progress), May 2016. <http://www.rfc-editor.org/info/rfc7911>.
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
 End of changes. 8 change blocks. 
24 lines changed or deleted 24 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/