One document matched: draft-litkowski-idr-rtc-interas-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4684 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4684.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- used by XSLT processors -->
<!-- OPTIONS, known as processing instructions (PIs) go here. -->
<!-- For a complete list and description of PIs,
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable PIs that most I-Ds might want to use. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC): -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references: -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space:
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of popular PIs -->
<rfc category="std" docName="draft-litkowski-idr-rtc-interas-00"
ipr="trust200902">
<front>
<title abbrev="rtc-interas">Inter Domain considerations for Constrained Route distribution</title>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Orange Business Service</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>stephane.litkowski@orange.com</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Jeff Haas" initials="J" surname="Haas">
<organization>Juniper Networks</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>jhaas@juniper.net</email>
<!-- <uri/> -->
</address>
</author>
<date year="2014"/>
<area/>
<workgroup>Interdomain Working Group</workgroup>
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<!-- <keyword/> -->
<abstract>
<t>
<xref target="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).
</t>
<t>
<xref target="RFC4684"/> addresses both intra domain and inter domain distributions. Based on operational deployments,
the current distribution model defined in <xref target="RFC4684"/> may cause some issue in specific scenarios.
</t>
<t>
This document refines the route distribution rules for inter domain NLRIs in order to address these specific scenarios.
</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119"/>.</t>
</note>
</front>
<middle>
<section anchor="problem-statement" title="Problem statement">
<figure>
<artwork>
+-------+
| DC1 | -- CE1 -- (mpebgp vpnv4+rtc) -- PE1
+-------+ \
(mpibgp vpnv4+rtc)
\
RR
/
(mpibgp vpnv4+rtc)
+-------+ /
| DC2 | -- CE2 -- (mpebgp vpnv4+rtc) -- PE2
+-------+
Figure 1
</artwork>
</figure>
<t>
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 features like "as-override" are deployed on PEs to overcome ASPATH loop issue.
</t>
<t>
<xref target="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 :
<list style="symbols">
<t>Locally originated NLRI where origin-as field of the NLRI is equal to the local AS number.</t>
<t>External NLRI where origin-as field of the NLRI is different from the local AS number.</t>
</list>
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.
</t>
<t>
Extract from <xref target="RFC4684"/> Section 3.2 :
<figure>
<artwork>
"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."
</artwork>
</figure>
</t>
<t>
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 <xref target="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.
</t>
<t>
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.
</t>
<t>
The same issue may appear if two MPeBGP sites using the same ASN are connected on the same PE like in figure 2.
</t>
<figure>
<artwork>
+-------+
| DC1 |
+-------+
\
(mpebgp vpnv4+rtc)
\
PE
/
(mpebgp vpnv4+rtc)
/
+-------+
| DC2 |
+-------+
Figure 2
</artwork>
</figure>
</section>
<section anchor="proposal" title="Proposal">
<t>
This document proposes to modify the following procedures defined in <xref target="RFC4684"/> :
<list style="numbers">
<t><xref target="RFC4684"/> Section 3.1 :
<figure>
<artwork>
"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."
</artwork>
</figure>
</t>
<t><xref target="RFC4684"/> Section 3.2 :
<figure>
<artwork>
"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."
</artwork>
</figure>
</t>
</list>
</t>
<t>
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.
</t>
<t>
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).
<figure>
<artwork>
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
</artwork>
</figure>
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.
</t>
</section>
<section anchor="Security" title="Security considerations">
<t>
This document does not introduce any new security issue compared to <xref target="RFC4684"/>.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements"/>
<section anchor="IANA" title="IANA Considerations">
<t>There is no IANA consideration.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4684;
&RFC4364;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:54:44 |