idnits 2.17.1 draft-li-idr-congestion-status-extended-community-04.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 an Introduction section. -- 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 (March 12, 2017) is 2574 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: 'RFC4271' is defined on line 269, but no explicit reference was found in the text Summary: 1 error (**), 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: Standards Track Huawei Technologies 6 Expires: September 13, 2017 March 12, 2017 8 Carry congestion status in BGP extended community 9 draft-li-idr-congestion-status-extended-community-04 11 Abstract 13 A new extended community is introduced in this document to carry the 14 link congestion status, especially for the exit link of one AS. It 15 is called congestion status extended community. This extended 16 community can be used by the BGP routers or the SDN controllers to 17 steer the Internet-access 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 September 13, 2017. 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Congestion Status Extended Community . . . . . . . . . . . . 4 62 4. Application Considerations . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Problem Statement 73 Typically the architecture of a large scale ISP's network is multi- 74 layered, as illustrated in Figure 1. The national backbone network 75 has its own AS, and each of the province or state network has a 76 specific AS. Backbone network connects all the province or state 77 networks together and has several exit links to access the Internet. 78 The province or state networks usually have direct exit links to the 79 Internet. The total bandwidth of the backbone exit links is usually 80 much bigger than that of the direct exit links in the province or 81 state networks. Thus, the Internet-access traffic is mainly 82 transported through the backbone exit links by deploying route 83 policies on the ASBR routers in the province or state networks. The 84 ASBR routers in the province or state networks, for example, prefer 85 the routes learned from the backbone by setting higher local 86 preference for those routes. However, when the backbone exit links 87 are congested due to traffic increasing or delay of the capacity 88 expansion, the ASBR routers in the province or state networks do not 89 know this, and still deliver Internet-access traffic to the backbone. 90 The customer experience deteriorates, the operator, in turn, will 91 receive more and more complaints for its bad network performance. 92 Then, the operator has to steer some Internet-access traffic to the 93 direct exit links in the province or state networks by deploying 94 route policy on the ASBR routers. This kind of policy should be 95 removed when the capacity expansion of the backbone exit links is 96 done. The ASBR routers do not know this again. 98 +---------------------------------------------------------+ 99 | | 100 | Internet | 102 | +----------+ +----------+ +----------+ | 103 +-| Router a |----------| Router b |---------| Router c |-+ 104 +----------+ +----------+ +----------+ 105 / \ \ / 106 ---/-----\-------------------\------------------/---------- 107 | \ \ /ISP Network 108 | +----------+ +----------+ +----------+ 109 | +-| Router 1 |----| Router 2 |----| Router 3 |-+ 110 | | +----------+ +----------+ +----------+ | 111 | | | 112 | | BACKBONE | 113 | | AS B | 114 | | +----------+ +----------+ +----------+ | 115 | +-| Router L |----| Router M |----| Router N |-+ 116 | +----------+ +----------+ +----------+ 117 | / | \ 118 | / | \ 119 +----------+ +----------+ +----------+ 120 +-| Router X |-+ +-| Router Y |-+ +-| Router Z |-+ 121 | +----------+ | | +----------+ | | +----------+ | 122 | province X | | province Y | | province Z | 123 | AS X | | AS Y | | AS Z | 124 +--------------+ +--------------+ +--------------+ 126 Figure 1: Typical architecture of a large scale ISP's network 128 In [constrained-multiple-path], authors from France Telecom also 129 specified the requirement to know the congestion status of a link. 131 2. Solution Overview 133 This document introduces a new extended community [RFC4360] to 134 deliver the congestion status of the exit link to other BGP speakers. 135 The BGP receiver can then use this extended community to deploy route 136 policy, thus steer Internet-access traffic according to the 137 congestion status of the exit link. Router X in the above figure, 138 for example, can steer some Internet-access traffic to the direct 139 exit link when it knows the backbone exit link is congested. On the 140 other hand, when Router X knows the exit link of AS B is not 141 congested anymore, it can steer all the Internet-access traffic back 142 to the backbone network. The introduced extended community is called 143 congestion status extended community. 145 Congestion status extended community is good not only to the ASBRs in 146 other AS, but also to the BGP peers within one AS. For instance, 147 Router M in backbone AS chooses Router 2 to transport the Internet- 148 access traffic by default, because the IGP cost from Router M to 149 Router 2 is smallest. When Router M receives congestion status 150 extended communities from Router 1,2,3, which indicate the 151 utilization of the exit link of Router 1,2,3 is 90%, 70%, and 50% 152 respectively, it can choose Router 3 to transport some Internet- 153 access traffic using route policy. 155 In a network deployed SDN (Software Defined Network) controller, 156 congestion status extended community can be used by the controller to 157 steer the Internet access traffic among all the exit links from the 158 perspective of the whole network. 160 For the network with Route Reflectors (RRs) [RFC4456], RRs by default 161 only advertise the best route for a specific prefix to their clients. 162 Thus RR clients has no opportunity to compare the congestion status 163 among all the exit links. In this situation, to allow RR clients 164 learning all the routes for a specific prefix from all the exit 165 links, RRs are RECOMMENDED to enable add-path functionality 166 [RFC7911]. 168 3. Congestion Status Extended Community 170 As described in [RFC4360], the extended community attribute is an 171 8-octet value with the first one or two octets to indicate the type 172 of this attribute. Since congestion status extended community needs 173 to be delivered from on AS to other ASes, and used by the BGP 174 speakers both in other ASes and within the same AS as the sender, it 175 MUST be a transitive extended community, i.e. the T bit in the first 176 octet MUST be zero. 178 We only define the congestion status extended community for four- 179 octet AS number [RFC6793], since all the BGP speakers can handle 180 four-octet AS number now and the two-octet AS numbers can be mapped 181 to four-octet AS numbers by setting the two high-order octets of the 182 four-octet field to zero, as per [RFC6793]. 184 Congestion status extended community is a sub-type allocated from 185 Transitive Four-Octet AS-Specific Extended Community Sub-Types 186 defined in section 5.2.4 of [RFC7153]. Its format is as Figure 2. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type =0x02 | Sub-Type | Sender AS Number | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Sender AS Number (cont.) | Bandwidth | Utilization | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2: Congestion status extended community 198 The "Type" field MUST be 0x02, which indicate this is a Transitive 199 Four-Octet AS-Specific Extended Community. 201 The "Sub-Type" field is used to indicate this is a Congestion 202 Status Extended Community. Its value is to be assigned by IANA. 204 The "Sender AS Number" field is 4 octets. Its value is the AS 205 number of the BGP speaker who generates this congestion status 206 extended community. If the generator has 2-octct AS number, it 207 MUST encode its AS number in the last (low order) two bytes and 208 set the first (high order) two bytes to zero, as per [RFC6793]. 210 The "Bandwidth" field is 1 octet. Its value is the bandwidth of 211 the exit link in unit of 10 gbps (gigabits per second). The link 212 with bandwidth less than 10 gbps is not suitable to use this 213 feature. 215 The "Utilization" field is 1 octet. Its value is the utilization 216 of the exit link in unit of percent. We can use the "Utilization" 217 field together with the "Bandwidth" field to calculate the traffic 218 load that we can further steer to this exit link. 220 4. Application Considerations 222 To avoid route oscillation, the exit router SHOULD set a threshold. 223 When the utilization change reaches the threshold, the exit router 224 SHOULD generate a BGP update message with congestion status extended 225 community. Implementations SHOULD further reduce the BGP update 226 messages trigered by link utilization change using the method similar 227 to BGP Route Flap Damping [RFC2439]. When link utilization change by 228 small amounts that fall under thresholds that would cause the 229 announcement of BGP update message, implementations SHOULD suppress 230 the announcement and set the penalty value accordingly. 232 To avoid traffic oscillation, i.e. more traffic than expected is 233 attracted to the low utilized link, and some traffic has to be 234 steered back to other links, route policy can be set at the exit 235 router. Congestion status extended community is only conveyed for 236 some specific routes or only for some specific BGP peers. Congestion 237 status extended community can also be used in a SDN network. The SDN 238 controller uses the exit link utilization information to steer the 239 Internet access traffic among all the exit links from the perspective 240 of the whole network. 242 5. Security Considerations 244 This document only defines a new extended communities to carry the 245 congestion status of the exit link. This new extended community does 246 not directly introduce any new security issues. The same security 247 considerations as for the BGP extended community [RFC4360] applies. 249 6. IANA Considerations 251 One sub-type is solicited to be assigned from Transitive Four-Octet 252 AS-Specific Extended Community Sub-Types registry to indicate the 253 Congestion Status Extended Community defined in this document. 255 7. Acknowledgments 257 Many thanks to Rudiger Volk, Susan Hares, John Scudder for their 258 review and comments to improve this document. 260 8. References 262 8.1. Normative References 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 270 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 271 DOI 10.17487/RFC4271, January 2006, 272 . 274 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 275 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 276 February 2006, . 278 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 279 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 280 March 2014, . 282 8.2. Informative References 284 [constrained-multiple-path] 285 Boucadair, M. and C. Jacquenet, "Constrained Multiple BGP 286 Paths", October 2010. 288 [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route 289 Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 290 1998, . 292 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 293 Reflection: An Alternative to Full Mesh Internal BGP 294 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 295 . 297 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 298 Autonomous System (AS) Number Space", RFC 6793, 299 DOI 10.17487/RFC6793, December 2012, 300 . 302 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 303 "Advertisement of Multiple Paths in BGP", RFC 7911, 304 DOI 10.17487/RFC7911, July 2016, 305 . 307 Authors' Addresses 309 Zhenqiang Li 310 China Mobile 311 No.32 Xuanwumenxi Ave., Xicheng District 312 Beijing 100032 313 P.R. China 315 Email: li_zhenqiang@hotmail.com 317 Jie Dong 318 Huawei Technologies 319 Huawei Campus, No.156 Beiqing Rd. 320 Beijing 100095 321 P.R. China 323 Email: jie.dong@huawei.com