One document matched: draft-litkowski-idr-rtc-interas-00.txt
Interdomain Working Group S. Litkowski
Internet-Draft Orange Business Service
Intended status: Standards Track J. Haas
Expires: December 20, 2014 Juniper Networks
June 18, 2014
Inter Domain considerations for Constrained Route distribution
draft-litkowski-idr-rtc-interas-00
Abstract
[RFC4684] defines Multi-Protocol BGP (MP-BGP) procedures that allow
BGP speakers to exchange Route Target reachability information in
order to limit the propagation of Virtual Private Networks (VPN)
Network Layer Reachability Information (NLRI).
[RFC4684] addresses both intra domain and inter domain distributions.
Based on operational deployments, the current distribution model
defined in [RFC4684] may cause some issue in specific scenarios.
This document refines the route distribution rules for inter domain
NLRIs in order to address these specific scenarios.
Requirements Language
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].
Status of This Memo
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 http://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 December 20, 2014.
Litkowski & Haas Expires December 20, 2014 [Page 1]
Internet-Draft rtc-interas June 2014
Copyright Notice
Copyright (c) 2014 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
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security considerations . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Problem statement
+-------+
| DC1 | -- CE1 -- (mpebgp vpnv4+rtc) -- PE1
+-------+ \
(mpibgp vpnv4+rtc)
\
RR
/
(mpibgp vpnv4+rtc)
+-------+ /
| DC2 | -- CE2 -- (mpebgp vpnv4+rtc) -- PE2
+-------+
Figure 1
The figure above describes a typical service provider scenario where
datacenters are connected through MPLS VPN interas option B with the
Service Provider network. Route Target Constraint (RTC) is deployed
on MPeBGP sessions as well as internally in the service provider
network to ensure optimal distribution of VPN routes (required for
scaling reason). In this scenario, both Datacenters are using the
same AS number, generally a private ASN (65000) like a typical PE-CE
connection. As we expect DCs to communicate between each other, some
Litkowski & Haas Expires December 20, 2014 [Page 2]
Internet-Draft rtc-interas June 2014
features like "as-override" are deployed on PEs to overcome ASPATH
loop issue.
[RFC4684] Section 3.1 and 3.2 describes propagation of Route Target
NLRI between ASes and inside an AS and distinguish two types of NLRIs
:
o Locally originated NLRI where origin-as field of the NLRI is equal
to the local AS number.
o External NLRI where origin-as field of the NLRI is different from
the local AS number.
Regarding External NLRI, the idea of Section 3.1 and 3.2 is to
establish the route distribution tree over the shortest path
considering that BGP routing is internally consistent for a given AS.
Extract from [RFC4684] Section 3.2 :
"As indicated above, the inter-AS VPN route distribution graph, for a
given route-target, is constructed by creating a directed arc on the
inverse direction of received Route Target membership UPDATEs
containing an NLRI of the form {origin-as#, route-target}.
Inside the BGP topology of a given autonomous-system, as far as
external RT membership information is concerned (route-targets where
the as# is not the local as), it is easy to see that standard BGP
route selection and advertisement rules [4] will allow a transit AS
to create the necessary flooding state."
In the Figure 1, CE1 and CE2 are advertising the RT 1:1 respectively
to PE1 and PE2, the generated NLRI would be 65000:2:1:1/96.
According to procedures defined in [RFC4684] Section 3.2, both PEs
are using the standard BGP route selection and advertising rules. So
both PEs are advertising their path for 65000:2:1:1/96 to the route-
reflector. The route-reflector would also use the standard BGP route
selection to create the RT flooding state. Considering that path
from PE1 is the best one, a flooding tree branch for RT 1:1 is
created only towards PE1.
Due to this behavior, VPN routes from DC1 would never to send to DC2
because PE2 is not part of the flooding tree and as DC1 and DC2 are
disjoint, even if they are using the same ASN, there is no
communication possible between them.
The same issue may appear if two MPeBGP sites using the same ASN are
connected on the same PE like in figure 2.
Litkowski & Haas Expires December 20, 2014 [Page 3]
Internet-Draft rtc-interas June 2014
+-------+
| DC1 |
+-------+
\
(mpebgp vpnv4+rtc)
\
PE
/
(mpebgp vpnv4+rtc)
/
+-------+
| DC2 |
+-------+
Figure 2
2. Proposal
This document proposes to modify the following procedures defined in
[RFC4684] :
1. [RFC4684] Section 3.1 :
"Using RT membership information that includes both route-target and
originator AS number allows BGP speakers to use standard path
selection rules concerning as-path length (and other policy
mechanisms) to prune duplicate paths in the RT membership information
flooding graph, while maintaining the information required to reach
all autonomous systems advertising the Route Target."
2. [RFC4684] Section 3.2 :
"As indicated above, the inter-AS VPN route distribution graph, for a
given route-target, is constructed by creating a directed arc on the
inverse direction of received Route Target membership UPDATEs
containing an NLRI of the form {origin-as#, route-target}.
Inside the BGP topology of a given autonomous-system, as far as
external RT membership information is concerned (route-targets where
the as# is not the local as), it is easy to see that standard BGP
route selection and advertisement rules [4] will allow a transit AS
to create the necessary flooding state."
In order to support our scenario, path pruning may be disabled by
configuration for a given origin AS (different from the local AS).
Implementations may also permit path pruning to be disabled for
private AS numbers by default, but must make provision for it to be
selectively enabled if such a feature is present.
Litkowski & Haas Expires December 20, 2014 [Page 4]
Internet-Draft rtc-interas June 2014
This modification in establishing route distribution tree may create
unnecessary flooding states in the situations where a real
AS is multihomed to a service provider network (as displayed in
Figure 3).
ASN 65000 ASN 64000
+-----------+ +-------------+
| ASBR3 | -- (mpebgp vpnv4+rtc) -- ASBR1 PE1 ---- | CE1 --- DC1 |
| | | \ / +-------------+
| | | (mpibgp vpnv4+rtc)
|(vpnv4+rtc)| \ /
| | | RR
| | | / \
| | | (mpibgp vpnv4+rtc) ASN 64000
| | | / \ +-------------+
| ASBR4 | -- (mpebgp vpnv4+rtc) -- ASBR2 PE2 ---- | CE2 --- DC2 |
+-----------+ +-------------+
Figure 3
In the figure above, disabling pruning is required for AS64000 but it
may be interesting to keep it enabled for AS65000. Implementations
may require support for such granularity as proposed previously.
3. Security considerations
This document does not introduce any new security issue compared to
[RFC4684].
4. Acknowledgements
5. IANA Considerations
There is no IANA consideration.
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006.
Litkowski & Haas Expires December 20, 2014 [Page 5]
Internet-Draft rtc-interas June 2014
Authors' Addresses
Stephane Litkowski
Orange Business Service
Email: stephane.litkowski@orange.com
Jeff Haas
Juniper Networks
Email: jhaas@juniper.net
Litkowski & Haas Expires December 20, 2014 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 01:37:37 |