idnits 2.17.1 draft-li-idr-congestion-status-extended-community-05.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 draft header indicates that this document updates RFC4360, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7153, but the abstract doesn't seem to mention this, which it should. -- 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) (Using the creation date from RFC4360, updated by this document, for RFC5378 checks: 2001-07-10) -- 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 (June 30, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4271' is defined on line 234, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Z. Li 3 Internet-Draft China Mobile 4 Updates: 4271, 4360, 7153 (if approved) J. Dong 5 Intended status: Experimental Huawei Technologies 6 Expires: January 1, 2018 June 30, 2017 8 Carry congestion status in BGP extended community 9 draft-li-idr-congestion-status-extended-community-05 11 Abstract 13 A new extended community, called congestion status extended 14 community, is introduced in this document to carry the link 15 congestion status, especially for the exit link of one AS. 16 Congestion status extended community can be used by the BGP speakers 17 to steer the AS-outgoing traffic among the exit links. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 1, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Congestion Status Extended Community . . . . . . . . . . . . 4 61 3. Application Considerations . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 7.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Knowing the congestion status of the AS exit links is useful for 73 traffic steering, especially for steering the AS outgoing traffic 74 among the exit links. 76 AS A, as shown in the following figure, has multiple exit links 77 connected to AS B. Both AS A and B has exit link to AS C, and AS B 78 provides transit service for AS A. Due to cost or some other 79 reasons, AS A prefers using AS B to transmit its' traffic to AS C, 80 not the directly connected link between AS A and C. If the exit 81 routers, Router 7 and 8, in AS A tell their iBGP peers the congestion 82 status of the exit links, the peers in turn can steer some outgoing 83 traffic toward the less loaded exit link. If AS A knows the link 84 between AS B and AS C is congested, it can steer some traffic towards 85 AS C from AS B to the directly connected link by applying some route 86 policies. 88 +-------------------------------------------+ 89 | AS C | 90 | +----------+ +----------+ | 91 +--| Router 1 |---------------| Router 2 |--+ 92 +----------+ +----------+ 93 | | 94 | | 95 | +----------+ 96 | +--------| Router 3 |----------+ 97 | | +----------+ | 98 | | AS B | 99 | | +----------+ +----------+ | 100 | +-| Router 4 |----| Router 5 |-+ 101 | +----------+ +----------+ 102 | | | 103 | | | 104 +----------+ +----------+ +----------+ 105 +--| Router 6 |--------| Router 7 |----| Router 8 |-+ 106 | +----------+ +----------+ +----------+ | 107 | AS A | 108 +---------------------------------------------------+ 110 In [constrained-multiple-path], authors from France Telecom also 111 specified the requirement to know the congestion status of a link. 113 This document introduces a new extended community [RFC4360] to 114 deliver the congestion status of the exit link to other BGP speakers. 115 The BGP receiver can then use this extended community to deploy route 116 policy, thus steer AS outgoing traffic according to the congestion 117 status of the exit links. This mechanisum can be used by both iBGP 118 and eBGP. 120 In a network deployed SDN (Software Defined Network) controller, 121 congestion status extended community can be used by the controller to 122 steer the AS outgoing traffic among all the exit links from the 123 perspective of the whole network. 125 For the network with Route Reflectors (RRs) [RFC4456], RRs by default 126 only advertise the best route for a specific prefix to their clients. 127 Thus RR clients has no opportunity to compare the congestion status 128 among all the exit links. In this situation, to allow RR clients 129 learning all the routes for a specific prefix from all the exit 130 links, RRs are RECOMMENDED to enable add-path functionality 131 [RFC7911]. 133 2. Congestion Status Extended Community 135 As described in [RFC4360], the extended community attribute is an 136 8-octet value with the first one or two octets to indicate the type 137 of this attribute. Since congestion status extended community needs 138 to be delivered from on AS to other ASes, and used by the BGP 139 speakers both in other ASes and within the same AS as the sender, it 140 MUST be a transitive extended community, i.e. the T bit in the first 141 octet MUST be zero. 143 We only define the congestion status extended community for four- 144 octet AS number [RFC6793], since all the BGP speakers can handle 145 four-octet AS number now and the two-octet AS numbers can be mapped 146 to four-octet AS numbers by setting the two high-order octets of the 147 four-octet field to zero, as per [RFC6793]. 149 Congestion status extended community is a sub-type allocated from 150 Transitive Four-Octet AS-Specific Extended Community Sub-Types 151 defined in section 5.2.4 of [RFC7153]. Its format is as Figure 1. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type =0x02 | Sub-Type | Sender AS Number | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Sender AS Number (cont.) | Bandwidth | Utilization | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Congestion status extended community 163 The "Type" field MUST be 0x02, which indicate this is a Transitive 164 Four-Octet AS-Specific Extended Community. 166 The "Sub-Type" field is used to indicate this is a Congestion 167 Status Extended Community. Its value is to be assigned by IANA. 169 The "Sender AS Number" field is 4 octets. Its value is the AS 170 number of the BGP speaker who generates this congestion status 171 extended community. If the generator has 2-octct AS number, it 172 MUST encode its AS number in the last (low order) two bytes and 173 set the first (high order) two bytes to zero, as per [RFC6793]. 175 The "Bandwidth" field is 1 octet. Its value is the bandwidth of 176 the exit link in unit of 10 gbps (gigabits per second). The link 177 with bandwidth less than 10 gbps is not suitable to use this 178 feature. 180 The "Utilization" field is 1 octet. Its value is the utilization 181 of the exit link in unit of percent. We can use the "Utilization" 182 field together with the "Bandwidth" field to calculate the traffic 183 load that we can further steer to this exit link. 185 3. Application Considerations 187 To avoid route oscillation, the exit router SHOULD set a threshold. 188 When the utilization change reaches the threshold, the exit router 189 SHOULD generate a BGP update message with congestion status extended 190 community. Implementations SHOULD further reduce the BGP update 191 messages trigered by link utilization change using the method similar 192 to BGP Route Flap Damping [RFC2439]. When link utilization change by 193 small amounts that fall under thresholds that would cause the 194 announcement of BGP update message, implementations SHOULD suppress 195 the announcement and set the penalty value accordingly. 197 To avoid traffic oscillation, i.e. more traffic than expected is 198 attracted to the low utilized link, and some traffic has to be 199 steered back to other links, route policy can be set at the exit 200 router. Congestion status extended community is only conveyed for 201 some specific routes or only for some specific BGP peers. Congestion 202 status extended community can also be used in a SDN network. The SDN 203 controller uses the exit link utilization information to steer the 204 Internet access traffic among all the exit links from the perspective 205 of the whole network. 207 4. Security Considerations 209 This document only defines a new extended communities to carry the 210 congestion status of the exit link. This new extended community does 211 not directly introduce any new security issues. The same security 212 considerations as for the BGP extended community [RFC4360] applies. 214 5. IANA Considerations 216 One sub-type is solicited to be assigned from Transitive Four-Octet 217 AS-Specific Extended Community Sub-Types registry to indicate the 218 Congestion Status Extended Community defined in this document. 220 6. Acknowledgments 222 Many thanks to Rudiger Volk, Susan Hares, John Scudder, Randy Bush 223 for their review and comments to improve this document. 225 7. References 227 7.1. Normative References 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, 231 DOI 10.17487/RFC2119, March 1997, 232 . 234 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 235 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 236 DOI 10.17487/RFC4271, January 2006, 237 . 239 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 240 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 241 February 2006, . 243 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 244 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 245 March 2014, . 247 7.2. Informative References 249 [constrained-multiple-path] 250 Boucadair, M. and C. Jacquenet, "Constrained Multiple BGP 251 Paths", October 2010. 253 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 254 Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 255 1998, . 257 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 258 Reflection: An Alternative to Full Mesh Internal BGP 259 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 260 . 262 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 263 Autonomous System (AS) Number Space", RFC 6793, 264 DOI 10.17487/RFC6793, December 2012, 265 . 267 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 268 "Advertisement of Multiple Paths in BGP", RFC 7911, 269 DOI 10.17487/RFC7911, July 2016, 270 . 272 Authors' Addresses 274 Zhenqiang Li 275 China Mobile 276 No.32 Xuanwumenxi Ave., Xicheng District 277 Beijing 100032 278 P.R. China 280 Email: li_zhenqiang@hotmail.com 282 Jie Dong 283 Huawei Technologies 284 Huawei Campus, No.156 Beiqing Rd. 285 Beijing 100095 286 P.R. China 288 Email: jie.dong@huawei.com