idnits 2.17.1 draft-zhang-trill-dvlan-auto-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 date (January 9, 2013) is 4124 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: 'RFC2119' is mentioned on line 112, but not defined ** Obsolete normative reference: RFC 6327 (Obsoleted by RFC 7177) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mingui Zhang 3 Intended Status: Proposed Standard Liangliang Ma 4 Expires: July 13, 2013 Xudong Zhang 5 Huawei 6 January 9, 2013 8 Auto-Configuration of Designated VLANs 9 draft-zhang-trill-dvlan-auto-02.txt 11 Abstract 13 When RBridges are connected by a bridge LAN link, they need to select 14 out a Designated VLAN to be used for PDU exchange and TRILL data 15 forwarding. 17 This document specifies an approach for RBridges to automatically 18 determine a Designated VLAN on a LAN link for default configured 19 RBridges. When a DVLAN has to be changed for the sake of a better 20 connectivity of a LAN link, RBridges can change their Designated VLAN 21 with least traffic interruption according to the soft Designated VLAN 22 change method. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Designated VLAN Determination . . . . . . . . . . . . . . . . . 3 65 2.1. Designated VLAN for Most RBridges . . . . . . . . . . . . . 3 66 2.2. DVLAN Initialization . . . . . . . . . . . . . . . . . . . 4 67 3. Soft DVLAN Change . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Backup DVLAN . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.2. Adjacency on Backup DVLAN . . . . . . . . . . . . . . . . . 6 70 3.3. DVLAN Change Restriction . . . . . . . . . . . . . . . . . 7 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 76 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Designated VLAN (DVLAN) plays an important role in both TRILL 81 protocol operations and data forwarding. According to [RFC6325] and 82 [RFC6327], the DVLAN of a link is determined by the desired DVLAN of 83 the DRB on this link. The desired DVLAN of an RBridge is usually 84 manually configured by operators. If the desired DVLAN is not 85 configured on an RBridge, its DVLAN is set to be the numerically 86 lowest enabled VLAN ID, which is VLAN 1 for a default configuration 87 RBridge [RFC6325]. TRILL frames except some TRILL Hellos are sent on 88 a LAN link out tagged with the Designated VLAN. 90 This document specifies an approach for default configured RBridges 91 on a link to automatically select a DVLAN. Under the circumstance 92 that an RBrdige joins in a link whose DVLAN is not enabled on the 93 attaching port of this RBridge while the intersection of enabled 94 VLANs of this RBridge and the other RBridges connected by this link 95 is non-empty, a DVLAN change of this link is necessary for the 96 interconnection of these RBridges. The soft DVLAN change approach 97 specified in this document enable RBridges to establish backup 98 adjacencies for a backup DVLAN in advance. Then the DVLAN can be 99 changed to the backup DVLAN without waiting for the time-consuming 100 adjacency transition processes, therefore RBridges can shift their 101 DVLAN with least traffic interruption. 103 Familiarity with [RFC6325], [RFC6327] is assumed in this document. As 104 in [RFC6325], in this document the word "link" means a "bridged LAN", 105 unless otherwise qualified. 107 1.1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Designated VLAN Determination 115 According to [RFC6327], the desired Designated VLAN SHOULD be 116 manually configured for each RBridge by operators. The desired DVLAN 117 of the DRB becomes the DVLAN for the local link. If the desired DVLAN 118 of the DRB is not configured, by default, the desired DVLAN will be 119 set to be the enabled VLAN of the DRB with the numerically lowest ID. 120 This section offers a substitute approach for DRB to automatically 121 elect a DVLAN on a local link when its desired DVLAN is not 122 configured. The desired DVLAN can therefore be selected adaptively 123 according to the practical VLAN configuration of RBridges on a link. 125 2.1. Designated VLAN for Most RBridges 126 Through the exchange of TRILL-Hello frames, the DRB can figure out 127 which VLAN is enabled by the largest number of its neighbors on a 128 local link. If there are more than one such VLAN IDs, they are 129 compared as unsigned integers with the smaller magnitude being 130 considered higher priority. According to this "Most Enabled VLAN 131 First (MEVF)" policy, a VLAN will be selected as the desired DVLAN of 132 the DRB. Take Figure 2.1 as an example. RB1 is the elected DRB on the 133 local link. VLAN 20 is enabled on all the three RBridges while VLAN 134 10 is enabled only on two RBridges, RB1 and RB2. RB1 should announce 135 in its Hellos that VLAN 20 is its desired DVLAN. 137 The policy to choose the VLAN supported by most RBridges achieves the 138 best connectivity of a local link. If the DVLAN is determined 139 arbitrarily, this best connectivity cannot be guaranteed. For 140 example, in Figure 2.1, if RB1 is configured to use VLAN 10 as its 141 desired DVLAN, RB3 will be disconnected from the local link. 143 +---+ +---+ 144 DRB|RB2| |RB3| 145 +-+-+ +-+-+ 146 |VLAN 10,20 |VLAN 10,20 147 | | 148 -----+----------+-----------+---------- 149 | 150 |VLAN 20 151 +-+-+ 152 |RB1| 153 +---+ 155 Figure 2.1: VLAN Configuration of RBridges on a Local Link 157 2.2. DVLAN Initialization 159 If desired DVLAN is configured on an RBridge port, this RBridge MUST 160 announce this configured DVLAN as its desired DVLAN in its TRILL 161 Hellos. Nevertheless, if desired DVLAN is not configured, the desired 162 DVLAN will be determined adaptively according to the following 163 process. 165 When an RBridge port comes up and its desired DVLAN is not 166 configured, it will wait for two Hello intervals before it announces 167 its desired DVLAN to other neighbors. According to [RFC6325], this 168 RBridge will consider itself to be DRB on that port before a TRILL- 169 Hello from a higher priority RBridge is received. After two Hello 170 intervals, the DRB should have been elected on the link the port 171 attached to. The DRB should have figured out which VLAN should be 172 designated for the local link according to the policy defined in 173 Section 2.1. This DRB will begin to set that VLAN as its desired 174 designated VLAN and announce it in its subsequent Hellos, which will 175 cause other RBridges on the local link set their DVLANs as the DRB 176 desired. 178 3. Soft DVLAN Change 180 When a new RBridge RBi joins in a local link and its enabled VLAN set 181 does not include the DVLAN in use, it cannot establish connectivity 182 with other RBridges on this link. It is possible that the set of 183 enabled VLANs of RBi has a non-null intersection with the set of 184 enabled VLANs of all the other RBridges. The connectivity can be 185 established if the DRB change its DVLAN to be one of this 186 intersection. Since the desired DVLAN of DRB is manually configured 187 in conventional TRILL, operators have to be involved to reconfigure 188 the desired DVLAN of the DRB. If the DVLAN is changed in this way, 189 all the adjacencies of the local link will move out from the Report 190 state and it may take a long time for all these adjacencies to move 191 to Report state again. This means an interruption to the TRILL Data 192 forwarding of the local link [RFC6327]. 194 This section aims to provide a substitute approach for RBridges to 195 shift their DVLAN with least traffic interruption. 197 3.1. Backup DVLAN 199 When RBi joins in the local link and announces its enabled VLANs 200 which do not list the DVLAN being used on this link. The DRB knows a 201 DVLAN change is needed in order to establish connectivity with RBi. 202 It need to figure out which VLAN should be used as the new DVLAN 203 according to MEVF policy. The DRB should never choose a VLAN as the 204 new DVLAN if there is any RBridge on the local link except RBi that 205 does not enable this DVLAN. In other words, when a DRB need to change 206 the DVLAN in order to achieve the connectivity to an RBridge that 207 joins the local link, it should not break the existing connectivity 208 of an RBridge on the local link due to the DVLAN change. 210 Before the DRB really shifts to this new DVLAN, this DVLAN will be 211 treated as a backup DVLAN. The following sub-TLV is used by the DRB 212 to notify its neighbors the backup DVLAN. 214 +-+-+-+-+-+-+-+-+ 215 | Type = B-DVLAN| (1 byte) 216 +-+-+-+-+-+-+-+-+ 217 | Length | (1 byte) 218 +---------------+---------------+ 219 | DRB Nickname | (2 bytes) 220 +-------------------------------+ 221 | Port ID | (2 bytes) 222 +-------------------------------+ 223 | Backup DVLAN | (2 bytes) 224 +-------------------------------+ 226 Figure 3.1: Sub-TLV for backup DVLAN 228 o Type: The Backup Designated VLAN TLV. 230 o Length: 6 bytes. 232 o DRB Nickname: The nickname of the Designated RBridge of the local 233 link. 235 o Port ID: The port ID of the DRB connecting the local link. 237 o Backup DVLAN: The DVLAN that the DRB will shift to. 239 3.2. Adjacency on Backup DVLAN 241 When RBridges on the local link receives Hellos with the B-DVLAN sub- 242 TLV, they MUST begin to create and maintain backup states of 243 adjacencies with other neighbors on the local link according to the 244 adjacency state machinery defined in Section 3 of [RFC6327], using 245 the backup DVLAN as the DVLAN. All other RBridges on this link should 246 add the SNPA of the attached port of RBi as a nexthop, which will 247 open up an entry in the adjacency table of all other RBridges. RBi 248 should also add entries in its adjacency table for the other 249 RBridges. TRILL Hello frames out tagged with the DVLAN will be tagged 250 with the backup DVLAN as well. However, a backup adjacency will not 251 be announced even it moves to the Report state. The TRILL data 252 forwarding in progress on the local link will not be interrupted. The 253 report of backup adjacencies will be postponed until the DRB change 254 the backup DVLAN as its desired DVLAN. 256 When all the backup states of adjacencies move to the Report state, 257 the DRB begins to send out Hellos with the backup DVLAN as its 258 desired DVLAN. This will trigger all RBridges on the local link 259 change to use the backup DVLAN as the new DVLAN and the backup 260 adjacencies are announced in LSPs. Since the backup adjacencies are 261 established in advance and can be announced in LSPs immediately after 262 the DVLAN shift take place, the time-consuming adjacency transitions 263 are avoided. RBridges on the local link do not have to set the non- 264 Designated VLAN Hello Holding timer and Designated VLAN Hello Holding 265 timer as that in Section 4.2.3 of [RFC6327]. 267 3.3. DVLAN Change Restriction 269 A DRB should make a DVLAN change only for the sake of increasing 270 TRILL campus connectivity. The following event SHOULD be a certain 271 event when the DRB makes the DVLAN change. 273 S0. The DRB receives a TRILL Hello (other an A0 event [RFC6327]) 274 that is not on the DVLAN and the DVLAN is not included in 275 this TRILL Hello while the intersection of Enabled VLANs of 276 all RBridges on the local link is non-empty. 278 Therefore, under the event that an RBridge is physically disconnected 279 from a local link, the DRB will not trigger a DVLAN change. 281 When an RBridge joins a local link and this RBridge has a higher 282 priority to be the DRB of current DRB, this will cause a change in 283 DRB. Under such circumstance, the current DRB should refrain from 284 DVLAN change. 286 4. Security Considerations 288 This document raises no new security issues for IS-IS. 290 5. IANA Considerations 292 IANA is requested to create a new registry in IIH for the B-DVLAN 293 sub-TLV defined in Section 3.1. 295 6. References 297 6.1. Normative References 299 [RFC6325] R. Perlman, D. Eastlake, et al, "RBridges: Base Protocol 300 Specification", RFC 6325, July 2011. 302 [RFC6327] D. Eastlake, R. Perlman, et al, "Routing Bridges 303 (RBridges): Adjacency", RFC 6327, July 2011. 305 6.2. Informative References 307 None. 309 Author's Addresses 311 Mingui Zhang 312 Huawei Technologies Co.,Ltd 313 Huawei Building, No.156 Beiqing Rd. 314 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 315 Beijing 100095 P.R. China 317 Email: zhangmingui@huawei.com 319 Liangliang Ma 320 Huawei Technologies Co.,Ltd 321 Huawei Building, No.156 Beiqing Rd. 322 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 323 Beijing 100095 P.R. China 325 Email: maliangliang@huawei.com 327 Xudong Zhang 328 Huawei Technologies Co.,Ltd 329 Huawei Building, No.156 Beiqing Rd. 330 Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, 331 Beijing 100095 P.R. China 333 Email: zhangxudong@huawei.com