draft-ietf-idr-bgp-dpa-03.txt   draft-ietf-idr-bgp-dpa-04.txt 
INTERNET-DRAFT Enke Chen INTERNET-DRAFT Enke Chen
<draft-ietf-idr-bgp-dpa-03.txt> Tony Bates <draft-ietf-idr-bgp-dpa-04.txt> Tony Bates
MCI Expires in six months MCI
November 1995 January 1996
Destination Preference Attribute for BGP Destination Preference Attribute for BGP
<draft-ietf-idr-bgp-dpa-03.txt> <draft-ietf-idr-bgp-dpa-04.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 16 skipping to change at page 2, line 16
[3], currently it is difficult to implement symmetric routing and [3], currently it is difficult to implement symmetric routing and
load sharing in the multi-provider Internet due to the lack of this load sharing in the multi-provider Internet due to the lack of this
preference in BGP. preference in BGP.
In this paper, we propose a new BGP attribute termed "Destination In this paper, we propose a new BGP attribute termed "Destination
Preference Attribute" (DPA) to address such a need. More Preference Attribute" (DPA) to address such a need. More
specifically, the DPA is a globally transitive metric that can be specifically, the DPA is a globally transitive metric that can be
used by an AS to specify preference in its routing announcement so used by an AS to specify preference in its routing announcement so
that the return traffic favors certain path. As illustrated in [4] that the return traffic favors certain path. As illustrated in [4]
through several examples, this metric, combined with AS-based through several examples, this metric, combined with AS-based
"local_pref" offers much greater flexibility and manageability in "LOCAL_PREF" offers much greater flexibility and manageability in
implementing symmetric inter-domain routing and load sharing in the implementing symmetric inter-domain routing and load sharing in the
multi-provider Internet. multi-provider Internet.
Destination Preference Attribute (DPA) Destination Preference Attribute (DPA)
This document proposes the DPA path attribute, which is an optional This document proposes the DPA path attribute, which is an optional
transitive attribute of fixed length. The attribute is represented transitive attribute of fixed length. The attribute is represented
by a pair <AS#, DPA value>. The AS# is a two octet non-negative by a pair <AS#, DPA value>. The AS# is a two octet non-negative
integer, which denotes the AS that specifies the preference. The DPA integer, which denotes the AS that specifies the preference. The DPA
value is a four octet non-negative integer. value is a four octet non-negative integer.
The DPA attribute has Type Code 11. The DPA attribute has Type Code 11.
Route Selection Process Route Selection Process
The DPA attributes are considered comparable only if the DPA The DPA attributes shall be used as a route selection criteria, after
attributes are present in all the routes being compared and are set the "LOCAL_PREF" attribute is evaluated, and before the evaluation of
by the same AS. the AS path length and the multi-exit-discriminator (MED) attribute.
However, if a route contains both MED and DPA attributes from the
The comparable DPA attributes shall be used as a route selection same neighboring AS, the MED values shall be favored over DPA values
criteria, after the "local_pref" attribute is evaluated, and before for route selection.
the evaluation of the AS path length and the multi-exit-discriminator
(MED) attribute. However, if a route contains both MED and comparable
DPA attributes from the same neighboring AS, the MED values shall be
favored over DPA values for route selection.
Non-comparable DPA attributes shall not be used in the route
selection process.
The higher the DPA attribute value, the more preferred the route. The higher the DPA attribute value, the more preferred the route.
A route with missing DPA attribute must be treated as having an DPA
attribute with value zero.
Operation Operation
The AS that sets this attribute must include its AS number in the The AS that sets this attribute must include its AS number in the
attribute. A BGP speaker may use the "local_pref" attribute to attribute. A BGP speaker may use the "LOCAL_PREF" attribute to
select a different path other than the one specified by the DPA select a different path other than the one specified by the DPA
attribute value. This does not preclude an AS from re-setting this attribute value. This does not preclude an AS from re-setting this
attribute. However, coordination with the upstream and/or downstream attribute. However, coordination with the upstream and/or downstream
neighbors is strongly recommended. neighbors is strongly recommended.
To make sure that the MED attribute and not the DPA attribute is used To make sure that the MED attribute and not the DPA attribute is used
in the selection of routes from multiple peers of the same in the selection of routes from multiple peers of the same
neighboring AS, the DPA value, if set, must be identical for all neighboring AS, the DPA value, if set, must be identical for all
peers with the same neighboring AS. It is an operational matter to peers with the same neighboring AS. It is an operational matter to
ensure the correct setting of the DPA value for multiple peers to the ensure the correct setting of the DPA value for multiple peers to the
skipping to change at page 3, line 36 skipping to change at page 3, line 36
the DPA attribute set if so desired. the DPA attribute set if so desired.
Remarks Remarks
It is noted that this new BGP attribute is simple and requires little It is noted that this new BGP attribute is simple and requires little
change to the current practice and operation of BGP4. Nevertheless, change to the current practice and operation of BGP4. Nevertheless,
the new attribute would offer the flexibility of shifting more the new attribute would offer the flexibility of shifting more
influence on route selection to where the route originates, which has influence on route selection to where the route originates, which has
become increasingly meaningful as the Internet becomes more complex become increasingly meaningful as the Internet becomes more complex
and dynamic. At the same time, the autonomy of an AS is preserved as and dynamic. At the same time, the autonomy of an AS is preserved as
the "local_pref" feature remains unchanged. A typical application of the "LOCAL_PREF" feature remains unchanged. A typical application of
this attribute is illustrated in [4] where the DPA attribute is used this attribute is illustrated in [4] where the DPA attribute is used
to simplify the implementation of symmetric inter-domain routing and to simplify the implementation of symmetric inter-domain routing and
load-sharing. load-sharing.
Applicability Applicability
The DPA path attribute may be used with BGP version 4 and all The DPA path attribute may be used with BGP version 4 and all
subsequent versions of BGP unless specifically noted otherwise. subsequent versions of BGP unless specifically noted otherwise.
Security Considerations Security Considerations
skipping to change at page 4, line 21 skipping to change at page 4, line 21
References 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 [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway
Protocol in the Internet", RFC1772, March 1995. Protocol in the Internet", RFC1772, March 1995.
[3] Chen, E., and Bates, T., "Current Practice of Implementing [3] Chen, E., and Bates, T., "Current Practice of Implementing
Symmetric Routing and Load Sharing in the Multi-Provider Internet", Symmetric Routing and Load Sharing in the Multi-Provider Internet",
INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-01.txt>, June 1995. INTERNET-DRAFT, <draft-ietf-idr-symm-multi-prov-02.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.
Author's Addresses Author's Addresses
Enke Chen Enke Chen
 End of changes. 

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