idnits 2.17.1 draft-chen-idr-asloop-aggr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4271, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4271, updated by this document, for RFC5378 checks: 2006-01-13) -- 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 (October 18, 2021) is 920 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Chen 3 Internet Draft Palo Alto Networks 4 Updates: 4271 (if approved) S. Olofsson 5 Intended Status: Standards Track Graphiant Inc. 6 Expiration Date: April 19, 2022 October 18, 2021 8 Relax the AS Loop Detection for Aggregates in BGP 9 draft-chen-idr-asloop-aggr-00.txt 11 Abstract 13 Currently an BGP aggregate may be denied or excluded by the AS loop 14 detection mechanism when a more specific, contributing route contains 15 the local AS number. To help enhance network robustness and simplify 16 network operations, in this document we propose that the AS loop 17 detection be relaxed for aggregates with an AS_SET path segment. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 19, 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 As described in Section 5.1.6 of the BGP specification [RFC4271], the 54 AS_SET path segment is formed when aggregating several routes, and it 55 normally includes the set of ASes from which the aggregate was 56 formed. The aggregate, being less specific than the contributing 57 routes, is different from any of the more specific, contributing 58 routes, and is a new route for all practical purposes. 60 When an aggregate is propagated through the routing system, it may 61 land in a network that has contributed with a more specific route to 62 the aggregate and thus has its AS number present in the AS_SET path 63 segment of the AS_PATH attribute. The aggregate may be denied, or be 64 excluded in BGP route selection due to the AS loop detection 65 mechanism specified in Section 9.1.2 [RFC4271]: 67 If the AS_PATH attribute of a BGP route contains an AS loop, the 68 BGP route should be excluded from the Phase 2 decision function. 69 AS loop detection is done by scanning the full AS path (as 70 specified in the AS_PATH attribute), and checking that the 71 autonomous system number of the local system does not appear in 72 the AS path. Operations of a BGP speaker that is configured to 73 accept routes with its own autonomous system number in the AS path 74 are outside the scope of this document. 76 By dropping the aggregate, or excluding it in BGP route selection 77 when the local AS is contained in the AS_SET, one can lose 78 reachability, in particular when only the aggregate is advertised and 79 the more specific contributing routes are suppressed. 81 Although BCP 172 [RFC6472] makes a recommendation for not using the 82 AS_SET path segment in BGP, the AS_SET path segment may remain in use 83 for a long time. 85 To help enhance network robustness and simplify network operations, 86 in this document we propose that the AS loop detection be relaxed for 87 aggregates with an AS_SET path segment. 89 2. Revision to AS Loop Detection 91 The AS loop detection specified in Section 9.1.2. of [RFC4271] is 92 revised as follows: 94 Old text: 96 AS loop detection is done by scanning the full AS path (as 97 specified in the AS_PATH attribute), and checking that the 98 autonomous system number of the local system does not appear 99 in the AS path. 101 New text: 103 AS loop detection is done by scanning the full AS path (as 104 specified in the AS_PATH attribute) but excluding the AS path 105 segments with the AS_SET segment type, and checking that the 106 autonomous system number of the local system does not appear 107 in the AS path. 109 3. IANA Considerations 111 This document makes no request to IANA. 113 4. Security Considerations 115 The revision proposed in this document does not change the underlying 116 security or confidentiality issues inherent in the existing BGP 117 [RFC4271]. 119 5. Acknowledgments 121 TBD. 123 6. References 125 6.1. Normative References 127 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 128 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 129 DOI 10.17487/RFC4271, January 2006, 130 . 132 6.2. Informative References 134 [RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using 135 AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, 136 DOI 10.17487/RFC6472, December 2011, 137 . 139 7. Authors' Addresses 141 Enke Chen 142 Palo Alto Networks, Inc. 144 Email: enchen@paloaltonetworks.com 146 Stefan Olofsson 147 Graphiant Inc. 149 Email: stefan@Graphiant.com