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]