idnits 2.17.1 draft-ietf-idr-bgp-dpa-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1996) is 10268 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 129, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 141, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 144, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1771 (ref. '1') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 1787 (ref. '6') Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Enke Chen 3 Tony Bates 4 Expires September 1996 MCI 5 March 1996 7 Destination Preference Attribute for BGP 8 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress". 23 Please check the I-D abstract listing contained in each Internet 24 Draft directory to learn the current status of this or any other 25 Internet Draft. 27 Abstract 29 The Border Gateway Protocol [1] is an inter-autonomous system routing 30 protocol designed for TCP/IP internets. 32 This document describes a new BGP path attribute termed "Destination 33 Preference Attribute" (DPA) which can be used by a single autonomous 34 system (AS) to specify globally transitive metrics in its routing 35 announcement via BGP. The metric can then be used by upstream BGP 36 speakers to favor certain path for return traffic. The application 37 of this attribute includes facilitating the implementation of 38 symmetric routing and load sharing in the multi-provider Internet. 40 Introduction 42 In certain cases there is a need for an autonomous system (AS) to 43 specify a globally transitive preference in its routing announcement 44 via BGP so that the upstream BGP speakers can use the preference to 45 favor certain path for return traffic. For instance, as discussed in 46 [3], currently it is difficult to implement symmetric routing and 47 load sharing in the multi-provider Internet due to the lack of this 48 preference in BGP. 50 In this paper, we propose a new BGP attribute termed "Destination 51 Preference Attribute" (DPA) to address such a need. More 52 specifically, the DPA is a globally transitive metric that can be 53 used by an AS to specify preference in its routing announcement so 54 that the return traffic favors certain path. As illustrated in [4] 55 through several examples, this metric, combined with AS-based 56 "LOCAL_PREF" offers much greater flexibility and manageability in 57 implementing symmetric inter-domain routing and load sharing in the 58 multi-provider Internet. 60 Destination Preference Attribute (DPA) 62 This document proposes the DPA path attribute, which is an optional 63 transitive attribute of fixed length. The attribute is represented 64 by a pair . The AS# is a two octet non-negative 65 integer, which denotes the AS that specifies the preference. The DPA 66 value is a four octet non-negative integer. 68 The DPA attribute has Type Code 11. 70 Route Selection Process 72 A router may use DPA to influence the degree of preference [1] 73 assigned to a route. 75 DPA influence on the computation of degree of preference is a local 76 matter. In general, a route with a higher DPA indicates a higher 77 preference by the originator of the DPA attribute. 79 Operation 81 The AS that sets this attribute must include its AS number in the 82 attribute. A BGP speaker may use the "LOCAL_PREF" attribute to 83 select a different path other than the one specified by the DPA 84 attribute value. This does not preclude an AS from re-setting this 85 attribute. However, coordination with the upstream and/or downstream 86 neighbors is strongly recommended. 88 Aggregation 90 If aggregation is done, the resultant aggregate shall be treated as a 91 new NLRI. No DPA attribute shall be derived from more specific NLRIs 92 which formed the aggregate. The resultant aggregate is free to have 93 the DPA attribute set if so desired. 95 Remarks 97 It is noted that this new BGP attribute is simple and requires little 98 change to the current practice and operation of BGP4. Nevertheless, 99 the new attribute would offer the flexibility of shifting more 100 influence on route selection to where the route originates, which has 101 become increasingly meaningful as the Internet becomes more complex 102 and dynamic. At the same time, the autonomy of an AS is preserved as 103 the "LOCAL_PREF" feature remains unchanged. A typical application of 104 this attribute is illustrated in [4] where the DPA attribute is used 105 to simplify the implementation of symmetric inter-domain routing and 106 load-sharing. 108 Applicability 110 The DPA path attribute may be used with BGP version 4 and all 111 subsequent versions of BGP unless specifically noted otherwise. 113 Security Considerations 115 Security considerations are not discussed in this memo. 117 Acknowledgments 119 The authors would like to thank Yakov Rekhter of cisco for his 120 insightful comments and suggestions. We also acknowledge Ramesh 121 Govindan (ISI), Paul Traina (cisco), and Ravi Chandra (cisco) for 122 their helpful comments. 124 References 126 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 127 RFC1771, March 1995. 129 [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway 130 Protocol in the Internet", RFC1772, March 1995. 132 [3] Chen, E., and Bates, T., "Current Practice of Implementing 133 Symmetric Routing and Load Sharing in the Multi-Provider Internet", 134 INTERNET-DRAFT, , January 135 1996. 137 [4] Chen, E., and Bates, T., "Application of the BGP Destination 138 Preference Attribute in Implementing Symmetric Routing", INTERNET- 139 DRAFT, , January 1996. 141 [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, , March 1995. 144 [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, 145 April 1995. 147 Author's Addresses 149 Enke Chen 150 MCI 151 2100 Reston Parkway 152 Reston, VA 22091 154 phone: +1 703 715 7087 155 email: enke@mci.net 157 Tony Bates 158 MCI 159 2100 Reston Parkway 160 Reston, VA 22091 162 phone: +1 703 715 7521 163 email: Tony.Bates@mci.net