< draft-yizhou-trill-tc-awareness-02.txt   draft-yizhou-trill-tc-awareness-03.txt >
TRILL Working Group Yizhou Li TRILL Working Group Yizhou Li
Internet Draft Weiguo Hao Internet Draft Weiguo Hao
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Jon Hudson Jon Hudson
Brocade Brocade
Naveen Nimmu Naveen Nimmu
Broadcom Broadcom
Anoop Ghanwani Anoop Ghanwani
DELL DELL
Expires: January 2014 May 2, 2013 Expires: May 25, 2014 November 21, 2013
Aware Spanning Tree Topology Change on RBridges Aware Spanning Tree Topology Change on RBridges
draft-yizhou-trill-tc-awareness-02.txt draft-yizhou-trill-tc-awareness-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on November 2, 2013. This Internet-Draft will expire on May 21, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
When a local LAN running spanning tree protocol connecting to TRILL When a local LAN running spanning tree protocol connecting to TRILL
campus via more than one RBridge, there are several ways to perform campus via more than one RBridge, there are several ways to perform
loop avoidance. One of them illustrated by RFC6325 [RFC6325] A.3 was loop avoidance. One of them illustrated by RFC6325 [RFC6325] A.3 was
to make relevant ports on edge RBridges involving in spanning tree to make relevant ports on edge RBridges involving in spanning tree
calculation. When edge RBridges are emulated as a single highest calculation. When edge RBridges are emulated as a single highest
priority root, the local bridged LAN will be naturally partitioned priority root, the local bridged LAN will be naturally partitioned
after running spanning tree protocol. This approach achieves better after running spanning tree protocol. This approach achieves better
link utilization and intra-VLAN load balancing in some scenarios. link utilization and intra-VLAN load balancing in some scenarios.
This document describes how the edge RBridges react to topology This document describes how the edge RBridges react to topology
change occurring in bridged LAN in order to make the abovementioned change occurring in bridged LAN in order to make the abovementioned
spanning tree approach function correct. spanning tree approach function correct.
Table of Contents Table of Contents
1. Introduction ................................................ 3 1. Introduction ............................................. 3
1.1. Motivations ............................................ 5 1.1. Motivations ......................................... 5
2. Conventions used in this document............................ 6 2. Conventions used in this document ........................ 6
3. BPDU RBridge Channel and TLVs................................ 6 3. BPDU RBridge Channel and TLVs ............................ 6
3.1. BPDU TLV ............................................... 7 3.1. BPDU TLV ............................................ 7
3.2. Authentication Information TLV.......................... 7 3.2. Authentication Information TLV ...................... 7
4. Operations .................................................. 8 4. Operations ............................................... 8
4.1. Sending BPDU using RBridge channel ......................9 4.1. Sending BPDU using RBridge channel .................. 9
4.2. Receiving BPDU in RBridge channel...................... 10 4.2. Receiving BPDU in RBridge channel................... 10
4.3. Informing the remote site.............................. 11 4.3. Informing the remote site .......................... 11
5. Security Considerations..................................... 13 5. Security Considerations ................................. 13
6. IANA Considerations ........................................ 13 6. IANA Considerations ..................................... 13
7. References ................................................. 13 7. References .............................................. 13
7.1. Normative References................................... 13 7.1. Normative References ............................... 13
7.2. Informative References................................. 14 7.2. Informative References.............................. 14
8. Acknowledgments ............................................ 14 8. Acknowledgments ......................................... 14
1. Introduction 1. Introduction
The TRILL protocol [RFC6325] provides the appointed forwarder The TRILL protocol [RFC6325] provides the appointed forwarder
mechanism [RFC6439] for loop avoidance where, for part of the loop, mechanism [RFC6439] for loop avoidance where, for part of the loop,
the frame would be in TRILL encapsulated format, for example in the the frame would be in TRILL encapsulated format, for example in the
scenario shown by Figure 1. Only one of the RBridges is responsible scenario shown by Figure 1. Only one of the RBridges is responsible
for encapsulating/decapsulating a given VLAN's data frames on a link. for encapsulating/decapsulating a given VLAN's data frames on a link.
Bridges in the local bridged LAN runs normal spanning tree protocol Bridges in the local bridged LAN runs normal spanning tree protocol
for local loop avoidance. RBridges keeps track of the root bridge by for local loop avoidance. RBridges keeps track of the root bridge by
listening to BPDUs received on the local port. This information is listening to BPDUs received on the local port. This information is
reported per VLAN by the RBridge in its LSP and is used to detect a reported per VLAN by the RBridge in its LSP and is used to detect a
root bridge change. Root bridge changes trigger the reset of the root bridge change. Root bridge changes trigger the reset of the
inhibition timer of the appointed forwarder. When an RBridge ceases inhibition timer of the appointed forwarder. When an RBridge ceases
to be appointed forwarder for a VLAN on a port, it sends topology to be appointed forwarder for a VLAN on a port, it sends topology
change BPDUs to purge the MAC table on local bridged LAN switches. An change BPDUs to purge the MAC table on local bridged LAN switches.
RBridge conformable to [RFC6325] never encapsulates or forwards any An RBridge conformable to [RFC6325] never encapsulates or forwards
BPDU frame it receives. any BPDU frame it receives.
------------------ ------------------
/ \ / \
| Trill Network | | Trill Network |
\ / \ /
------------------ ------------------
| | | |
DRB| | DRB| |
+------+ +------+ +------+ +------+
AF --->| RB1 | | RB2 | AF --->| RB1 | | RB2 |
skipping to change at page 4, line 26 skipping to change at page 4, line 26
end stations on local bridged LAN can be separated into multiple end stations on local bridged LAN can be separated into multiple
VLANs VLANs
4. Configure the RBridges to be like one STP tree root in local 4. Configure the RBridges to be like one STP tree root in local
bridged LAN. The RBridge ports that are connected to the bridged bridged LAN. The RBridge ports that are connected to the bridged
LAN send spanning tree configuration BPDUs. Then the bridged LAN LAN send spanning tree configuration BPDUs. Then the bridged LAN
is forced into partitions. Figure 2 shows its network topology. is forced into partitions. Figure 2 shows its network topology.
Method 1 and 2 highly depends on the network topology and equipment Method 1 and 2 highly depends on the network topology and equipment
types and therefore have very limited applicability. Method 3 and 4 types and therefore have very limited applicability. Method 3 and 4
have broader applicability. Method 4 is more applicable than method 3 have broader applicability. Method 4 is more applicable than method
if all end stations in bridged LAN are on the same VLAN or intra VLAN 3 if all end stations in bridged LAN are on the same VLAN or intra
load balancing is required to avoid per VLAN congestion and VLAN load balancing is required to avoid per VLAN congestion and
suboptimal routing. The traffic discontinuity was caused by suboptimal routing. The traffic discontinuity was caused by
inhibition timer setting in case of root change in method 3. Proper inhibition timer setting in case of root change in method 3. Proper
timeout value has to be carefully chosen for tradeoff between timeout value has to be carefully chosen for tradeoff between
unnecessary traffic continuity and potential loop. Method 4 unnecessary traffic continuity and potential loop. Method 4
eliminates the requirement of setting inhibition timer in case of eliminates the requirement of setting inhibition timer in case of
root change. Therefore method 4 is considered as a very common root change. Therefore method 4 is considered as a very common
practice in real deployment. practice in real deployment.
------------------ ------------------
/ \ / \
skipping to change at page 6, line 7 skipping to change at page 6, line 7
RB1 & RB2 use the same bridge ID to emit spanning tree BPDUs as the RB1 & RB2 use the same bridge ID to emit spanning tree BPDUs as the
highest priority root Bx. All bridges in LAN see RB1 and RB2 as a highest priority root Bx. All bridges in LAN see RB1 and RB2 as a
single tree root. Therefore B1-B2 and B2-B3 links are blocked for single tree root. Therefore B1-B2 and B2-B3 links are blocked for
loop avoidance by the spanning tree protocol. RB1 and RB2 will not loop avoidance by the spanning tree protocol. RB1 and RB2 will not
receive TRILL-Hello from each other. Bridged LAN is logically receive TRILL-Hello from each other. Bridged LAN is logically
partitioned into two parts. RB1 is DRB and AF for all VLANs in left partitioned into two parts. RB1 is DRB and AF for all VLANs in left
partition and RB2 is DRB and AF in right partition. partition and RB2 is DRB and AF in right partition.
If B1-B3 link fails for some reason, alternate port p2 on B3 will If B1-B3 link fails for some reason, alternate port p2 on B3 will
send topology change (TC) BPDU to B2 as RSTP specifies [802.1D]. B2- send topology change (TC) BPDU to B2 as RSTP specifies [802.1D]. B2-
B3 link will start forwarding frames. TC BPDU is then sent from B2 to B3 link will start forwarding frames. TC BPDU is then sent from B2
RB2. As RB2 never forwards BPDU frame to TRILL campus, left partition to RB2. As RB2 never forwards BPDU frame to TRILL campus, left
has no way to know the topology change. Therefore B4 will not able to partition has no way to know the topology change. Therefore B4 will
correctly purge the MACs learnt from port p1 for end stations not able to correctly purge the MACs learnt from port p1 for end
connected to B3. MAC table entry aging is the last resort in this stations connected to B3. MAC table entry aging is the last resort
case. In addition, a remote end station may keep sending traffic to in this case. In addition, a remote end station may keep sending
an end station connected to B3 via RB1-B1 which causes frame loss. traffic to an end station connected to B3 via RB1-B1 which causes
Therefore some mechanism must be introduced to purge the MACs learned frame loss. Therefore some mechanism must be introduced to purge the
both in the left partition of the bridged LAN and at the remote MACs learned both in the left partition of the bridged LAN and at
Rbridges when topology changes. the remote Rbridges when topology changes.
This draft proposes to use RBridge channel [TRILLChannel] to tunnel This draft proposes to use RBridge channel [TRILLChannel] to tunnel
the TC BPDU to solve the issue. It complements Appendix A.3 of the TC BPDU to solve the issue. It complements Appendix A.3 of
RFC6325 to improve correctness and efficiency. RFC6325 to improve correctness and efficiency.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
This document uses the terminologies defined in [RFC6325] along with This document uses the terminologies defined in [RFC6325] along with
the following: the following:
Root Bridge Group - A group of RBridges acting as an emulated single Root Bridge Group - A group of RBridges acting as an emulated single
tree root in a spanning tree instance in local bridged LAN. The group tree root in a spanning tree instance in local bridged LAN. The
has at least two RBridges. group has at least two RBridges.
3. BPDU RBridge Channel and TLVs 3. BPDU RBridge Channel and TLVs
A new channel protocol is defined to carry BPDU. A new channel protocol is defined to carry BPDU.
Channel protocol code: TBD (BPDU) Channel protocol code: TBD (BPDU)
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
RBridge Channel Header: RBridge Channel Header:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RBridge Channel Ethertype | | RBridge Channel Ethertype |
skipping to change at page 7, line 25 skipping to change at page 7, line 25
| Domain ID | reserved | | Domain ID | reserved |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. TLVs . . TLVs .
. . . .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3 RBridge Channel Format for BPDU Figure 3 RBridge Channel Format for BPDU
Domain ID: Unique ID to identify a single spanning tree domain. Domain ID: Unique ID to identify a single spanning tree domain.
Reserved: 4 bits reserved field. Reserved: 4 bits reserved field.
The fields of TRILL header and inner Ethernet header SHOULD be set as The fields of TRILL header and inner Ethernet header SHOULD be set
per [TRILLChannel] unless specified in this draft. as per [TRILLChannel] unless specified in this draft.
3.1. BPDU TLV 3.1. BPDU TLV
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type= | (1 byte) | Type= | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BPDU | (variable length) | BPDU | (variable length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 27 skipping to change at page 8, line 27
Auth Value: Value used to authenticate the RBridge Channel BPDU Auth Value: Value used to authenticate the RBridge Channel BPDU
Specific Information using the algorithm specified by Auth Mode Specific Information using the algorithm specified by Auth Mode
This TLV is used for channel message authentication. When an RBridge This TLV is used for channel message authentication. When an RBridge
receives a channel message with Authentication Information, it MUST receives a channel message with Authentication Information, it MUST
discard it if the Authentication Value is incorrect. discard it if the Authentication Value is incorrect.
4. Operations 4. Operations
Figure 4 shows TC BPDU tunneled from RB2 to RB1 using RBridge Channel. Figure 4 shows TC BPDU tunneled from RB2 to RB1 using RBridge
Channel.
------------------------- -------------------------
/ \ / \
/ \ / \
| Trill Network | | Trill Network |
| | | |
| +---------------+ | | +---------------+ |
| | 4.tunnel BPDU | | | | 4.tunnel BPDU | |
| | in channel | | | | in channel | |
\ | +-----------+ | / \ | +-----------+ | /
skipping to change at page 10, line 7 skipping to change at page 10, line 7
4.1. Sending BPDU using RBridge channel 4.1. Sending BPDU using RBridge channel
In figure 4, when B1-B3 link fails, alternate port p2 on B3 will In figure 4, when B1-B3 link fails, alternate port p2 on B3 will
start to send TC BPDU and go to forwarding state. RB2 receives TC start to send TC BPDU and go to forwarding state. RB2 receives TC
BPDU from B2 sequentially. RB2 encapsulates the TC BPDU in RBridge BPDU from B2 sequentially. RB2 encapsulates the TC BPDU in RBridge
channel and sends it to RB1. channel and sends it to RB1.
Interested VLANs and Spanning Tree Roots Sub-TLV [RFC6326] carries Interested VLANs and Spanning Tree Roots Sub-TLV [RFC6326] carries
spanning tree root bridge IDs seen for all ports for which the spanning tree root bridge IDs seen for all ports for which the
RBridge is the appointed forwarder for a VLAN. As RB1 and RB2 use the RBridge is the appointed forwarder for a VLAN. As RB1 and RB2 use
same bridge ID and that bridge ID is the spanning tree root, RB1 and the same bridge ID and that bridge ID is the spanning tree root, RB1
RB2 are considered as in a root bridge group. Static configuration of and RB2 are considered as in a root bridge group. Static
root bridge group is also allowed. configuration of root bridge group is also allowed.
When RBridge receives TC BPDU from an access port, it tunnels the When RBridge receives TC BPDU from an access port, it tunnels the
frame to all the other RBridges in the same root bridge group using frame to all the other RBridges in the same root bridge group using
RBridge channel protocol specified in section 3. Normally the number RBridge channel protocol specified in section 3. Normally the number
of RBridges in a root bridge group is limited, say 2 or 3; such of RBridges in a root bridge group is limited, say 2 or 3; such
tunneling is performed using TRILL unicast encapsulation. N members tunneling is performed using TRILL unicast encapsulation. N members
in a root bridge group results in N-1 sequential unicast BPDU in a root bridge group results in N-1 sequential unicast BPDU
tunneled. In figure 4, RB2 knows RB1 is in the same root bridge group tunneled. In figure 4, RB2 knows RB1 is in the same root bridge
from LSP exchange; hence RB2 uses RB1's nickname as egress nickname group from LSP exchange; hence RB2 uses RB1's nickname as egress
and encapsulates the TC BPDU in RBridge channel. M bit in TRILL nickname and encapsulates the TC BPDU in RBridge channel. M bit in
header SHOULD be 0. TRILL header SHOULD be 0.
If TRILL Campus was partitioned temporarily in some unusual cases, If TRILL Campus was partitioned temporarily in some unusual cases,
RBridges in the same root bridge group may not reach each other. For RBridges in the same root bridge group may not reach each other. For
instance, if RB2 was not able to reach RB1 through TRILL campus at instance, if RB2 was not able to reach RB1 through TRILL campus at
some transition period due to network fault, RB1 would not receive some transition period due to network fault, RB1 would not receive
the tunneled TC BPDU from RB2. Then the approach illustrated in this the tunneled TC BPDU from RB2. Then the approach illustrated in this
document will take effect again only after RB1 and RB2 connectivity document will take effect again only after RB1 and RB2 connectivity
via TRILL recovers from the network fault. via TRILL recovers from the network fault.
It is possible to statically configure a root bridge group, especial It is possible to statically configure a root bridge group, especial
when network is relatively small and stable. Therefore when an when network is relatively small and stable. Therefore when an
RBridge tunnels the TC BPDU to other members in the same root bridge RBridge tunnels the TC BPDU to other members in the same root bridge
group, it has to make sure the destination is reachable. group, it has to make sure the destination is reachable.
If edges RBridges configured in the same root bridge group connect to If edges RBridges configured in the same root bridge group connect
separate TRILL campus intentionally, it is not recommended to use to separate TRILL campus intentionally, it is not recommended to use
spanning tree partition mechanism and such root bridge group spanning tree partition mechanism and such root bridge group
provisioning is normally considered as mis-configuration. provisioning is normally considered as mis-configuration.
4.2. Receiving BPDU in RBridge channel 4.2. Receiving BPDU in RBridge channel
When an RBridge receives a TC BPDU from RBridge channel, it When an RBridge receives a TC BPDU from RBridge channel, it
determines the frame was sent from an RB in the same root bridge determines the frame was sent from an RB in the same root bridge
group. Then RBridge decapsulates the frame and sends the original TC group. Then RBridge decapsulates the frame and sends the original TC
BPDU to its local bridged LAN. TC BPDU will be flooded throughout the BPDU to its local bridged LAN. TC BPDU will be flooded throughout
access ports configured as the same domain ID specified by BPDU the access ports configured as the same domain ID specified by BPDU
RBridge channel in the left partition to purge MAC table of bridges. RBridge channel in the left partition to purge MAC table of bridges.
4.3. Informing the remote site 4.3. Informing the remote site
When local topology changes, the correspondence of end station and When local topology changes, the correspondence of end station and
its attaching RBridge cached by remote RB may become invalid. The its attaching RBridge cached by remote RB may become invalid. The
RBridges who is the appointed forwarder for the specified VLAN in RBridges who is the appointed forwarder for the specified VLAN in
remote sites should be informed to update the stale correspondence remote sites should be informed to update the stale correspondence
table entry. table entry.
skipping to change at page 11, line 30 skipping to change at page 11, line 30
remote to local, remote RBridge will not receive the data frame from remote to local, remote RBridge will not receive the data frame from
local RBridge to refresh its table. Then traffic discontinuity may local RBridge to refresh its table. Then traffic discontinuity may
last for some time until the table entry is aged out at the remote last for some time until the table entry is aged out at the remote
RBridge. RBridge.
A lightweight method is to use RBridge channel to carry MAC purge A lightweight method is to use RBridge channel to carry MAC purge
information. In Figure 4, When RB2 receives TC BPDU from B2, it information. In Figure 4, When RB2 receives TC BPDU from B2, it
derives the corresponding VLAN list. For example, if MSTP is used, derives the corresponding VLAN list. For example, if MSTP is used,
RB2 will get the VLAN IDs in the same MSTP instance as TC BPDU. RB2 RB2 will get the VLAN IDs in the same MSTP instance as TC BPDU. RB2
sends out MAC purge information using RBridge channel with VLAN sends out MAC purge information using RBridge channel with VLAN
information and RBidges' nicknames in the same root bridge group. All information and RBidges' nicknames in the same root bridge group.
remote RBridges received MAC purge should clear its MAC-to-nickname All remote RBridges received MAC purge should clear its MAC-to-
correspondence table for entries with the specified nicknames and nickname correspondence table for entries with the specified
VLAN IDs. If no VLAN list is specified, the remote RBridges should nicknames and VLAN IDs. If no VLAN list is specified, the remote
clear the correspondence in all VLANs relevant to the given nicknames. RBridges should clear the correspondence in all VLANs relevant to
The MAC purge is recommended to send on the management VLAN in which the given nicknames. The MAC purge is recommended to send on the
all RBridges joins. management VLAN in which all RBridges joins.
A new channel protocol code for MAC purge should be defined as A new channel protocol code for MAC purge should be defined as
follows. follows.
| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RBridge Channel | | RBridge Channel |
| Header | | Header |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Number of nicknames | nickname 1 | | Number of nicknames | nickname 1 |
skipping to change at page 12, line 32 skipping to change at page 12, line 32
| End.VLAN | | | End.VLAN | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Other Start/End VLAN list ... | | Other Start/End VLAN list ... |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. TLVs . . TLVs .
. . . .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 5 RBridge Channel Format for MAC Purge Figure 5 RBridge Channel Format for MAC Purge
Number of nicknames: number of the following nicknames, which will be Number of nicknames: number of the following nicknames, which will
used by the receivers to purge their relevant MAC-to-nickname be used by the receivers to purge their relevant MAC-to-nickname
correspondence table entries. correspondence table entries.
Num of VLAN blocks: number of the following VLAN block. A VLAN block Num of VLAN blocks: number of the following VLAN block. A VLAN block
is specified by a start and an end VLAN IDs. When start and end VLAN is specified by a start and an end VLAN IDs. When start and end VLAN
IDs are the same, it implies only one VLAN ID is in the block. When IDs are the same, it implies only one VLAN ID is in the block. When
number of VLAN block is 0, it implies no VLAN ID is specified. number of VLAN block is 0, it implies no VLAN ID is specified.
For any nickname x specified and any VLAN y specified in this TLV, For any nickname x specified and any VLAN y specified in this TLV,
the receivers should purge MAC-to-nickname correspondence table the receivers should purge MAC-to-nickname correspondence table
entries with (any-MAC, VLAN-y, nickname-x). When number of VLAN block entries with (any-MAC, VLAN-y, nickname-x). When number of VLAN
is 0, the receivers should purge entries with (any-MAC, any-VLAN, block is 0, the receivers should purge entries with (any-MAC, any-
nickname-x). VLAN, nickname-x).
Authentication Information TLV specified by section 3.2 can be used Authentication Information TLV specified by section 3.2 can be used
in MAC Purge channel message. in MAC Purge channel message.
5. Security Considerations 5. Security Considerations
This document does not change the general RBridge security This document does not change the general RBridge security
considerations of the TRILL base protocol and TRILL RBridge Channel. considerations of the TRILL base protocol and TRILL RBridge Channel.
See Section 6 of [RFC6325] and section 7 of [TRILLChannel]. See Section 6 of [RFC6325] and section 7 of [TRILLChannel].
Massive TC BPDU may trigger RBridges continuously sending tunneled Massive TC BPDU may trigger RBridges continuously sending tunneled
BPDU and MAC purges. It may cause denial-of-service in TRILL campus. BPDU and MAC purges. It may cause denial-of-service in TRILL campus.
Similar as the traditional bridged LAN running spanning tree, it is Similar as the traditional bridged LAN running spanning tree, it is
suggested to monitor the receiving rate of TC BPDU on bridged LAN suggested to monitor the receiving rate of TC BPDU on bridged LAN
facing port of RBridges. If the receiving rate is beyond the facing port of RBridges. If the receiving rate is beyond the
threshold, RBridge should only process and tunnel the TC BPDU in the threshold, RBridge should only process and tunnel the TC BPDU in the
configured rate. configured rate.
Authentication TLV should be included if risk of injecting forged Authentication TLV should be included if risk of injecting forged
information is a concern. However keeping channel information in this information is a concern. However keeping channel information in
document secret and private is not necessary and is not a requirement. this document secret and private is not necessary and is not a
requirement.
6. IANA Considerations 6. IANA Considerations
IANA is requested to allocate the new channel protocol codes as IANA is requested to allocate the new channel protocol codes as
following. following.
Channel protocol code X1: BPDU Channel protocol code X1: BPDU
Channel protocol code X2: MAC purge Channel protocol code X2: MAC purge
skipping to change at page 14, line 10 skipping to change at page 14, line 10
rfc6326bis-07.txt, Work in Progress, December 2011. rfc6326bis-07.txt, Work in Progress, December 2011.
[RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC [RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC
6439, November 2011. 6439, November 2011.
[TRILLChannel] - Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward, [TRILLChannel] - Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward,
"RBridges: RBridge Channel Support in TRILL", draft-ietf- "RBridges: RBridge Channel Support in TRILL", draft-ietf-
trill-rbridge-channel, work in progress. trill-rbridge-channel, work in progress.
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC and V. Manral, "Routing Bridges (RBridges): Adjacency",
6327, July 2011 RFC 6327, July 2011
[802.1D] "IEEE Standard for Local and metropolitan area networks [802.1D] "IEEE Standard for Local and metropolitan area networks
/Media Access Control (MAC) Bridges", 802.1D-2004, 9 June /Media Access Control (MAC) Bridges", 802.1D-2004, 9 June
2004. 2004.
7.2. Informative References 7.2. Informative References
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011. Systems", RFC 6165, April 2011.
[802.1Q-2011] "IEEE Standard for Local and metropolitan area networks [802.1Q-2011] "IEEE Standard for Local and metropolitan area
/Virtual Bridged Local Area Networks", 802.1Q-2011, 31 Aug networks /Virtual Bridged Local Area Networks", 802.1Q-
2011. 2011, 31 Aug 2011.
8. Acknowledgments 8. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
Appendix: Change History Appendix: Change History
Changes from -01 to -02 Changes from -01 to -02
1. Add domain ID field to BPDU channel message. 1. Add domain ID field to BPDU channel message.
 End of changes. 23 change blocks. 
82 lines changed or deleted 84 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/