draft-ietf-idr-dpa-application-01.txt   draft-ietf-idr-dpa-application-02.txt 
INTERNET-DRAFT Enke Chen INTERNET-DRAFT Enke Chen
<draft-ietf-idr-dpa-application-01.txt> Tony Bates <draft-ietf-idr-dpa-application-02.txt> Tony Bates
Expires in six months MCI Expires in six months MCI
June 1995 January 1996
Application of the BGP Destination Preference Attribute Application of the BGP Destination Preference Attribute
in Implementing Symmetric Routing in Implementing Symmetric Routing
<draft-ietf-idr-dpa-application-01.txt> <draft-ietf-idr-dpa-application-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 2, line 7 skipping to change at page 2, line 6
The Destination Preference Attribute (DPA) is proposed in [4] for The Destination Preference Attribute (DPA) is proposed in [4] for
BGP. This attribute can be used by an autonomous system (AS) to BGP. This attribute can be used by an autonomous system (AS) to
specify a globally transitive preference in its routing announcement specify a globally transitive preference in its routing announcement
via BGP so that the upstream BGP speakers can use the preference to via BGP so that the upstream BGP speakers can use the preference to
favor certain path for return traffic. This paper presents a typical favor certain path for return traffic. This paper presents a typical
application of this attribute. It illustrates how the DPA attribute application of this attribute. It illustrates how the DPA attribute
facilitates the implementation of symmetric inter-domain routing and facilitates the implementation of symmetric inter-domain routing and
load-sharing for the the typical cases presented in [3]. load-sharing for the the typical cases presented in [3].
This paper assumes that in general an ISP treats other ISPs equally This paper assumes that in general an ISP treats other ISPs equally
(in terms of the "local_pref" parameter) in the route selection (in terms of the "LOCAL_PREF" parameter) in the route selection
process. It also assumes the following order of preference is process. It also assumes the following order of preference is
followed for the purpose of route selection: first the "local_pref" followed for the purpose of route selection: first the "LOCAL_PREF"
parameter, followed by the DPA attribute, the shortest AS-path, the parameter, followed by the DPA attribute, the shortest AS-path, the
MED and the IGP metric. MED and the IGP metric.
2. Application of the DPA Attribute 2. Application of the DPA Attribute
In [3] we present several typical topologies of Internet connections, In [3] we present several typical topologies of Internet connections,
their inter-domain routing requirements, and the current practice to their inter-domain routing requirements, and the current practice to
implement these routing policies. This section illustrates how the implement these routing policies. This section illustrates how the
DPA attribute can be used to facilitate the implementation. DPA attribute can be used to facilitate the implementation.
skipping to change at page 3, line 31 skipping to change at page 3, line 31
| AS1 |------| AS2 | | AS1 |------| AS2 |
+------+ +------+ +------+ +------+
(a) (b) (c) (a) (b) (c)
Figure 2 Figure 2
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
providers, and permits their announcement to its direct providers. providers, and permits their announcement to its direct providers.
Similar configuration for AS2. As presented in [3], the AS-based Similar configuration for AS2. As presented in [3], the "LOCAL_PREF"
"local_pref" configuration is sufficient to implement the routing configuration is sufficient to implement the routing requirements.
requirements. It is not necessary to use the DPA attribute. It is not necessary to use the DPA attribute.
However, the DPA attribute would simplify the implementation as shown However, the DPA attribute would simplify the implementation as shown
in the following. in the following.
Policy 1: Used solely as a backup link. Policy 1: Used solely as a backup link.
AS1 can simply announce all its routes with a higher DPA value to AS1 can simply announce all its routes with a higher DPA value to
its direct provider, and with a lower DPA value to AS2. AS1 can its direct provider, and with a lower DPA value to AS2. AS1 can
either carry full routing or only take partial routing (AS2's either carry full routing or only take partial routing (AS2's
routes) from both its direct provider and AS2, and configure routes) from both its direct provider and AS2, and configure
default routes. Similar configuration for AS2. default routes. Similar configuration for AS2.
Policy 2: Used for traffic between AS1 and AS2, and as backup in Policy 2: Used for traffic between AS1 and AS2, and as backup in
general general
As with Policy 1, AS1 can simply announce all its routes with a As with Policy 1, AS1 can simply announce all its routes with a
higher DPA value to its direct provider, and with a lower DPA higher DPA value to its direct provider, and with a lower DPA
value to AS2. AS1 also needs to configure proper AS-based value to AS2. AS1 also needs to configure proper "LOCAL_PREF"
"local_pref" value for AS2's routes. This is to override the value for AS2's routes. This is to override the higher DPA value
higher DPA value for AS2's routes received from the direct for AS2's routes received from the direct provider. AS1 can
provider. AS1 can either carry full routing or only take partial either carry full routing or only take partial routing (AS2's
routing (AS2's routes) from both its direct provider and AS2, and routes) from both its direct provider and AS2, and configure
configure default routes. Similar configuration for AS2. default routes. Similar configuration for AS2.
2.3 An Entity with Multiple Direct Providers 2.3 An Entity with Multiple Direct Providers
This is where the DPA attribute would be most useful. As shown in This is where the DPA attribute would be most useful. As shown in
Figure 3, AS1 has two direct providers. X and Y are routes of AS1. Figure 3, AS1 has two direct providers. X and Y are routes of AS1.
Note that AS1 could be an RSP. Note that AS1 could be an RSP.
+------+ +-----+ +------+ +------+ +-----+ +------+
| ISP3 | | ISP | | ISP3 | | ISP3 | | ISP | | ISP3 |
+------+ +-----+ +------+ +------+ +-----+ +------+
skipping to change at page 4, line 44 skipping to change at page 4, line 44
|X Y| |X Y|
+------+ +------+
(a) (b) (c) (a) (b) (c)
Figure 3 Figure 3
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
AS discussed in [3], the routing policy can be implemented by AS discussed in [3], the routing policy can be implemented by
coordinating the AS-based "local_pref" parameter with direct coordinating the "LOCAL_PREF" parameter with direct providers. It
providers. It is not necessary to use the DPA attribute. is not necessary to use the DPA attribute.
However, the DPA attribute would simplify the implementation as However, the DPA attribute would simplify the implementation as
detailed in the following. detailed in the following.
AS1 can simply announce all its routes with a higher DPA value to AS1 can simply announce all its routes with a higher DPA value to
the primary provider, and with a lower DPA value to the other the primary provider, and with a lower DPA value to the other
provider. provider.
AS1 can either carry full routing or use default. If AS1 takes AS1 can either carry full routing or use default. If AS1 takes
full routing, then AS1 also need to configure AS-based full routing, then AS1 also need to configure "LOCAL_PREF" so that
"local_pref" so that the primary path is preferred. the primary path is preferred.
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, the other as provider. In general one link is used as primary, the other as
backup. backup.
As with Policy 1, AS1 can simply announce all its routes with a As with Policy 1, AS1 can simply announce all its routes with a
higher DPA value to the primary provider, and with a lower DPA higher DPA value to the primary provider, and with a lower DPA
value to the other provider. value to the other provider.
AS1 can be configured: AS1 can 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 configure default routes providers and their customers) and configure default routes
with different weights. with different weights.
o or with full routing and configure AS-based "local_pref" val- o or with full routing and configure "LOCAL_PREF" values. The
ues. The AS-list would still need to be updated and main- AS-list would still need to be updated and maintained, as
tained, as discussed in [3]. discussed in [3].
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. providers and their customers.
AS1 shall categorize its networks into two categories (say X and AS1 shall categorize its networks into two categories (say X and
Y). Then, X routes shall be configured with higher DPA value when Y). Then, X routes shall be configured with higher DPA value when
they are being announced to one direct provider, and with lower they are being announced to one direct provider, and with lower
DPA values when they are being announced to the other direct DPA values when they are being announced to the other direct
provider. Similar configuration for Y routes. provider. Similar configuration for Y routes.
In addition, AS1 also needs to configure AS-based "local_pref" so In addition, AS1 also needs to configure "LOCAL_PREF" so that the
that the direct link is taken between the AS and its direct direct link is taken between the AS and its direct providers.
providers.
AS1 can take full routing. It can also take partial routing AS1 can take full routing. It can also take partial routing
(routes of direct providers and their customers), and configure (routes of direct providers and their customers), and configure
equal-weight default routes at its border routers and propagate equal-weight default routes at its border routers and propagate
them into its AS. them into its AS.
Policy 4: Complete load-sharing among these links Policy 4: Complete load-sharing among these links
That is, each network in AS1 sends packets to the closer (in terms That is, each network in AS1 sends packets to the closer (in terms
of internal route preference) border router that peers with a of internal route preference) border router that peers with a
skipping to change at page 6, line 40 skipping to change at page 6, line 40
3. Configure Preference for Routes with the DPA Attribute 3. Configure Preference for Routes with the DPA Attribute
It is possible, although not common, that the DPA attribute has been It is possible, although not common, that the DPA attribute has been
set by one AS (say AS1), and another AS (say AS2) desires further set by one AS (say AS1), and another AS (say AS2) desires further
preference between its direct providers. The following options are preference between its direct providers. The following options are
available for AS2: available for AS2:
(1) AS2 uses the DPA attributes to do load sharing for routes other (1) AS2 uses the DPA attributes to do load sharing for routes other
than AS1's. That is, AS2 does not include AS1's routes in load shar- than AS1's. That is, AS2 does not include AS1's routes in load shar-
ing with respect to AS2's direct providers. Instead, AS2 can coordi- ing with respect to AS2's direct providers. Instead, AS2 can coordi-
nate with its direct providers to configure the proper AS-based nate with its direct providers to configure the proper "LOCAL_PREF"
"local_pref" values so that one provider is used as the primary, the values so that one provider is used as the primary, the other as the
other as the backup, for all of AS1's routes. This is to make sure backup, for all of AS1's routes. This is to make sure that routing
that routing symmetry is maintained for routing to AS1. If there are symmetry is maintained for routing to AS1. If there are multiple ASs
multiple ASs that have configured the DPA attributes, then AS2 can that have configured the DPA attributes, then AS2 can perform load
perform load sharing by distribute (on per-AS basis) routes evenly sharing by distribute (on per-AS basis) routes evenly with respect to
with respect to its direct providers. its direct providers.
(2) AS1 chooses to re-set the DPA attribute for route announcements (2) AS1 chooses to re-set the DPA attribute for route announcements
including AS1's routes. This may well cause the DPA attributes set including AS1's routes. This may well cause the DPA attributes set
by AS1 not to be used by upstream BGP speakers (due to non-comparable by AS1 not to be used by upstream BGP speakers (due to non-comparable
DPA attributes). DPA attributes).
In many cases, Option (1) is probably preferred. However, Option (1) In many cases, Option (1) is probably preferred. However, Option (1)
may not be able to maintain routing symmetry, either. It should be may not be able to maintain routing symmetry, either. It should be
emphasized that when dealing with the complicated topologies of emphasized that when dealing with the complicated topologies of
Internet connections, one needs to take into account its internal Internet connections, one needs to take into account its internal
skipping to change at page 7, line 44 skipping to change at page 7, line 44
+------+ +------+
| AS1 | | AS1 |
|W Z| |W Z|
+------+ +------+
Figure 4 Figure 4
In this example, RSP1 can use the DPA attributes to do load sharing In this example, RSP1 can use the DPA attributes to do load sharing
for routes without the DPA attributes. For AS1's routes (such as W for routes without the DPA attributes. For AS1's routes (such as W
and Z) that are already configured with the DPA attribute, RSP1 can and Z) that are already configured with the DPA attribute, RSP1 can
coordinate, with ISP1 or ISP2, to configure the proper AS-based coordinate, with ISP1 or ISP2, to configure the proper "LOCAL_PREF"
"local_pref" value so that one acts as primary to reach routes of value so that one acts as primary to reach routes of AS1. For
AS1. For instance, ISP1 configures lower AS-based "local_pref" value instance, ISP1 configures lower "LOCAL_PREF" value for all of AS1's
for all of AS1's routes so that the ISP1 - ISP2 link is preferred to routes so that the ISP1 - ISP2 link is preferred to reach AS1's
reach AS1's routes. This would also ensure that ISP3 would use ISP2 routes. This would also ensure that ISP3 would use ISP2 to reach
to reach AS1's routes. AS1's routes.
4. Security Considerations 4. Security Considerations
Security considerations are not discussed in this memo. Security considerations are not discussed in this memo.
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Yakov Rekhter of Cisco for his help- The authors would like to thank Yakov Rekhter of Cisco for his help-
ful comments and suggestions. ful comments and suggestions.
6. References 6. 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., "Analysis and Critique of the Current [3] Chen, E., and Bates, T., "Current Practice of Implementing Sym-
Practice of Implementing Symmetric Routing in the Multi-Provider metric Routing and Load Sharing in the Multi-Provider Internet",
Internet", INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-01.txt>, INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-02.txt>, January
June 1995. 1996.
[4] Chen, E., and Bates, T., "Destination Preference Attribute for [4] 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.
6. Author's Addresses 6. 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/