idnits 2.17.1 draft-ietf-idr-bgp-dpa-02.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-26) 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 (July 1995) is 10513 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 136, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 147, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 150, 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. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Enke Chen 2 Tony Bates 3 MCI 4 July 1995 6 Destination Preference Attribute for BGP 7 9 Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its Areas, 13 and its Working Groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material or to cite them other than as a "working 20 draft" or "work in progress". 22 Please check the I-D abstract listing contained in each Internet 23 Draft directory to learn the current status of this or any other 24 Internet Draft. 26 Abstract 28 The Border Gateway Protocol [1] is an inter-autonomous system routing 29 protocol designed for TCP/IP internets. 31 This document describes a new BGP path attribute termed "Destination 32 Preference Attribute" (DPA) which can be used by a single autonomous 33 system (AS) to specify globally transitive metrics in its routing 34 announcement via BGP. The metric can then be used by upstream BGP 35 speakers to favor certain path for return traffic. The application 36 of this attribute includes facilitating the implementation of 37 symmetric routing and load sharing in the multi-provider Internet. 39 Introduction 41 In certain cases there is a need for an autonomous system (AS) to 42 specify a globally transitive preference in its routing announcement 43 via BGP so that the upstream BGP speakers can use the preference to 44 favor certain path for return traffic. For instance, as discussed in 45 [3], currently it is difficult to implement symmetric routing and 46 load sharing in the multi-provider Internet due to the lack of this 47 preference in BGP. 49 In this paper, we propose a new BGP attribute termed "Destination 50 Preference Attribute" (DPA) to address such a need. More 51 specifically, the DPA is a globally transitive metric that can be 52 used by an AS to specify preference in its routing announcement so 53 that the return traffic favors certain path. As illustrated in [4] 54 through several examples, this metric, combined with AS-based 55 "local_pref" offers much greater flexibility and manageability in 56 implementing symmetric inter-domain routing and load sharing in the 57 multi-provider Internet. 59 Destination Preference Attribute (DPA) 61 This document proposes the DPA path attribute, which is an optional 62 transitive attribute of fixed length. The attribute is represented 63 by a pair . The AS# is a two octet non-negative 64 integer, which denotes the AS that specifies the preference. The DPA 65 value is a four octet non-negative integer. 67 The DPA attribute has Type Code 11. 69 Route Selection Process 71 The DPA attributes are considered comparable only if the DPA 72 attributes are present in all the routes being compared and are set 73 by the same AS. 75 The comparable DPA attributes shall be used as a selection criteria, 76 after the "local_pref" attribute is evaluated, and before the 77 evaluation of the AS path length and the multi-exit-discriminator 78 (MED). Non-comparable DPA attributes shall not be used in the route 79 selection process. 81 The higher the DPA attribute value, the more preferred the route. 83 Operation 85 The DPA attribute should not be used as a replacement for MED. MED 86 should still be used when an AS has multiple connections to a single 87 neighboring AS. 89 The DPA attribute should only be set when needed. The AS that sets 90 this preference must include its AS number in the attribute. A BGP 91 speaker may use the "local_pref" attribute to prefer a different path 92 other than the one specified by the DPA attribute value. This does 93 not preclude an AS from re-setting this attribute. However, 94 coordination with the upstream and/or downstream neighbors is 95 strongly recommended. 97 Aggregation 99 If aggregation is done, the resultant aggregate shall be treated as a 100 new NLRI. No DPA attribute shall be derived from more specific NLRIs 101 which formed the aggregate. The resultant aggregate is free to have 102 the DPA attribute set if so desired. 104 Remarks 106 It is noted that this new BGP attribute is simple and requires little 107 change to the current practice and operation of BGP4. Nevertheless, 108 the new attribute would offer the flexibility of shifting more 109 influence on route selection to where the route originates, which has 110 become increasingly meaningful as the Internet becomes more complex 111 and dynamic. At the same time, the autonomy of an AS is preserved as 112 the "local_pref" feature remains unchanged. A typical application of 113 this attribute is illustrated in [4] where the DPA attribute is used 114 to simplify the implementation of symmetric inter-domain routing and 115 load-sharing. 117 Applicability 119 The DPA path attribute may be used with BGP version 4 and all 120 subsequent versions of BGP unless specifically noted otherwise. 122 Security Considerations 124 Security considerations are not discussed in this memo. 126 Acknowledgments 128 The authors would like to thank Yakov Rekhter of Cisco for his 129 insightful comments and suggestions. 131 References 133 [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", 134 RFC1771, March 1995. 136 [2] Y. Rekhter, and P. Gross, "Application of the Border Gateway 137 Protocol in the Internet", RFC1772, March 1995. 139 [3] Chen, E., and Bates, T., "Current Practice of Implementing 140 Symmetric Routing and Load Sharing in the Multi-Provider Internet", 141 INTERNET-DRAFT, , June 1995. 143 [4] Chen, E., and Bates, T., "Application of the BGP Destination 144 Preference Attribute in Implementing Symmetric Routing", INTERNET- 145 DRAFT, , June 1995. 147 [5] Antonov, V., "BGP AS Path Metrics", INTERNET DRAFT, , March 1995. 150 [6] Rekhter, Y., "Routing in a Multi-provider Internet", RFC1787, 151 April 1995. 153 Author's Addresses 155 Enke Chen 156 MCI 157 2100 Reston Parkway 158 Reston, VA 22091 160 phone: +1 703 715 7087 161 email: enke@mci.net 163 Tony Bates 164 MCI 165 2100 Reston Parkway 166 Reston, VA 22091 168 phone: +1 703 715 7521 169 email: Tony.Bates@mci.net