idnits 2.17.1 draft-francois-idr-addpath-limit-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 '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 a Security Considerations section. ** 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 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 128: '...e remaining bits MUST be set to 0 and ...' RFC 2119 keyword, line 139: '...Limit capability SHOULD be announced b...' RFC 2119 keyword, line 142: '...DD-PATH neighbor SHOULD also announce ...' RFC 2119 keyword, line 148: '... BGP peer SHOULD ignore the ADD-PATH...' RFC 2119 keyword, line 153: '...he number of paths per peer SHOULD NOT...' (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 (February 7, 2014) is 3731 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) == Missing Reference: 'RFC4760' is mentioned on line 116, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-09 == Outdated reference: A later version (-08) exists of draft-ietf-idr-add-paths-guidelines-05 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pierre Francois 3 Internet-Draft Camilo Cardona 4 Expires: August 11, 2014 Institute IMDEA Networks 5 Adam Simpson 6 Alcatel-Lucent 7 Jeffrey Haas 8 Juniper Networks 9 February 7, 2014 11 ADD-PATH limit capability 12 draft-francois-idr-addpath-limit-00 14 Abstract 16 In this draft, we propose a new capability that allows BGP speakers 17 supporting ADD-PATH to announce a limit on the number of paths they 18 want to receive from their peers. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 11, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. The ADD-PATH Limit capability . . . . . . . . . . . . . . . . . 3 56 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1. Introduction 62 ADD-PATH is an extension to BGP that allows a BGP speaker to send and 63 receive more than one path for the same NLRI [AddPath]. The ADD-PATH 64 capability does not include any mechanism for restricting the number 65 or type of paths that a peer can receive from others. Thus, a 66 receiving BGP speaker has no control on the number of paths sent by 67 its peer, which depends only on the mode the operator desires to 68 implement in the transmitting side [AddPathGuidelines]. This 69 restriction can make network operations more difficult in some 70 situations: 71 o In cases in which all network devices are managed by the same 72 group, operators select the ADD-PATH mode that best fits the 73 resources of each of their devices. Operators must configure 74 manually each speaker with a mode that does not overload the 75 resources of the other devices. The overhead of this procedure 76 can be high in some networks, as this configuration must be 77 performed at the session level. If a ADD-PATH router could signal 78 a limit in the number of paths it wants to receive, operators 79 could achieve the same resource control by performing a more 80 simple configuration. 81 o In cases in which devices are managed by different operators, such 82 as in networks spanning large geographical regions or in Internet 83 Exchange Points, operators must agree on the ADD-PATH mode to use 84 between BGP speakers. If one of the devices has constraints on 85 the number of paths it can receive, the other party must configure 86 an ADD-PATH mode that does not overload the memory of other 87 device. Under these circumstances, allowing the receiving side to 88 limit the number of paths can ease the management process for all 89 administration sides. 91 In this document, we propose a new capability that allows an ADD-PATH 92 capable BGP speaker to set an explicit upperbound on the number of 93 paths it wants to receive from its peer. 95 2. The ADD-PATH Limit capability 97 +------------------------------------------------+ 98 | Address Family Identifier (2 octets) | 99 +------------------------------------------------+ 100 | Subsequent Address Family Identifier (1 octet) | 101 +------------------------------------------------+ 102 | Flags(1 octet) | 103 +------------------------------------------------+ 104 | Receive bound (2 octet) | 105 +------------------------------------------------+ 106 Figure 1: Capability 108 The meaning and use of the fields are as follows: 110 Address Family Identifier (AFI): 112 This field is the same as the one used in [RFC4760]. 114 Subsequent Address Family Identifier (SAFI): 116 This field is the same as the one used in [RFC4760]. 118 Flag Field 120 This field contains different bit flags related to the ADD-PATH 121 limitation capability. 122 The most significant bit of the field (limit-capable bit) is 123 used to communicate if the device supports the limitation of 124 paths announced to the peer. If the router supports the ADD- 125 PATH Limit capability, but it is not capable of limiting the 126 number of announced paths, it should set the limit-capable bit 127 to 0. 128 The remaining bits MUST be set to 0 and SHOULD be ignored upon 129 receipt. 130 Receive Bound 132 This field indicates the maximum number of paths the device 133 wants to receive from a peer for the . If the field 134 is set to 0, the device has no restriction on the number of 135 paths it can receive. 137 3. Operation 139 The ADD-PATH Limit capability SHOULD be announced by BGP speakers 140 that require their neighbors to send a limited number of paths per 141 prefix. A router that is capable of sending a limited number of 142 paths to a BGP ADD-PATH neighbor SHOULD also announce the ADD-PATH 143 Limit capability. For cases in which a router is not capable of 144 setting a limit in the number of paths it sends to a peer, it should 145 set the limit-capable bit in the add-path capability to 0. 147 The ADD-PATH capability is a prerequisite of the ADD-PATH Limit. A 148 BGP peer SHOULD ignore the ADD-PATH Limit capability from a peer that 149 did not also announce the ADD-PATH capability. 151 The ADD-PATH limit capability is used to set an upper bound on the 152 number of paths that the router wants to receives from a peer. A 153 sender capable of limiting the number of paths per peer SHOULD NOT 154 send more paths than requested by the receiver. 156 It might be impractical for a BGP speaker to strictly stick to each 157 of the upper bounds specified by its peers. Thus, the sender MAY 158 send a lower amount of paths than the upper bound indicated by its 159 peer. 161 A router SHOULD include the best path in the subset of paths to send 162 to a peer, except when the best path is received from that peer. The 163 choice of the rest of paths to be sent is left free to the 164 implementation. 166 A BGP speaker could receive more paths than the number defined in the 167 ADD-PATH capability, even when the BGP peer supports the limitation 168 of paths. This event should be logged, but the session with the peer 169 should be preserved. The receiving speaker should implement the 170 required mechanism to deal with more paths that it can support. 172 4. References 174 [AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder, 175 "Advertisement of Multiple Paths in BGP", 176 draft-ietf-idr-add-paths-09.txt (work in progress). 178 [AddPathGuidelines] 179 J. Uttaro, P. Francois, R. Fragassi, A. Simpson, and K. 180 Patel, "Best Practices for Advertisement of Multiple Paths 181 in IBGP", draft-ietf-idr-add-paths-guidelines-05.txt (work 182 in progress). 184 Authors' Addresses 186 Pierre Francois 187 Institute IMDEA Networks 188 Avda. del Mar Mediterraneo, 22 189 Leganes 28918 190 ES 192 Email: pierre.francois@imdea.org 193 Camilo Cardona 194 Institute IMDEA Networks 195 Avda. del Mar Mediterraneo, 22 196 Leganes 28918 197 ES 199 Email: juancamilo.cardona@imdea.org 201 Adam Simpson 202 Alcatel-Lucent 203 600 March Road 204 Ontario K2K 2E6 205 CA 207 Email: adam.simpson@alcatel-lucent.com 209 Jeffrey Haas 210 Juniper Networks 211 1194 N. Mathilda Ave 212 Sunnyvale 94089 213 USA 215 Email: jhaas@juniper.net