Internet DRAFT - draft-litkowski-idr-rtc-interas
draft-litkowski-idr-rtc-interas
Interdomain Working Group S. Litkowski
Internet-Draft Orange Business Service
Intended status: Standards Track J. Haas
Expires: September 6, 2015 Juniper Networks
K. Patel
Cisco Systems
March 5, 2015
Inter Domain considerations for Constrained Route distribution
draft-litkowski-idr-rtc-interas-01
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 September 6, 2015.
Litkowski, et al. Expires September 6, 2015 [Page 1]
Internet-Draft rtc-interas March 2015
Copyright Notice
Copyright (c) 2015 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. External NLRI propagation . . . . . . . . . . . . . . . . . . 2
1.1. Peering type based pruning . . . . . . . . . . . . . . . 3
1.2. NLRI type based pruning . . . . . . . . . . . . . . . . . 4
1.3. Analysis of both approaches . . . . . . . . . . . . . . . 4
2. Problem statement : disjoint peer AS . . . . . . . . . . . . 5
3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. External NLRI propagation
[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.
The global idea of inter AS propagation, is to propagate only VPN
routes on shortest path towards the peer ASes using pruning of some
branches of the distribution tree.
Based on current implementations of RFC4684, we can see two flavors
of pruning for interAS that are both compatible with RFC4684 text.
Litkowski, et al. Expires September 6, 2015 [Page 2]
Internet-Draft rtc-interas March 2015
o Pruning based on peering type : pruning rule is applied when RT
membership path are learned from eBGP peers only. No pruning is
applied when path is iBGP.
o Pruning based on NLRI type : pruning rule is applied to external
RT membership NLRIs (source AS different from local AS). This
pruning rule applies both to eBGP and iBGP.
1.1. Peering type based pruning
AS 400 AS 500
|
ASBR1 --- (mpebgp vpnv4+rtc)___
| \
| \
ASBR2 --- (mpebgp vpnv4+rtc) -- PE1
| \
| (mpibgp vpnv4+rtc)
| \
| RR ------------ PE3
| /
| (mpibgp vpnv4+rtc)
| /
ASBR3 --- (mpebgp vpnv4+rtc) -- PE2
|
|
Figure 1
In the figure above, ASBR1,ASBR2 and ASBR3 are MPLS VPN nodes part of
the AS 400. We consider that all these ASBRs are importing the same
RT : 400:1, which is also exported by PE3. All ASBRs will generate
the same RT membership NLRI 400:400:1/96 towards their PE. PE2 will
send its path for this RT membership to RR. As PE1 has two ebgp
paths for the same RT membership NLRI, it will apply pruning (as per
peering type based pruning policy), if we consider that path from
ASBR1 is the best path, RT distribution tree will only have a branch
to ASBR1, and so ASBR2 will not receive any VPN route for RT 400:1
from PE1. PE1 will also send the RT membership NLRI to RR. RR will
so have two paths for NLRI 400:400:1/96. As both path are iBGP, no
pruning will be applied (as per peering type based pruning policy),
and RR will create tree branches for 400:1 to both PE1 and PE2. As a
result, VPN routes originated by PE3 with RT 400:1 will be sent by RR
to PE1 and PE2. PE1 will propagate the routes only to ASBR1. PE2
will propagate the routes to ASBR3. AS 400 will have knowledge from
PE3 routes only from ASBR1 and ASBR2.
Litkowski, et al. Expires September 6, 2015 [Page 3]
Internet-Draft rtc-interas March 2015
1.2. NLRI type based pruning
We consider the same setup as in Figure 1. All ASBRs will generate
the same RT membership NLRI 400:400:1/96 towards their PE. PE2 will
send its path for this RT membership to RR. As PE1 has two ebgp
paths for the same external RT membership NLRI, it will apply pruning
(as per NLRI type based pruning policy, pruning is applied because
NLRI is external), if we consider that path from ASBR1 is the best
path, RT distribution tree will only have a branch to ASBR1, and so
ASBR2 will not receive any VPN route for RT 400:1 from PE1. PE1 will
also send the RT membership NLRI to RR. RR will so have two paths
for NLRI 400:400:1/96. As the NLRI is external, pruning will be
applied : if we consider that path from PE1 is the best one, a single
branch of distribution tree will be added towards PE1. As a result,
VPN routes originated by PE3 with RT 400:1 will be sent by RR to PE1
only. PE1 will propagate the routes only to ASBR1. AS 400 will have
knowledge from PE3 routes only from ASBR1.
AS 400 AS 500 AS 400
| |
| |
| |
cPE1 --------- sPE1 ------ RR ------- sPE2 ---------- cPE2
| |
| |
Figure 2
Figure 2 presents at typical case where an AS (AS400) uses another AS
(AS500) as transit to build VPN services. If cPE1 and cPE2 shares a
common VPN using RT 400:1, in case of NLRI type based pruning in
AS500, RR in AS500 will perform pruning of VPN routes for NLRI
400:400:1/96. Considering that path from sPE1 is considered as best
path, sPE2 will be pruned and cPE2 will never receive VPN routes from
cPE1. This issue is discussed further in Section 2.
1.3. Analysis of both approaches
Both pruning approaches have pros and cons. Service Provider will
need to be aware of this pros/cons while deploying inter AS RTC.
o NLRI type based pruning helps in saving BGP paths in network
nodes, inter AS distribution tree is only established on shortest
path (at AS boundary and within the AS). In figure 1, PE2 does
not receive VPN routes for RT 400:1 because these routes are
already advertised through another path. This approach prevents
hot potatoe routing and transit for disjoint ASes.
Litkowski, et al. Expires September 6, 2015 [Page 4]
Internet-Draft rtc-interas March 2015
o Peering type based pruning is based on the fact that the local AS
does not know the precise location of the VPNs in the peer AS, so
there is no reason for a route reflector to perform blind pruning
that may lead to suboptimal routing. In figure 1, if we consider
that ASBR3 is located in New York City, and ASBR1/2 are located in
San Francisco. Considering that PE3 is located in Washington,
performing NLRI type based pruning will prevent ASBR3 to receive
PE3 routes, so routing from Washington to New York City will
transit through San Francisco. We must note that in case of ASBR1
and ASBR2 being in two far cities, peering type based pruning will
also suffer from suboptimal routing. The other point in favor of
peering type pruning is faster convergence. In figure 1, when PE1
fails, backup routes are already available in AS400 through ASBR3.
As a summary, NLRI type based pruning helps in saving BGP paths in
the transit networks, while peering type based pruning permits more
optimal routing and faster convergence with the drawback of
propagating additional routes. Peering type based pruning may also
experience convergence or suboptimal routing case in case a single
node is attached to multiple routers in the external AS.
2. Problem statement : disjoint peer AS
The previous section described how inter AS route distribution works
and pros and cons of the existing approaches. Apart of these pros/
cons, pruning in both solutions may lead to some problematic
situation where the remote AS is disjoint, as already shown in
Section 1.2.
+-------+
| DC1 | -- CE1 -- (mpebgp vpnv4+rtc) -- PE1
+-------+ \
(mpibgp vpnv4+rtc)
\
RR
/
(mpibgp vpnv4+rtc)
+-------+ /
| DC2 | -- CE2 -- (mpebgp vpnv4+rtc) -- PE2
+-------+
Figure 3
The figure above describes another 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
Litkowski, et al. Expires September 6, 2015 [Page 5]
Internet-Draft rtc-interas March 2015
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.
In the Figure 3, CE1 and CE2 are advertising the RT 1:1 respectively
to PE1 and PE2, the generated NLRI would be 65000: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:1:1/96 to the route-reflector.
In case of NLRI type based pruning, route-reflector will establish
the distribution tree only to PE1 (considering PE1 is the best path).
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 4. In this situation both
NLRI type based pruning and Peering type based pruning solutions are
impacted.
+-------+
| DC1 |
+-------+
\
(mpebgp vpnv4+rtc)
\
PE
/
(mpebgp vpnv4+rtc)
/
+-------+
| DC2 |
+-------+
Figure 4
3. Proposal
This document proposes to introduce some new behavior in complement
of [RFC4684] to manage the disjoint AS case.
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, et al. Expires September 6, 2015 [Page 6]
Internet-Draft rtc-interas March 2015
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.
4. Security considerations
This document does not introduce any new security issue compared to
[RFC4684].
5. Acknowledgements
6. IANA Considerations
There is no IANA consideration.
7. 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, et al. Expires September 6, 2015 [Page 7]
Internet-Draft rtc-interas March 2015
Authors' Addresses
Stephane Litkowski
Orange Business Service
Email: stephane.litkowski@orange.com
Jeff Haas
Juniper Networks
Email: jhaas@juniper.net
Keyur Patel
Cisco Systems
Email: keyupate@cisco.com
Litkowski, et al. Expires September 6, 2015 [Page 8]
