draft-ietf-idr-symm-multi-prov-01.txt   draft-ietf-idr-symm-multi-prov-02.txt 
INTERNET-DRAFT Enke Chen INTERNET-DRAFT Enke Chen
<draft-ietf-idr-symm-multi-prov-01.txt> Tony Bates <draft-ietf-idr-symm-multi-prov-02.txt> Tony Bates
Expires in six months MCI MCI
June 1995 January 1996
Expires in six months
Current Practice of Implementing Current Practice of Implementing
Symmetric Routing and Load Sharing Symmetric Routing and Load Sharing
in the Multi-Provider Internet in the Multi-Provider Internet
<draft-ietf-idr-symm-multi-prov-01.txt> <draft-ietf-idr-symm-multi-prov-02.txt>
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
skipping to change at page 4, line 45 skipping to change at page 4, line 45
In all cases of Figure 2, in order to provide for backup, AS1 shall In all cases of Figure 2, in order to provide for backup, AS1 shall
permit the acceptance of AS2's routes from both AS2 and AS1's direct permit the acceptance of AS2's routes from both AS2 and AS1's direct
provider, and permit their announcements to its direct providers. provider, and permit their announcements to its direct providers.
Similar configuration is required for AS2. Similar configuration is required for AS2.
There are two common routing policies depending upon how the link There are two common routing policies depending upon how the link
between AS1 and AS2 is used. between AS1 and AS2 is used.
Policy 1: Used solely as a backup link Policy 1: Used solely as a backup link
The routing policy can be implemented by coordinating AS-based The routing policy can be implemented by coordinating "LOCAL_PREF"
"local_pref" values between neighboring ASs. values between neighboring ASs. This can be acheived using AS-
based configuration or comunity based configuration [8].
In all cases of Figure 2, the "local_pref" value for the peer of In all cases of Figure 2, the "LOCAL_PREF" value for the peer of
AS1 or AS2 with its direct provider shall be higher than that for AS1 or AS2 with its direct provider shall be higher than that for
the peer between AS1 and AS2. Either full routing or partial the peer between AS1 and AS2. Either full routing or partial
routing can be configured. routing can be configured.
For example, in Figure 2(a), AS1 can take full routing from ISP For example, in Figure 2(a), AS1 can take full routing from ISP
and AS2. An alternative is for AS1 to take only AS2's routes and AS2. An alternative is for AS1 to take only AS2's routes
from ISP and AS2, and configure default routes (with different from ISP and AS2, and configure default routes (with different
weights) at its border routers and then propagate them into its weights) at its border routers and then propagate them into its
own AS (via, e.g., iBGP). The ISP needs to make sure that the own AS (via, e.g., iBGP). The ISP needs to make sure that the
"local_pref" values are equal for the peers with AS1 and AS2 so "LOCAL_PREF" values are equal for the peers with AS1 and AS2 so
that the shorter AS-path would be selected. that the shorter AS-path would be selected.
Policy 2: Used for traffic between AS1 and AS2, and as backup in gen- Policy 2: Used for traffic between AS1 and AS2, and as backup in gen-
eral eral
In general this routing policy can be implemented by coordinating In general this routing policy can be implemented by coordinating
AS-based "local_pref" values among the neighboring ASs and direct "LOCAL_PREF" values [8] among the neighboring ASs and direct
providers. providers.
In Figure 2(a), equal "local_pref" values could be configured for In Figure 2(a), equal "LOCAL_PREF" values could be configured for
all the peers. Then the length of AS path would be used as tie- all the peers. Then the length of AS path would be used as tie-
breaker in the route selection. AS1 can either take full routing breaker in the route selection. AS1 can either take full routing
from AS2 and its direct provider. It can also choose to take only from AS2 and its direct provider. It can also choose to take only
AS2's routes from its direct provider and AS2, and configure AS2's routes from its direct provider and AS2, and configure
default routes (with a different weights) at its border routers default routes (with a different weights) at its border routers
and then propagate them into its own AS (via, e.g., iBGP). Simi- and then propagate them into its own AS (via, e.g., iBGP). Simi-
lar configuration for AS2. lar configuration for AS2.
In Figures 2(b)-(c), AS1 can either take full routing from AS2 and In Figures 2(b)-(c), AS1 can either take full routing from AS2 and
its direct provider, and configure the "local_pref" parameter so its direct provider, and configure the "LOCAL_PREF" parameter so
that traffic to AS2 prefers the AS1 - AS2 link over the link to that traffic to AS2 prefers the AS1 - AS2 link over the link to
its direct provider. AS1 can choose to take only AS2's routes from its direct provider. AS1 can choose to take only AS2's routes from
its direct provider and AS2, and configure default routes (with its direct provider and AS2, and configure default routes (with
different weight) at its border routers and then propagate them different weight) at its border routers and then propagate them
into its own AS (via, e.g., iBGP). Similar configuration for AS2. into its own AS (via, e.g., iBGP). Similar configuration for AS2.
AS1's direct provider (and possible its ISP) needs to configure AS1's direct provider (and possible its ISP) needs to configure
the "local_pref" parameter so that traffic to AS2 does not prefer the "LOCAL_PREF" parameter so that traffic to AS2 does not prefer
the link to AS1. Similar configuration is required for AS2's the link to AS1. Similar configuration is required for AS2's
direct provider. direct provider.
2.3 An Entity with Multiple Direct Providers 2.3 An Entity with Multiple Direct Providers
As shown in Figure 3, AS1 has two direct providers. X and Y are As shown in Figure 3, AS1 has two direct providers. X and Y are
routes of AS1. Note that AS1 could be an RSP. routes of AS1. Note that AS1 could be an RSP.
+------+ +-----+ +------+ +------+ +-----+ +------+
| ISP3 | | ISP | | ISP3 | | ISP3 | | ISP | | ISP3 |
skipping to change at page 6, line 43 skipping to change at page 6, line 43
Depending upon the quality of these links and the internal network Depending upon the quality of these links and the internal network
topology of the AS, there are several common routing policies. topology of the AS, there are several common routing policies.
Policy 1: One link is used as primary, the other as pure backup Policy 1: One link is used as primary, the other as pure backup
This policy is common when the quality of these links differ dra- This policy is common when the quality of these links differ dra-
matically. matically.
This policy can be implemented by coordinating AS-based This policy can be implemented by coordinating AS-based
"local_pref" values between the entity and its direct providers. "LOCAL_PREF" values between the entity and its direct providers.
The AS can either take full routing or use default routes. In the The AS can either take full routing or use default routes. In the
case of default, each border router can configure a default route case of default, each border router can configure a default route
and then propagate it into the AS (via, e.g., iBGP). and then propagate it into the AS (via, e.g., iBGP).
Policy 2: Each link is used for traffic with the respective direct Policy 2: Each link is used for traffic with the respective direct
provider. In general one link is used as primary, and the other as provider. In general one link is used as primary, and the other as
backup. backup.
If the traffic between AS1 and its direct providers (and their If the traffic between AS1 and its direct providers (and their
customers) shall take the direct link, AS1 needs to be configured: customers) shall take the direct link, AS1 needs to be configured:
o either with partial routing (only routes of the direct o either with partial routing (only routes of the direct
providers and their customers) and defaults with different providers and their customers) and defaults with different
weights. weights.
o or with full routing and configure AS-based "local_pref" val- o or with full routing and configure "LOCAL_PREF" values.
ues.
The difficulty is that the indirect providers (e.g., ISP3 in The difficulty is that the indirect providers (e.g., ISP3 in
Figure 3(a)) may have to be involved to achieve symmetric rout- Figure 3(a)) may have to be involved to achieve symmetric rout-
ing. More specifically, ing. More specifically,
o In Figure 3(a), ISP3 would receive routes X and Y from both o In Figure 3(a), ISP3 would receive routes X and Y from both
ISP1 and ISP2 with identical length of AS paths. In order ISP1 and ISP2 with identical length of AS paths. In order
for L1 to be favored by ISP3 to AS1, ISP1 would need to for L1 to be favored by ISP3 to AS1, ISP1 would need to
manipulate the AS-path length, which is discussed in Section manipulate the AS-path length, which is discussed in Section
3.1. Another approach is for ISP3 to configure AS-based 3.1. Another approach is for ISP3 to configure "LOCAL_PREF"
"local_pref" parameter, which certainly does not scale well parameter, which certainly does not scale well as there are
as there are many ISPs at an NAP. In addition, it is almost many ISPs at an NAP. In addition, it is almost impossible to
impossible to do as AS1 is not a customer of ISP3. do as AS1 is not a customer of ISP3.
o In Figure 3(b), ISP would receive routes X and Y from both o In Figure 3(b), ISP would receive routes X and Y from both
RSP1 and RSP2 with identical length of AS paths. Either RSP1 RSP1 and RSP2 with identical length of AS paths. Either RSP1
needs to manipulate the AS-path length, or ISP needs to con- needs to manipulate the AS-path length, or ISP needs to con-
figure AS-based "local_pref" parameter. figure "LOCAL_PREF" parameter.
o In Figure 3(c), ISP1 would receive routes X and Y from both o In Figure 3(c), ISP1 would receive routes X and Y from both
RSP1 and ISP2. In order for traffic from ISP1 to AS1 to RSP1 and ISP2. In order for traffic from ISP1 to AS1 to
favor the ISP1 - ISP2 link, either RSP1 needs to manipulate favor the ISP1 - ISP2 link, either RSP1 needs to manipulate
the AS-path length, or ISP1 needs to configure AS-based the AS-path length, or ISP1 needs to configure "LOCAL_PREF"
"local_pref" parameter. parameter.
Another problem is that it is difficult for AS1 to implement Another problem is that it is difficult for AS1 to implement
"full routing", as AS1 needs to update the AS list for the "full routing", as AS1 needs to update the AS list for the
"local_pref" parameter each time its direct providers acquire a "LOCAL_PREF" parameter each time its direct providers acquire a
new AS as a customer. Nevertheless, some entities still prefer new AS as a customer. Nevertheless, some entities still prefer
full routing. full routing.
Policy 3: Partial load-sharing among these links Policy 3: Partial load-sharing among these links
That is, the direct link is used for traffic between AS1 and its That is, the direct link is used for traffic between AS1 and its
direct providers including its customers. However, the closest direct providers including its customers. However, the closest
exit point would be taken for traffic beyond these direct exit point would be taken for traffic beyond these direct
providers and their customers. For example, in Figure 3(a) traffic providers and their customers. For example, in Figure 3(a) traffic
between AS1 and ISP1 (and its customers) would use the direct link between AS1 and ISP1 (and its customers) would use the direct link
skipping to change at page 9, line 24 skipping to change at page 9, line 21
routes and prepends an AS number (either its own AS or a different AS routes and prepends an AS number (either its own AS or a different AS
number): number):
AS1 Prepend AS Path AS1 Prepend AS Path
Route To ISP1 To ISP2 ISP1 ISP2 Route To ISP1 To ISP2 ISP1 ISP2
===== ======= ======= ======= ====== ===== ======= ======= ======= ======
X AS1 AS1 AS1 AS1 X AS1 AS1 AS1 AS1
Y AS1 AS1 AS1 AS1 Y AS1 AS1 AS1 AS1
In general the different AS paths can be used by ISP1 and ISP2 to In general the different AS paths can be used by ISP1 and ISP2 to
configure AS-based "local_pref" values to implement the desired rout- configure AS-based "LOCAL_PREF" values to implement the desired rout-
ing policy. The "local_pref" configuration would not be necessary if ing policy. The "LOCAL_PREF" configuration would not be necessary if
there are sufficient number of ASs inserted. there are sufficient number of ASs inserted.
With this approach the AS that originates the preference has full With this approach the AS that originates the preference has full
control, and only that AS needs to manipulate the AS path on a per- control, and only that AS needs to manipulate the AS path on a per-
route basis. route basis.
The drawbacks of this approach includes: The drawbacks of this approach includes:
o It extends the AS path with superfluous information. In par- o It extends the AS path with superfluous information. In par-
ticular, the superfluous information in the AS path would be ticular, the superfluous information in the AS path would be
skipping to change at page 10, line 48 skipping to change at page 10, line 45
with ISP2. with ISP2.
This approach requires NRLI-based customization with the direct This approach requires NRLI-based customization with the direct
providers and sometimes indirect providers as well as the originating providers and sometimes indirect providers as well as the originating
AS. The NSFNET configuration experience has shown that this approach AS. The NSFNET configuration experience has shown that this approach
requires non-trivial administrative coordination and full topology requires non-trivial administrative coordination and full topology
information. In addition, it places a burden on routers with limited information. In addition, it places a burden on routers with limited
memory capacity. For these reasons, the NLRI-based preference con- memory capacity. For these reasons, the NLRI-based preference con-
figuration should be avoided at the provider level if possible. figuration should be avoided at the provider level if possible.
Instead, such a configuration should be pushed as close to the origi- Instead, such a configuration should be pushed as close to the origi-
nating AS as possible. nating AS as possible. The technique presented in [8] makes use of
the BGP community attribute to allow one to acheive NLRI based
LOCAL_PREF configuration without provider level customization.
3.4 Perfect Aggregation and Addressing 3.4 Perfect Aggregation and Addressing
In the cases that all routes in the AS are covered by an aggregate In the cases that all routes in the AS are covered by an aggregate
and address assignment is completely consistent with the network and address assignment is completely consistent with the network
topology, the rule of the longest prefix match can be used to help topology, the rule of the longest prefix match can be used to help
achieve routing symmetry and load sharing. That is, a portion of the achieve routing symmetry and load sharing. That is, a portion of the
aggregate, along with the aggregate itself, can be announced to one aggregate, along with the aggregate itself, can be announced to one
direct provider. The remaining portion of the aggregate, along with direct provider. The remaining portion of the aggregate, along with
the aggregate itself, can be announced to the other direct provider. the aggregate itself, can be announced to the other direct provider.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
tantly, the requirement of this approach is not likely to be met in tantly, the requirement of this approach is not likely to be met in
practice. So, this approach is listed just for the sake of complete- practice. So, this approach is listed just for the sake of complete-
ness. ness.
4. Discussion 4. Discussion
As has been illustrated in Section 3, it is not easy to implement As has been illustrated in Section 3, it is not easy to implement
routing symmetry and load sharing for an entity with multiple direct routing symmetry and load sharing for an entity with multiple direct
providers using the current functionality of BGP. There are many providers using the current functionality of BGP. There are many
drawbacks with the current practice of implementation. Even the drawbacks with the current practice of implementation. Even the
implementation of the AS-based "local_pref" parameter can sometimes implementation of the AS-based "LOCAL_PREF" parameter can sometimes
be quite involved. The difficulty is caused by the lack of a glob- be quite involved. The difficulty is caused by the lack of a glob-
ally transitive preference an AS (with multiple direct providers) can ally transitive preference an AS (with multiple direct providers) can
specify, and be used in the route selection process. specify, and be used in the route selection process.
A new BGP attribute termed "Destination Preference Attribute" (DPA) A new BGP attribute termed "Destination Preference Attribute" (DPA)
has been proposed in [3] to address such need. As illustrated in has been proposed in [3] to address such need. As illustrated in
[4], the routing policies presented in Section 2 can be implemented [4], the routing policies presented in Section 2 can be implemented
with ease by using the DPA attribute. In particular, only the AS with ease by using the DPA attribute. In particular, only the AS
that originates this preference needs to specify this preference on a that originates this preference needs to specify this preference on a
per-route basis. per-route basis.
skipping to change at page 12, line 14 skipping to change at page 12, line 14
7. References 7. References
[1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC1771, March 1995. RFC1771, March 1995.
[2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro- [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway Pro-
tocol in the Internet", RFC1772, March 1995. tocol in the Internet", RFC1772, March 1995.
[3] Chen, E., and Bates, T., "Destination Preference Attribute for [3] Chen, E., and Bates, T., "Destination Preference Attribute for
BGP", INTERNET-DRAFT, <draft-ietf-idr-bgp-dpa-01.txt>, June 1995. BGP", INTERNET-DRAFT, <draft-ietf-idr-bgp-dpa-04.txt>, January 1996.
[4] Chen, E., and Bates, T., "Application of the BGP Destination [4] Chen, E., and Bates, T., "Application of the BGP Destination
Preference Attribute in Implementing Symmetric Routing", INTERNET- Preference Attribute in Implementing Symmetric Routing", INTERNET-
DRAFT, <draft-ietf-idr-dpa-application-01.txt>, June 1995. DRAFT, <draft-ietf-idr-dpa-application-02.txt>, January 1996.
[5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, <draft-ietf- [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, <draft-ietf-
idr-bgp-metrics-00.txt>, March 1995. idr-bgp-metrics-00.txt>, March 1995.
[6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787,
April 1995. April 1995.
[7] Hawkinsin, J., and Bates, T., "Guidelines for creation, selec- [7] Hawkinsin, J., and Bates, T., "Guidelines for creation, selec-
tion, and registration of an Autonomous System (AS)", INTERNET-DRAFT, tion, and registration of an Autonomous System (AS)", INTERNET-DRAFT,
<draft-ietf-idr-autosys-guide-03.txt>, May 1995. <draft-ietf-idr-autosys-guide-04.txt>, December 1995.
[8] Chen, E., and Bates, T., "An Application of the BGP Community
Attribute in Multi-home Routing", INTERNET-DRAFT, <draft-chen-
community-usage-00.txt>, January 1996.
8. Author's Addresses 8. Author's Addresses
Enke Chen Enke Chen
MCI MCI
2100 Reston Parkway 2100 Reston Parkway
Reston, VA 22091 Reston, VA 22091
phone: +1 703 715 7087 phone: +1 703 715 7087
email: enke@mci.net email: enke@mci.net
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/