idnits 2.17.1 draft-ietf-idr-bgp-dpa-03.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-03-28) 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 (November 1995) is 10361 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 144, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 155, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 158, 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 MCI 5 November 1995 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 The DPA attributes are considered comparable only if the DPA 73 attributes are present in all the routes being compared and are set 74 by the same AS. 76 The comparable DPA attributes shall be used as a route selection 77 criteria, after the "local_pref" attribute is evaluated, and before 78 the evaluation of the AS path length and the multi-exit-discriminator 79 (MED) attribute. However, if a route contains both MED and comparable 80 DPA attributes from the same neighboring AS, the MED values shall be 81 favored over DPA values for route selection. 83 Non-comparable DPA attributes shall not be used in the route 84 selection process. 86 The higher the DPA attribute value, the more preferred the route. 88 Operation 90 The AS that sets this attribute must include its AS number in the 91 attribute. A BGP speaker may use the "local_pref" attribute to 92 select a different path other than the one specified by the DPA 93 attribute value. This does not preclude an AS from re-setting this 94 attribute. However, coordination with the upstream and/or downstream 95 neighbors is strongly recommended. 97 To make sure that the MED attribute and not the DPA attribute is used 98 in the selection of routes from multiple peers of the same 99 neighboring AS, the DPA value, if set, must be identical for all 100 peers with the same neighboring AS. It is an operational matter to 101 ensure the correct setting of the DPA value for multiple peers to the 102 same neighboring AS. 104 Aggregation 106 If aggregation is done, the resultant aggregate shall be treated as a 107 new NLRI. No DPA attribute shall be derived from more specific NLRIs 108 which formed the aggregate. The resultant aggregate is free to have 109 the DPA attribute set if so desired. 111 Remarks 113 It is noted that this new BGP attribute is simple and requires little 114 change to the current practice and operation of BGP4. Nevertheless, 115 the new attribute would offer the flexibility of shifting more 116 influence on route selection to where the route originates, which has 117 become increasingly meaningful as the Internet becomes more complex 118 and dynamic. At the same time, the autonomy of an AS is preserved as 119 the "local_pref" feature remains unchanged. A typical application of 120 this attribute is illustrated in [4] where the DPA attribute is used 121 to simplify the implementation of symmetric inter-domain routing and 122 load-sharing. 124 Applicability 126 The DPA path attribute may be used with BGP version 4 and all 127 subsequent versions of BGP unless specifically noted otherwise. 129 Security Considerations 131 Security considerations are not discussed in this memo. 133 Acknowledgments 135 The authors would like to thank Yakov Rekhter of cisco for his 136 insightful comments and suggestions. We also acknowledge Ramesh 137 Govindan (ISI) and Ravi Chandra (cisco) for their helpful comments. 139 References 141 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 142 RFC1771, March 1995. 144 [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway 145 Protocol in the Internet", RFC1772, March 1995. 147 [3] Chen, E., and Bates, T., "Current Practice of Implementing 148 Symmetric Routing and Load Sharing in the Multi-Provider Internet", 149 INTERNET-DRAFT, , June 1995. 151 [4] Chen, E., and Bates, T., "Application of the BGP Destination 152 Preference Attribute in Implementing Symmetric Routing", INTERNET- 153 DRAFT, , June 1995. 155 [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, , March 1995. 158 [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, 159 April 1995. 161 Author's Addresses 163 Enke Chen 164 MCI 165 2100 Reston Parkway 166 Reston, VA 22091 168 phone: +1 703 715 7087 169 email: enke@mci.net 171 Tony Bates 172 MCI 173 2100 Reston Parkway 174 Reston, VA 22091 176 phone: +1 703 715 7521 177 email: Tony.Bates@mci.net