INTERNET-DRAFT Mingui Zhang Intended Status: Proposed Standard Liangliang Ma Expires: July 13, 2013 Xudong Zhang Huawei January 9, 2013 Auto-Configuration of Designated VLANs draft-zhang-trill-dvlan-auto-02.txt Abstract When RBridges are connected by a bridge LAN link, they need to select out a Designated VLAN to be used for PDU exchange and TRILL data forwarding. This document specifies an approach for RBridges to automatically determine a Designated VLAN on a LAN link for default configured RBridges. When a DVLAN has to be changed for the sake of a better connectivity of a LAN link, RBridges can change their Designated VLAN with least traffic interruption according to the soft Designated VLAN change method. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Mingui Zhang, et al Expires July 13, 2013 [Page 1] INTERNET-DRAFT DVLAN Auto-Configuration January 9, 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Designated VLAN Determination . . . . . . . . . . . . . . . . . 3 2.1. Designated VLAN for Most RBridges . . . . . . . . . . . . . 3 2.2. DVLAN Initialization . . . . . . . . . . . . . . . . . . . 4 3. Soft DVLAN Change . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Backup DVLAN . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Adjacency on Backup DVLAN . . . . . . . . . . . . . . . . . 6 3.3. DVLAN Change Restriction . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Mingui Zhang, et al Expires July 13, 2013 [Page 2] INTERNET-DRAFT DVLAN Auto-Configuration January 9, 2013 1. Introduction Designated VLAN (DVLAN) plays an important role in both TRILL protocol operations and data forwarding. According to [RFC6325] and [RFC6327], the DVLAN of a link is determined by the desired DVLAN of the DRB on this link. The desired DVLAN of an RBridge is usually manually configured by operators. If the desired DVLAN is not configured on an RBridge, its DVLAN is set to be the numerically lowest enabled VLAN ID, which is VLAN 1 for a default configuration RBridge [RFC6325]. TRILL frames except some TRILL Hellos are sent on a LAN link out tagged with the Designated VLAN. This document specifies an approach for default configured RBridges on a link to automatically select a DVLAN. Under the circumstance that an RBrdige joins in a link whose DVLAN is not enabled on the attaching port of this RBridge while the intersection of enabled VLANs of this RBridge and the other RBridges connected by this link is non-empty, a DVLAN change of this link is necessary for the interconnection of these RBridges. The soft DVLAN change approach specified in this document enable RBridges to establish backup adjacencies for a backup DVLAN in advance. Then the DVLAN can be changed to the backup DVLAN without waiting for the time-consuming adjacency transition processes, therefore RBridges can shift their DVLAN with least traffic interruption. Familiarity with [RFC6325], [RFC6327] is assumed in this document. As in [RFC6325], in this document the word "link" means a "bridged LAN", unless otherwise qualified. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Designated VLAN Determination According to [RFC6327], the desired Designated VLAN SHOULD be manually configured for each RBridge by operators. The desired DVLAN of the DRB becomes the DVLAN for the local link. If the desired DVLAN of the DRB is not configured, by default, the desired DVLAN will be set to be the enabled VLAN of the DRB with the numerically lowest ID. This section offers a substitute approach for DRB to automatically elect a DVLAN on a local link when its desired DVLAN is not configured. The desired DVLAN can therefore be selected adaptively according to the practical VLAN configuration of RBridges on a link. 2.1. Designated VLAN for Most RBridges Mingui Zhang, et al Expires July 13, 2013 [Page 3] INTERNET-DRAFT DVLAN Auto-Configuration January 9, 2013 Through the exchange of TRILL-Hello frames, the DRB can figure out which VLAN is enabled by the largest number of its neighbors on a local link. If there are more than one such VLAN IDs, they are compared as unsigned integers with the smaller magnitude being considered higher priority. According to this "Most Enabled VLAN First (MEVF)" policy, a VLAN will be selected as the desired DVLAN of the DRB. Take Figure 2.1 as an example. RB1 is the elected DRB on the local link. VLAN 20 is enabled on all the three RBridges while VLAN 10 is enabled only on two RBridges, RB1 and RB2. RB1 should announce in its Hellos that VLAN 20 is its desired DVLAN. The policy to choose the VLAN supported by most RBridges achieves the best connectivity of a local link. If the DVLAN is determined arbitrarily, this best connectivity cannot be guaranteed. For example, in Figure 2.1, if RB1 is configured to use VLAN 10 as its desired DVLAN, RB3 will be disconnected from the local link. +---+ +---+ DRB|RB2| |RB3| +-+-+ +-+-+ |VLAN 10,20 |VLAN 10,20 | | -----+----------+-----------+---------- | |VLAN 20 +-+-+ |RB1| +---+ Figure 2.1: VLAN Configuration of RBridges on a Local Link 2.2. DVLAN Initialization If desired DVLAN is configured on an RBridge port, this RBridge MUST announce this configured DVLAN as its desired DVLAN in its TRILL Hellos. Nevertheless, if desired DVLAN is not configured, the desired DVLAN will be determined adaptively according to the following process. When an RBridge port comes up and its desired DVLAN is not configured, it will wait for two Hello intervals before it announces its desired DVLAN to other neighbors. According to [RFC6325], this RBridge will consider itself to be DRB on that port before a TRILL- Hello from a higher priority RBridge is received. After two Hello intervals, the DRB should have been elected on the link the port attached to. The DRB should have figured out which VLAN should be designated for the local link according to the policy defined in Section 2.1. This DRB will begin to set that VLAN as its desired Mingui Zhang, et al Expires July 13, 2013 [Page 4] INTERNET-DRAFT DVLAN Auto-Configuration January 9, 2013 designated VLAN and announce it in its subsequent Hellos, which will cause other RBridges on the local link set their DVLANs as the DRB desired. 3. Soft DVLAN Change When a new RBridge RBi joins in a local link and its enabled VLAN set does not include the DVLAN in use, it cannot establish connectivity with other RBridges on this link. It is possible that the set of enabled VLANs of RBi has a non-null intersection with the set of enabled VLANs of all the other RBridges. The connectivity can be established if the DRB change its DVLAN to be one of this intersection. Since the desired DVLAN of DRB is manually configured in conventional TRILL, operators have to be involved to reconfigure the desired DVLAN of the DRB. If the DVLAN is changed in this way, all the adjacencies of the local link will move out from the Report state and it may take a long time for all these adjacencies to move to Report state again. This means an interruption to the TRILL Data forwarding of the local link [RFC6327]. This section aims to provide a substitute approach for RBridges to shift their DVLAN with least traffic interruption. 3.1. Backup DVLAN When RBi joins in the local link and announces its enabled VLANs which do not list the DVLAN being used on this link. The DRB knows a DVLAN change is needed in order to establish connectivity with RBi. It need to figure out which VLAN should be used as the new DVLAN according to MEVF policy. The DRB should never choose a VLAN as the new DVLAN if there is any RBridge on the local link except RBi that does not enable this DVLAN. In other words, when a DRB need to change the DVLAN in order to achieve the connectivity to an RBridge that joins the local link, it should not break the existing connectivity of an RBridge on the local link due to the DVLAN change. Before the DRB really shifts to this new DVLAN, this DVLAN will be treated as a backup DVLAN. The following sub-TLV is used by the DRB to notify its neighbors the backup DVLAN. Mingui Zhang, et al Expires July 13, 2013 [Page 5] INTERNET-DRAFT DVLAN Auto-Configuration January 9, 2013 +-+-+-+-+-+-+-+-+ | Type = B-DVLAN| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +---------------+---------------+ | DRB Nickname | (2 bytes) +-------------------------------+ | Port ID | (2 bytes) +-------------------------------+ | Backup DVLAN | (2 bytes) +-------------------------------+ Figure 3.1: Sub-TLV for backup DVLAN o Type: The Backup Designated VLAN TLV. o Length: 6 bytes. o DRB Nickname: The nickname of the Designated RBridge of the local link. o Port ID: The port ID of the DRB connecting the local link. o Backup DVLAN: The DVLAN that the DRB will shift to. 3.2. Adjacency on Backup DVLAN When RBridges on the local link receives Hellos with the B-DVLAN sub- TLV, they MUST begin to create and maintain backup states of adjacencies with other neighbors on the local link according to the adjacency state machinery defined in Section 3 of [RFC6327], using the backup DVLAN as the DVLAN. All other RBridges on this link should add the SNPA of the attached port of RBi as a nexthop, which will open up an entry in the adjacency table of all other RBridges. RBi should also add entries in its adjacency table for the other RBridges. TRILL Hello frames out tagged with the DVLAN will be tagged with the backup DVLAN as well. However, a backup adjacency will not be announced even it moves to the Report state. The TRILL data forwarding in progress on the local link will not be interrupted. The report of backup adjacencies will be postponed until the DRB change the backup DVLAN as its desired DVLAN. When all the backup states of adjacencies move to the Report state, the DRB begins to send out Hellos with the backup DVLAN as its desired DVLAN. This will trigger all RBridges on the local link change to use the backup DVLAN as the new DVLAN and the backup adjacencies are announced in LSPs. Since the backup adjacencies are established in advance and can be announced in LSPs immediately after Mingui Zhang, et al Expires July 13, 2013 [Page 6] INTERNET-DRAFT DVLAN Auto-Configuration January 9, 2013 the DVLAN shift take place, the time-consuming adjacency transitions are avoided. RBridges on the local link do not have to set the non- Designated VLAN Hello Holding timer and Designated VLAN Hello Holding timer as that in Section 4.2.3 of [RFC6327]. 3.3. DVLAN Change Restriction A DRB should make a DVLAN change only for the sake of increasing TRILL campus connectivity. The following event SHOULD be a certain event when the DRB makes the DVLAN change. S0. The DRB receives a TRILL Hello (other an A0 event [RFC6327]) that is not on the DVLAN and the DVLAN is not included in this TRILL Hello while the intersection of Enabled VLANs of all RBridges on the local link is non-empty. Therefore, under the event that an RBridge is physically disconnected from a local link, the DRB will not trigger a DVLAN change. When an RBridge joins a local link and this RBridge has a higher priority to be the DRB of current DRB, this will cause a change in DRB. Under such circumstance, the current DRB should refrain from DVLAN change. 4. Security Considerations This document raises no new security issues for IS-IS. 5. IANA Considerations IANA is requested to create a new registry in IIH for the B-DVLAN sub-TLV defined in Section 3.1. 6. References 6.1. Normative References [RFC6325] R. Perlman, D. Eastlake, et al, "RBridges: Base Protocol Specification", RFC 6325, July 2011. [RFC6327] D. Eastlake, R. Perlman, et al, "Routing Bridges (RBridges): Adjacency", RFC 6327, July 2011. 6.2. Informative References None. Mingui Zhang, et al Expires July 13, 2013 [Page 7] INTERNET-DRAFT DVLAN Auto-Configuration January 9, 2013 Author's Addresses Mingui Zhang Huawei Technologies Co.,Ltd Huawei Building, No.156 Beiqing Rd. Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, Beijing 100095 P.R. China Email: zhangmingui@huawei.com Liangliang Ma Huawei Technologies Co.,Ltd Huawei Building, No.156 Beiqing Rd. Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, Beijing 100095 P.R. China Email: maliangliang@huawei.com Xudong Zhang Huawei Technologies Co.,Ltd Huawei Building, No.156 Beiqing Rd. Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District, Beijing 100095 P.R. China Email: zhangxudong@huawei.com Mingui Zhang, et al Expires July 13, 2013 [Page 8]