idnits 2.17.1 draft-kvk-trill-fair-share-af-load-share-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 21, 2012) is 4207 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) -- Looks like a reference, but probably isn't: '11' on line 205 -- Looks like a reference, but probably isn't: '20' on line 201 -- Looks like a reference, but probably isn't: '16' on line 147 -- Looks like a reference, but probably isn't: '14' on line 205 == Unused Reference: 'RFC6325' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC6326' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RBisisb' is defined on line 351, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6326 (Obsoleted by RFC 7176) ** Obsolete normative reference: RFC 6439 (Obsoleted by RFC 8139) == Outdated reference: A later version (-06) exists of draft-zhang-trill-vlan-assign-04 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kesava Vijaya Krupakaran 3 Intended Status: Proposed Standard Janardhanan Pathangi Narasimhan 4 Expires: March 25, 2013 Dell 5 September 21, 2012 7 Fair Share AF Load Share 8 draft-kvk-trill-fair-share-af-load-share-02 10 Abstract 12 In an access LAN of a TRILL campus, the DRB can choose to load share 13 the AF responsibility among other RBridges in the LAN. This document 14 throws light on one such approach where the AF appointment is fair 15 share scheduled among the RBridges. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright and License Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2 Shares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3 AF Affinity VLAN Set . . . . . . . . . . . . . . . . . . . . . 4 59 4 AF Affinity VLAN Set Overlap . . . . . . . . . . . . . . . . . 5 60 5 AF Distribution Among Heterogeneous RBridges . . . . . . . . . 6 61 6 AF Computation at DRB . . . . . . . . . . . . . . . . . . . . . 6 62 7 AF and VLAN Mapping . . . . . . . . . . . . . . . . . . . . . . 7 63 8 AF and Multiple ports on a link . . . . . . . . . . . . . . . . 7 64 9 Multi-Topology-Aware Port Capability Sub-TLVs . . . . . . . . . 7 65 9.1 Fair Share Sub-TLV . . . . . . . . . . . . . . . . . . . . 7 66 9.2 AF Affinity VLAN Set Sub-TLV . . . . . . . . . . . . . . . 7 67 9.3 Partial VLANs Appointing Sub-TLV . . . . . . . . . . . . . 8 68 10 Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12.1 Normative References . . . . . . . . . . . . . . . . . . . 9 72 12.2 Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1 Introduction 77 In a shared access LAN, the appointed forwarder for a VLAN is 78 responsible for encapsulating and decapsulating native traffic on 79 that VLAN. Other non-AF RBridges in the LAN discard the native 80 traffic for that VLAN. 82 The DRB can choose to be the AF for all VLANs or load share the AF 83 responsibility among other RBRidges in the LAN. This ensures better 84 utilization of resources like hardware tables and buffers. The VLAN 85 partitioning scheme suggested in [RFC6439] section 2.2.1 is static 86 and requires careful configuration. Another simple protocol would be 87 to allocate VLANs in a round-robin fashion among all RBridges in the 88 LAN. However this doesn't leave scope for schemes like retaining 50% 89 of VLANs with the DRB and distribute only the rest among others. 91 Fair share scheduling of AF allows for the flexibility of assigning 92 certain RBridges (say with higher switching capability) AF for higher 93 proportion of VLANs than others. 95 1.1 Terminology 97 This document uses the acronyms defined in [RFC6439]. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2 Shares 105 Each RBridge is configured with certain quantity of shares. A share 106 is the proportion of VLANs which would be allocated to the RBridge in 107 comparison with other RBridges. The face value of the shares is a 108 relative quantity and makes sense only when taken in conjunction with 109 total shares allocated in the LAN. 111 These shares are advertised by each RBridge in its hello. The DRB 112 load shares the AF among RBridges based on the relative value of 113 shares. 115 For instance, let A, B and C be three RBridges with S(A) = 2, S(B) = 116 1 and S(C) = 1. Then A is assigned the AF for 1/2 of the VLANs while 117 B and C the AF for 1/4th of the VLANs each. 119 Even when the number of VLANs for which the RBridge is to be AF 120 calculates to a non integer value, it should be made sure that there 121 is only one AF for a VLAN in a multi-access LAN. 123 3 AF Affinity VLAN Set 125 Fair share scheduling distributes VLANs among RBridges according to 126 proportion of shares allocated. This allows allocation of higher 127 proportion of VLANs to certain RBridges (with higher switching 128 capability). However, this does not guarantee that these RBridges 129 would handle larger share of the native traffic. 131 Following the previous example, even though A is appointed AF for 50% 132 of the VLANs while B only 25% of the VLANs, the traffic load of VLANs 133 for which B is AF could be considerably higher that those in A. 135 In order to overcome this conundrum, each RBriged in access LAN is 136 configured with an AF Affinity VLAN Set apart form the share 137 proportion. This RBridge has AF affinity to the set of configured 138 VLANs. Thus when the DRB appoints an RBridge AF for a set of VLANs, 139 the members of the set are chosen from the AF Affinity VLAN Set 140 advertised. 142 Expanding on the previous example, if X denotes an RBridge, let S(X) 143 be the shares assigned to X, V(X) be the AF Affinity VLAN Set and 144 AF(X) denote the set of VLANs for which X is assigned AF. Let the 145 access LAN encompass ten shared VLANs [11, 20]. In this case the AF 146 assignment with just the shares configured could be as in Table 1. If 147 RBridge A has higher switching capability and VLANs [16, 20] are 148 heavily loaded, this AF appointment defeats the purpose. 150 +----------------------------------------------------+ 151 |Table 1: AF appointment using fair share scheduling | 152 +--------+-------------+-----------------------------+ 153 | X | S(X) | AF(X) | 154 +--------+-------------+-----------------------------+ 155 | A | 2 | {11, 12, 13, 14, 15} | 156 +--------+-------------+-----------------------------+ 157 | B | 1 | {16, 17, 18} | 158 +--------+-------------+-----------------------------+ 159 | C | 1 | {19, 20} | 160 +--------+-------------+-----------------------------+ 162 By configuring AF Affinity VLAN set in each RBridge, this difficulty 163 can be overcome. Such a configuration is shown in Table 2. How the AF 164 Affinity VLAN set is arrived at is beyond the scope of this document. 165 Long term traffic planning tools could be helpful in extrapolating a 166 decent configuration. 168 +----------------------------------------------------------+ 169 |Table 2: Fair share scheduling with AF Affinity VLAN set | 170 +--+-------+-----------------------+-----------------------+ 171 |X | S(X) | V(X) | AF(X) | 172 +--+-------+-----------------------+-----------------------+ 173 |A | 2 | {16, 17, 18, 19, 20} | {16, 17, 18, 19, 20} | 174 +--+-------+-----------------------+-----------------------+ 175 |B | 1 | {11, 12, 13, 14} | {11, 12, 13} | 176 +--+-------+-----------------------+-----------------------+ 177 |C | 1 | {12, 13, 14} | {14, 15} | 178 +--+-------+-----------------------+-----------------------+ 180 4 AF Affinity VLAN Set Overlap 182 If the AF Affinity VLAN sets advertised by the RBridges overlap, the 183 RBridge with higher share has priority over the affinity of common 184 VLANs. In case the RBridges advertise same share with conflicting AF 185 Affinity VLAN sets, then the one with higher system ID gets more AF 186 affinity over the common VLANs. 188 +-------------------------------------------------------------------+ 189 | Table 3: Fair share scheduling with AF Affinity VLAN set overlap | 190 +-+--------------+----+------------------------+--------------------+ 191 |X| ID(X) |S(X)| V(X) | AF(X) | 192 +-+--------------+----+------------------------+--------------------+ 193 |A|0000.0000.000a| 2 |{15, 16, 17, 18, 19, 20}|{15, 16, 17, 18, 19}| 194 +-+--------------+----+------------------------+--------------------+ 195 |B|0000.0000.000b| 1 | {11, 12, 13, 14, 15} | {14, 20} | 196 +-+--------------+----+------------------------+--------------------+ 197 |C|0000.0000.000c| 1 | {11, 12, 13, 14} | {11, 12, 13} | 198 +-+--------------+----+------------------------+--------------------+ 200 Consider the previous examples with the LAN comprising of three 201 RBridges A, B and C coloured for VLANs [11, 20]. As shown in table 3, 202 the AF Affinity VLAN sets overlap in RBridges {A, C} as well as {B, 203 C}. A, having the highest share has the most affinity over the VLANs 204 configured there. In this example, A has higher AF affinity to VLAN 205 15 than C. Similarly, C has greater the AF affinity of VLANs [11, 14] 206 than B on virtue of its higher system ID. 208 It is possible to calculate a better AF distribution by examining 209 common VLANs in AF Affinity VLAN sets when they overlap. Such 210 algorithms have been avoided to keep the computation at DRB simple. 212 5 AF Distribution Among Heterogeneous RBridges 214 An access LAN could constitute motley set of RBridges with some that 215 support fair share AF scheduling and some that doesn't. If the DRB 216 doesn't support fair share AF scheduling, it ignores the sub-TLVs 217 advertised by other RBridges and continue to distribute AF as it did 218 previously. 220 If the DRB does support fair share AF scheduling and it receives 221 hello form an RBridge without Fair Share Sub-TLV, it is assigned a 222 default share equal to average of all shares advertised in the LAN 223 during AF computation. If the AF Affinity VLAN Set Sub-TLV was not 224 advertised, it is taken to be a NULL set. In case an RBridge 225 advertises AF Affinity Sub-TLV without saying the shares, such TLV is 226 ignored and the behaviour follows as though it had not advertised AF 227 Affinity VLAN set. 229 In particular, if DRB is the only RBridge supporting the feature, all 230 the RBridges get equal shares (equal to the one configured at DRB, 231 consistent with the average rule discussed). 233 For instance, in an access LAN with RBridges A, B and C where S(A) = 234 7, S(B) = 3, and C doesn't support fair share AF scheduling, the DRB 235 assigns it a default of 5 shares. 237 As a special case, if DRB supports fair share AF load share and none 238 of the RBridges advertise any share and no share is configured in 239 DRB, then DRB assigns a share value of 1 to all RBridges and load 240 shares VLANs equally among all the RBridges. 242 6 AF Computation at DRB 244 DRB runs through all RBridges, in descending order of shares 245 configured and assigns the AF based on Affinity VLAN set. If the 246 shares advertised are equal, then RBridges are ordered based on 247 system ID. If RBridges don't advertise shares, they are assigned 248 default shares and are placed below RBridges who advertise shares in 249 the ordered list of RBridges. If there are multiple such non 250 congruous RBridges, they are again ordered based on system ID. 252 The DRB also monitors hellos for any change from previously 253 advertised shares or AF Affinity VLAN set. If it detects a change, 254 the AF assignment is recomputed for all RBridges. Any addition or 255 deletion of adjacency also triggers fresh AF assignment. This 256 simplifies the computation at DRB. 258 7 AF and VLAN Mapping 260 If the DRB detects VLAN mapping, it appoints one RBridge (possibly 261 itself) as the AF for all VLANs as suggested in [RFC6439] section 2.4 262 to prevent loops. 264 8 AF and Multiple ports on a link 266 The shares configured represents the whole RBridge's proportion of AF 267 sought. Further load sharing of AF among multiple ports on same link 268 in an RBridge is a local decision. 270 9 Multi-Topology-Aware Port Capability Sub-TLVs 272 Two new Multi-Topology-Aware Port Capability Sub-TLVs are required 273 for the purpose of fair share AF appointment - Fair Share Sub-TLV and 274 AF Affinity VLAN Set Sub-TLV. 276 9.1 Fair Share Sub-TLV 278 Fair Share Sub-TLV is used to advertise the number of shares 279 configured in the RBridge. Number of shares is a two octet value. 280 When an RBridge advertises zero shares, it is not assigned any AF. 282 +-+-+-+-+-+-+-+-+ 283 | Type | (1 byte) 284 +-+-+-+-+-+-+-+-+ 285 | Length | (1 byte) 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Number of Shares | (2 bytes) 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 9.2 AF Affinity VLAN Set Sub-TLV 292 AF Affinity VLAN Set Sub-TLV is used to advertise the AF Affinity 293 VLAN set configured in an RBridge. It is a facsimile of the Enabled- 294 VLANs sub-TLV. 296 +-+-+-+-+-+-+-+-+ 297 | Type | (1 byte) 298 +-+-+-+-+-+-+-+-+ 299 | Length | (1 byte) 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | RESV | Start VLAN ID | (2 bytes) 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | VLAN bit-map.... 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 9.3 Partial VLANs Appointing Sub-TLV 308 As discussed in [RFC6439] section 2.2.3, the size of hello imposes a 309 limit on the distribution of AF info in AF Sub-TLV by the DRB. The 310 nature of the algorithm means that the AF appointment information 311 could be disjoint. If the number of VLANs on a shared link is too 312 high, all AF appointments cannot be accommodated in a single hello 313 using the start end mechanism of AF Sub-TLV. In such case, the DRB 314 should appoint one RBridge (possibly itself) as AF for all VLANs. 316 Alternatively, the AF information can be sent in a bitmap rather than 317 start-end mechanism as suggested in AF Sub-TLV. For this purpose the 318 Partial VLANs Appointing Sub-TLV suggested in Adaptive VLAN 319 Assignment draft [VlanAsn] can be used. 321 10 Security Considerations 323 This document raises no new security issues for IS-IS. 325 11 IANA Considerations 327 This document suggests two additional Sub-TLV to Multi-Topology-Aware 328 Port Capability TLV apart from the reuse of Partial VLANs Appointing 329 Sub-TLV from Adaptive VLAN Assignment draft. 331 o Fair Share Sub-TLV 332 o AF Affinity VLAN Set Sub-TLV 334 12 References 336 12.1 Normative References 338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 [RFC6325] R. Perlman, D. Eastlake, et al, "RBridges: Base Protocol 342 Specification", RFC 6325, July 2011. 344 [RFC6326] D. Eastlake, A. Banerjee, et al, "Transparent 345 Interconnection of Lots of Links (TRILL) Use of IS-IS", RFC 346 6326, July 2011. 348 [RFC6439] D. Eastlake, R. Perlman, et al, "Routing Bridges 349 (RBridges): Appointed Forwarders", RFC 6439, November 2011. 351 [RBisisb] D. Eastlake, A. Banerjee, et al, "Transparent 352 Interconnection of Lots of Links (TRILL) Use of IS-IS", 353 draft-eastlake-isis-rfc6326bis-09.txt, work in progress. 355 12.2 Informative References 357 [VlanAsn] M.Zhang and D.Zhang, "Adaptive VLAN Assignment for Data 358 Center RBridges", draft-zhang-trill-vlan-assign-04.txt, 359 work in progress. 361 Authors' Addresses 363 Kesava Vijaya Krupakaran 364 Dell 365 Olympia Technology Park, 366 Guindy Chennai 600 032 368 Phone: +91 44 4220 8496 369 Email: Kesava_Vijaya_Krupak@Dell.com 371 Janardhanan Pathangi 372 Dell 373 Olympia Technology Park, 374 Guindy Chennai 600 032 376 Phone: +91 44 4220 8459 377 Email: Pathangi_Janardhanan@Dell.com