Document 3: Symmetric Routing
Tony Bates <Tony.Bates@mci.net> Fri, 28 April 1995 22:43 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06879;
28 Apr 95 18:43 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06875;
28 Apr 95 18:43 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa15586;
28 Apr 95 18:43 EDT
Received: by interlock.ans.net id AA38385
(InterLock SMTP Gateway 3.0 for iwg-out@ans.net);
Fri, 28 Apr 1995 18:20:39 -0400
Message-Id: <199504282220.AA38385@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2);
Fri, 28 Apr 1995 18:20:39 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1);
Fri, 28 Apr 1995 18:20:39 -0400
To: bgp@ans.net
Subject: Document 3: Symmetric Routing
Cc: enke@mci.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tony Bates <Tony.Bates@mci.net>
X-Phone: +1 703 715 7521
Date: Fri, 28 Apr 1995 18:20:31 -0400
X-Orig-Sender: tony@mci.net
INTERNET-DRAFT Enke Chen
<draft-ietf-idr-mpp-application-00.txt> Tony Bates
MCI
April 1995
Application of the BGP Multi-Provider Preference
Attribute in Implementing Symmetric Routing
<draft-ietf-idr-mpp-application-00.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
This paper presents applications of the proposed Multi-Provider
Preference (MPP) attribute for BGP. It shows how the MPP attribute
can aid in the implementation of symmetric inter-domain routing in
the multi-provider Internet.
1. Introduction
An Multi-Provider Preference (MPP) attribute is proposed [4] for the
purpose of facilitating symmetric routing in the multi-provider
Internet. This paper presents applications of the MPP attribute. It
illustrates how the MPP attribute facilitates the implementation of
the routing requirements of the typical cases presented in [3].
This paper assumes that in general an ISP treats other ISPs equally
Chen & Bates [Page 1]
INTERNET-DRAFT Application of MPP April 1995
(in terms of the "local_pref" parameter) in the route selection
process. It also assumes the following order of preference is
followed for the purpose of route selection: first the "local_pref"
parameter, followed by the MPP attribute, the shortest AS-path, the
MED, and the IGP metric.
2. Application of the MPP Attribute
In [3] we present several typical topologies of Internet connections,
their inter-domain routing requirements, and the current practice to
implement these routing policies. This section illustrates how the
MPP attribute can be used to facilitate the implementation.
2.1 An Entity with a Single Direct Provider
+-----+ +-----+ +-----+
| ISP | | ISP | | ISP |
+-----+ +-----+ +-----+
| | |
+-----+ +-----+ +-----+
| AS1 | | RSP | | RSP |
+-----+ +-----+ +-----+
|
+-----+
| AS1 |
+-----+
(a) (b) (c)
Figure 1
The routing is always symmetric at the inter-domain level. The MPP
attribute should not be set as is not needed.
AS1 can either take full routing or use default.
Chen & Bates [Page 2]
INTERNET-DRAFT Application of MPP April 1995
2.2 Backup of Entities with Different Direct Providers
+-----+ +------+ +------+
| ISP | | ISP3 | | ISP3 |
+-----+ +------+ +------+
/ \ / \ / \
/ \ / (NAP) \ / (NAP) \
+-----+ +-----+ +------+ +------+ +------+ +------+
| AS1 |----| AS2 | | ISP1 |------| ISP2 | | ISP1 |-------| ISP2 |
+-----+ +-----+ +------+ +------+ +------+ +------+
| | | |
+------+ +------+ +------+ +------+
| AS1 |------| AS2 | | RSP1 | | RSP2 |
+------+ +------+ +------+ +------+
| |
+------+ +------+
| AS1 |------| AS2 |
+------+ +------+
(a) (b) (c)
Figure 2
In all cases of Figure 2, in order to provide for backup, AS1 needs to
receive AS2's routes from both AS2 and its direct providers, and permits
their announcement to its direct providers. Similar configuration for
AS2. As presented in [3], the AS-based "local_pref" configuration is
sufficient to implement the routing requirements. It is not necessary
to use the MPP attribute.
However, the MPP attribute would simplify the implementation as shown in
the following.
Policy 1: Used solely as a backup link.
AS1 could simply configure higher MPP value for all nets in AS1 to be
announced to its direct provider. AS1 can either carry full routing
or only take partial routing (AS2's routes) from both its direct
provider and AS2, and configure default routes. Similar
configuration for AS2.
Policy 2: Used for traffic between AS1 and AS2, and as backup in general
AS with Policy 1, higher MPP values need to be configured for all
nets in AS1 to be announced to its direct provider. Then configure
proper AS-based "local_pref" value for AS2's routes. This is to
override the higher MPP value for AS2's routes received from the
direct provider. AS1 can either carry full routing or only take
Chen & Bates [Page 3]
INTERNET-DRAFT Application of MPP April 1995
partial routing (AS2's routes) from both its direct provider and AS2,
and configure default routes. Similar configuration for AS2.
2.3 An Entity with Multiple Direct Providers
This is where the MPP attribute would be most useful. As shown in
Figure 3, AS1 has two direct providers. X and Y are routes of AS1.
Note that AS1 could be an RSP.
+------+ +-----+ +------+
| ISP3 | | ISP | | ISP3 |
+------+ +-----+ +------+
/ \ / \ / \
/ (NAP) \ / \ / (NAP)\
+------+ +------+ +------+ +------+ +------+ +-----+
| ISP1 |------| ISP2 | | RSP1 | | RSP2 | | ISP1 |-----| ISP2|
+------+ +------+ +------+ +------+ +------+ +-----+
\ / \ / | |
\L1 /L2 \ / | |
+------+ +------+ +------+ +-----+
| AS1 | | AS1 | | RSP1 | | RSP2|
|X Y| |X Y| +------+ +-----+
+------+ +------+ \ /
\ /
+------+
| AS1 |
|X Y|
+------+
(a) (b) (c)
Figure 3
Policy 1: One link is used as primary, the other as pure backup
AS discussed in [3], the routing policy can be implemented by
coordinating the AS-based "local_pref" parameter with direct
providers. It is not necessary to use the MPP attribute.
However, the MPP attribute would simplify the implementation as
detailed in the following.
AS1 configure higher MPP value for all its routes when they are being
announced to the primary provider.
Chen & Bates [Page 4]
INTERNET-DRAFT Application of MPP April 1995
AS1 can either carry full routing or use default. If AS1 takes full
routing, then AS1 also need to configure AS-based "local_pref" so
that the primary path is preferred.
Policy 2: One link is used for traffic with the direct provider, as
backup in general
As with Policy 1, AS1 shall configure higher MPP value for all its
routes when they are being announced to the primary provider.
AS1 can be configured:
o either with partial routing (only routes of the direct providers
and their customers) and configure default routes with different
weights.
o or with full routing and configure AS-based "local_pref" values.
The AS-list would still need to be updated and maintained, as
discussed in [3].
Policy 3: Partial load-sharing among these links
That is, the direct link is used for traffic between AS1 and its
direct providers including its customers. However, the closest
exit point would be taken for traffic beyond these direct
providers and their customers.
AS1 shall categorize its networks into two categories (say X and
Y). Then, routes X shall be configured with higher MPP value when
they are being announced to one direct provider, and with lower
MPP values when they are being announced to the other direct
provider. Similar configuration for routes Y.
In addition, AS1 also need to configure AS-based "local_pref" so
that the direct link is taken between the AS and its direct
providers.
AS1 can take full routing. It can also take partial routing
(routes of direct providers and their customers), and configure
equal-weight default routes at its border routers and propagate
them into its AS.
Policy 4: Complete load-sharing among these links
That is, each network in AS1 sends packets to the closer (in terms
of internal route preference) border router that peers with a
Chen & Bates [Page 5]
INTERNET-DRAFT Application of MPP April 1995
direct providers. The return traffic is expected to take a sym-
metric path.
AS1 shall categorize its networks into two categories (say X and
Y). Then, routes X shall be configured with higher MPP value when
they are being announced to one direct provider, and with lower
MPP values when they are being announced to the other direct
provider. Similar configuration for route Y.
It is much simpler if AS1 does not take full routing. Then AS1
can configure default routes at its border routers and propagate
them into its AS (via iBGP).
If AS1 still prefers to take full routing, then routes received
from the direct providers need to have equal length of AS path.
It is still necessary for AS1 to manipulate the AS path. However,
the routes with their AS paths manipulated would not be propagated
upstream. That is, the propagation of the superfluous information
in the AS path would be limited to the AS and possibly its down-
stream ASs, rather than the whole Internet.
Chen & Bates [Page 6]
INTERNET-DRAFT Application of MPP April 1995
3. Configure Preference for Routes with the MPP Attribute
It is possible, although not common, that the MPP attribute has been
set by AS1, and AS2 desires further preference between its direct
providers. In such cases, AS2 can use the MPP attributes to do load
sharing for routes without the MPP attributes. However, AS2 shall
not include AS1's routes in the net-based load sharing with respect
to AS2's direct providers. Instead, AS2 shall coordinate with its
direct providers to configure the proper AS-based "local_pref" values
so that one provider is used as the primary, the other as the back,
for all of AS1's routes. This is to make sure that routing symmetry
is maintained for routing to AS1. If there are multiple ASs that
have configured the MPP attributes, then AS2 can perform load sharing
by distribute (on per-AS basis) routes evenly with respect to its
direct providers.
+------+
| ISP3 |
+------+
/ \
/ (NAP) \
+------+ +------+
| ISP1 |-----| ISP2 |
+------+ +------+
| / |
| / |
+------+ +------+
| RSP1 | | RSP2 |
|X Y| | |
+------+ +------+
\ /
\ /
+------+
| AS1 |
|W Z|
+------+
Figure 4
For example, in Figure 4, AS1 has two direct providers RSP1 and RSP2.
AS1 does load sharing by setting MPP attributes for routes W and Z.
RSP1 has direct providers ISP1 and ISP2, and wishes to do load shar-
ing.
RSP1 can use the MPP attributes to do load sharing for routes without
the MPP attributes.
Chen & Bates [Page 7]
INTERNET-DRAFT Application of MPP April 1995
For AS1's routes (such as W and Z) that are already configured with
the MPP attribute, RSP1 shall coordinate, with ISP1 or ISP2, to con-
figure the proper AS-based "local_pref" value so that one acts as
primary to reach routes of AS1. For instance, ISP1 configures lower
"local_pref" for AS1's routes so that the ISP1 - ISP2 link is pre-
ferred to reach AS1's routes. This would also ensure that ISP3 would
use ISP2 to reach AS1's routes.
It should be emphasized that when dealing with the complicated
topologies of Internet connections, one needs to take into account
of its internal network topology, its connection to direct providers
and to the major interconnection points. Coordination between
providers is strongly recommended.
4. Security Considerations
Security considerations are not discussed in this memo.
5. References
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995.
[2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro-
tocol in the Internet", RFC1772, March 1995.
[3] Chen, E., and Bates, T., "Analysis and Critique of the Current
Practice of Implementing Symmetric Routing in the Multi-Provider
Internet", INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-00.txt>,
April 1995.
[4] Chen, E., and Bates, T., "Multi-Provider Preference Attribute for
BGP", INTERNET-DRAFT, <draft-ietf-idr-bgp-mpp-00.txt>, April 1995.
Chen & Bates [Page 8]
INTERNET-DRAFT Application of MPP April 1995
6. Author's Addresses
Enke Chen
MCI
2100 Reston Parkway
Reston, VA 22094
phone: +1 703 715 7087
email: enke@mci.net
Tony Bates
MCI
2100 Reston Parkway
Reston, VA 22094
phone: +1 703 715 7521
email: Tony.Bates@mci.net
Chen & Bates [Page 9]
- Document 3: Symmetric Routing Tony Bates
- Re: Document 3: Symmetric Routing Sean Doran
- Re: Document 3: Symmetric Routing Curtis Villamizar
- Re: Document 3: Symmetric Routing Dennis Ferguson
- Re: Document 3: Symmetric Routing Enke Chen