idnits 2.17.1 draft-bhagat-bgp-multiple-nexthops-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 89: '.... A BGP speaker SHOULD use Capability...' RFC 2119 keyword, line 123: '... group. The BGP peers MUST share same...' RFC 2119 keyword, line 131: '... The BGP speaker SHOULD add multiple N...' RFC 2119 keyword, line 137: '...originated, the BGP speaker SHOULD NOT...' RFC 2119 keyword, line 141: '...originated, the BGP speaker SHOULD add...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 23, 2021) is 1127 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group A. Bhagat 3 Internet-Draft Amazon 4 Intended status: Informational March 23, 2021 5 Expires: September 24, 2021 7 BGP Multiple Nexthops 8 draft-bhagat-bgp-multiple-nexthops-00 10 Abstract 12 This document presents a new feature in BGP that allows grouping of 13 multiple BGP sessions between a pair of speakers and sending multiple 14 nexthops for a single prefix. This helps avoid sending and receiving 15 duplicate routes across all sessions. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 24, 2021. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Capability Support . . . . . . . . . . . . . . . . . . . . . 2 53 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Multiprotocol Extensions . . . . . . . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 In Data Center networks where CLOS fabrics are built solely using BGP 63 [RFC4271], it is very common to have topology where a pair of routers 64 have multiple BGP sessions between them - a single BGP session over 65 every link. Each BGP session is independent of the others and BGP 66 messages are sent and received over every BGP session. There are 67 various reasons for following this design pattern but the main reason 68 is that when links within the LAG interfaces go down, that results in 69 inconsistent bandwidth availability which is not reflected at the 70 routing level. This causes the capacity models to not work correctly 71 and can also result in network congestion. 73 While the maintenance of these independent BGP sessions is trivial, 74 routers sending and receiving duplicate BGP UPDATE messages for 75 hundreds or thousands of routes, leads to unnecessarily generating, 76 processing and storing of routes. These duplicate messages provide 77 no extra information except capability to select and install multiple 78 paths for routes. Every route in the BGP UPDATE messages has same 79 BGP path attributes except the NEXT_HOP attribute. 81 This document provides a way to advertise the route only one time 82 with multiple NEXT_HOP attributes to achieve the same benefits as 83 having the same route advertised multiple times over multiple BGP 84 sessions with different NEXT_HOP attributes. 86 2. Capability Support 88 A new Capability Optional parameter will be communicated in BGP Open 89 message. A BGP speaker SHOULD use Capability Advertisement procedure 90 in [RFC3392] to announce the support. The Capability Code is to be 91 assigned by IANA. 93 0 1 2 3 94 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Type | Length | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | AFI | Reserved | SAFI | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 ~ ~ 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | AFI | Reserved | SAFI | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 1: BGP Multiple Nexthops Capability 107 Capability Type: TBA by IANA 109 Capability Length: Variable length. 111 Capability Value: Specifies all AFI/SAFI configured on the BGP 112 speaker that support the feature. 114 3. Operation 116 During BGP session establishment, BGP Multiple Nexthops capability 117 for every supported AFI/SAFI is advertised and received in BGP Open 118 message. When two BGP speakers have multiple BGP sessions between 119 themselves and if they support BGP Multiple Nexthops capability, BGP 120 Identifier and AS of the peer are used to identify all BGP sessions 121 that can be logically grouped together per AFI/SAFI. BGP UPDATE 122 messages sent over one BGP session applies to all other BGP sessions 123 within this logical group. The BGP peers MUST share same 124 configuration settings to be treated as a group on the speaker. 126 When BGP UPDATE message is advertised, the rules for the next hop 127 information are as follows: 129 When sending a message to an external peer: 131 o The BGP speaker SHOULD add multiple NEXT_HOP attributes - each 132 NEXT_HOP attribute carrying the IP address of the interface that 133 the speaker uses to establish BGP session to peer. 135 When sending a message to an internal peer: 137 o If the route is not locally originated, the BGP speaker SHOULD NOT 138 modify the NEXT_HOP attributes unless it has been explicitly 139 configured to announce its own IP address(es) as next-hop(s). 141 o If the route is locally originated, the BGP speaker SHOULD add 142 multiple NEXT_HOP attributes - each NEXT_HOP attribute carrying 143 the IP address of the interface that the speaker uses to establish 144 BGP session to peer. 146 When withdrawing routes, next-hop information is not carried in the 147 message. In that case, the peer SHOULD remove the route with any 148 number of NEXT_HOP attributes attached to it even when the withdraw 149 message is received over a different BGP session than the original 150 BGP session over which the update message was sent. 152 When the link or BGP session associated with the logical group goes 153 down, the speakers SHOULD remove only the NEXT_HOP associated with 154 routes. 156 Note that the BGP UPDATE message is sent over a single BGP session in 157 the logical group. For example, if there are 8 independent BGP 158 sessions between two speakers, the speaker chooses only 1 out of 8 159 sessions over which it sends the BGP UPDATE message. The speaker can 160 choose one BGP session at random, or in round-robin fashion, or some 161 other means and hence is out-of-scope of this document. 163 4. Multiprotocol Extensions 165 [RFC4760] defines MP_REACH_NLRI path attribute which carries routes 166 as well as next-hop information, grouped together. Details of next- 167 hop information for MP_REACH_NLRI in section 3 of [RFC4760]. This 168 document allows adding multiple NEXT_HOP attributes when advertising 169 routes with MP_REACH_NLRI path attribute using the same mechanism 170 described in section 3 of this document. 172 5. IANA Considerations 174 As specified in the document, the IANA will assign a new Capability 175 Code for BGP Multiple Nexthops capability support. 177 6. Acknowledgements 179 The authors would like to thank members of IDR Working Group for 180 their review and comments. 182 7. Normative References 184 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 185 with BGP-4", RFC 3392, DOI 10.17487/RFC3392, November 186 2002, . 188 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 189 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 190 DOI 10.17487/RFC4271, January 2006, 191 . 193 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 194 "Multiprotocol Extensions for BGP-4", RFC 4760, 195 DOI 10.17487/RFC4760, January 2007, 196 . 198 Author's Address 200 Amit Bhagat 201 Amazon 202 Seattle 203 USA 205 Email: abhagat@amazon.com