Internet DRAFT - draft-hao-trill-rb-syn
draft-hao-trill-rb-syn
TRILL Weiguo Hao
Yizhou Li
Liang Xia
Internet Draft Huawei Technologies
HJ. Zhai
ZTE Corporation
Intended status: Standards Track June 06, 2014
Expires: December 2014
The problem statement of RBridge edge group state synchronization
draft-hao-trill-rb-syn-03.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November 10,
2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
Hao & Li Expires December 05, 2014 [Page 1]
Internet-Draft problem statement of RBridge edge group June 2014
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 6, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
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.
Abstract
In TRILL multi-homing scenario, the concept of virtual RBridge in
[TRILLPN], was introduced to address the MAC flip-flopping problem at
remote RBridges. Based on virtual RBridge mechanism, Coordinated
Multicast Trees (CMT) solution in [CMT] was introduced to solve the
related RPF issues. In this document, additional problems are
described regarding virtual Bridges members' state synchronization in
multi-homing scenario, including virtual RBridge membership auto
discovery, pseudo-nickname static configuration consistency check,
dynamic pseudo-nickname allocation, CMT configuration
synchronization ,LACP configuration and state synchronization,
node/link failure detection, MAC table synchronization, DHCP snooping
information, and dynamically joined VLANs and multicast groups. To
Hao & Li Expires December 6, 2014 [Page 2]
Internet-Draft problem statement of RBridge edge group June 2014
address these problems, a communication protocol among members of a
virtual RBridge group should be provided. Requirements for this
protocol are also discussed.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document............................ 5
3. Problem Statement ........................................... 6
3.1. RBv membership configuration and state synchronization...6
3.2. CMT configuration and state synchronization .............7
3.3. LACP configuration and state synchronization ............8
3.4. MAC table synchronization.............................. 10
3.5. Dynamic VLAN and multicast group table synchronization..11
3.6. DHCP snooping table synchronization ....................11
4. Requirements for communication protocol in RBv ..............11
5. Security Considerations..................................... 14
6. IANA Considerations ........................................ 14
7. References ................................................. 14
7.1. Normative References................................... 14
7.2. Informative References................................. 15
8. Acknowledgments ............................................ 15
1. Introduction
TRILL (Transparent Interconnection of Lots of Links) presented
in[RFC6325] and other related documents, provides methods of
utilizing all available paths for active forwarding with minimum
configuration. TRILL utilizes IS-IS (Intermediate System to
Intermediate System) as its control plane and encapsulates native
frames with a TRILL header.
+------+
| CEx |
+------+
|
+------+
|(RBx) |
+------+
|
Hao & Li Expires December 6, 2014 [Page 3]
Internet-Draft problem statement of RBridge edge group June 2014
-------------------
/ \
| |
| TRILL Campus |
| |
\ /
--------------------
| | |
-------- | --------
| | |
+------+ +------+ +------+
|(RB1) | |(RB2) | | (RBk)|
+------+ +------+ +------+
| | | |
| --------- ------ |
| | LAG1 LAG2 | |
+------+ +------+
| CE1 | | CE2 |
+------+ +------+
Figure 1 Reference Topology
In order to improve the reliability of connection to TRILL network ,
CE devices typically are multi-homed to edge RBridges and treat all
of the uplinks as a single Link Aggregation (LAG) bundle [802.1AX] in
the scenario shown by Figure 1. In this scenario, When remote RBridge
RBx receives a frame originated by CE1, the ingress RBridge maybe
either one of the edge RBridges i.e. RB1 or RB2. The learning on RBx
for source MAC will flip-flop between RB1's and RB2's nicknames. In
[TRILLPN], the concept of Virtual RBridge, along with its pseudo-
nickname, is introduced to address the MAC flip-flopping problem in
remote RBridges.
A Virtual RBridge (RBv) represents a group of different ports on
different edge RBridges, on which these RBridges provide end-station
service to a set of their attached CE devices. After joining RBv,
such an RBridge port is called a member port of RBv, and such an
RBridge becomes a member RBridge of RBv. In an RBridge RBv is
identified by its virtual nickname in TRILL campus, and virtual
nickname is also referred to as pseudo-nickname in this specification.
Hao & Li Expires December 6, 2014 [Page 4]
Internet-Draft problem statement of RBridge edge group June 2014
An RBridge port can join at most one RBv at any time, but different
ports on the same RBridge can join the same RBv or different RBvs.
After joining an RBv, such a port becomes a member port of the RBv,
and the RBridge becomes a member RBridge of the RBv.
Furthermore, for a member RBridge, it MUST move out of RBv and clear
the RBv's information from its self-originated LSPs when it loses the
last member port from this group, due to port down, configuration,
and etc.
Based on the concept of Virtual RBridge and pseudo-nickname,
Coordinated Multicast Trees (CMT) [CMT] solution was introduced to
solve the related RPF issues. In CMT solution, different member
RBridges are assigned different distribution trees for forwarding the
multi-destination TRILL data frames that using RBv's pseudo-nickname
as ingress nickname in their TRILL header.
When a member RBridge joins into or leaves from a virtual RBridge
group RBv due to its last member ports up/down or its configuration
changing, the distribution trees assigned to different member
RBridges may change.
For TRILL multi-homing scenario, pseudo-nickname and CMT is not
sufficient to provide a complete solution. Additional problems such
as RBv membership management, LACP configuration and state
synchronization, node and access link failure detection, and etc
still exist. This draft is going to talk about those problem in more
details.
2. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
Hao & Li Expires December 6, 2014 [Page 5]
Internet-Draft problem statement of RBridge edge group June 2014
TRILL: Transparent Interconnection of Lots of Links. TRILL presented
in [RFC6325] and other related documents, provides methods of
utilizing all available paths for active forwarding, with minimum
configuration. TRILL utilizes IS-IS (Intermediate System to
Intermediate System) as its control plane and encapsulates native
frames with a TRILL header.
CE: Classical Ethernet device, that is a device that performs
forwarding based on 802.1Q bridging. This also can be end-station or
a server.
CMT: Coordinated Multicast Trees.
LACP: Link Aggregation Control Protocol.
LAG: Link Aggregation, as specified in [8021AX].
RB: Router Bridge. RBs are a switch that implements the TRILL
protocol and combine the advantages of bridges and routers.
3. Problem Statement
For TRILL multi-homing scenario, the following problems should be
addressed:
3.1. RBv membership
configuration and state
synchronization
A Virtual RBridge (RBv) is identified by its virtual nickname
referred as pseudo-nickname in [PSEUDO-NICK]. RBv must allow static
member configuration by network operator.
If each member of RBv statically configures its RBridge ports with a
pseudo-nickname, the pseudo-nickname should be consistent among all
member RBridges in RBv. Communication protocol between member
RBridges should be provided to ensure pseudo-nickname configuration
consistency in RBv. Member RBridges in RBv should notify each other
to find if conflict of pseudo-nickname configuration exists when
pseudo-nickname is configured. For example:
The RBridges configured with same pseudo-nickname are not in the same
LACP group.
The Rbridges configured in the same LACP group don't have the same
pseudo-nickname.
Hao & Li Expires December 6, 2014 [Page 6]
Internet-Draft problem statement of RBridge edge group June 2014
If conflict exists, It is recommended to send trap to network
management system (NMS) and let operator modify configuration to
eliminate conflict. Only when the conflict is removed, each member
RBridge can advertises the RBv's pseudo-nickname using the nickname
sub-TLV [rfc6326bis], along with its regular nickname(s), in its LSPs.
The communication protocol is an inter-chassis communication protocol
among RBridges in RBv to synchronize configuration and/or running
state data. The communication protocol should run over TRILL campus
to accommodate multi-hop interconnection among member RBridges in RBv.
To simplify configuration of pseudo-nickname, dynamic pseudo-nickname
allocation through communication protocol should be allowed. For LAG
multi-homed access scenario, as no Hello running on LAG member
ports RBv membership auto-discovery and pseudo-nickname dynamic
allocation are not achievable using the Hello based mechanism. Some
new method is required for such purpose. One of the potential
ways[TRILLPN] is to use the member communication protocol as follows.
As all member RBridges in RBv can exchange message through TRILL
campus although there is no HELLOs on LAG access port side, dynamic
pseudo-nickname allocation can be accomplished through communication
protocol over TRILL campus. The member RBridges in RBv select one RB
as DRB and let DRB assign pseudo-nickname dynamically. After pseudo-
nickname is allocated, each member RBridge in RBv can advertises the
RBv's pseudo-nickname in its LSPs.
3.2. CMT configuration and
state synchronization
CMT configuration should be synchronized between RBridges in RBv to
ensure different member RBridges assigned to different distribution
trees. If different RBridges in one RBv associate the same virtual
RBridge as their child in the same tree or trees, conflict occurs and
there should be a mechanism to remove the conflict. It is recommended
to send trap to NMS if conflict occurs. Network operator may manually
eliminate the conflict by modify configurations. Automatic mechanism
should also be provided to remove the conflict. After the conflict is
removed in local RBv, RBridges can advertise Affinity sub-TLVs to
trill campus.
If RBv membership changes when a member RBridges joins or leaves RBv,
each member RBridge in the RBv should do configuration consistency
check first. If no conflict is found or the conflict had been removed,
each member RBridge in the RBv recalculates the multi-destination
tree assignment and advertises the related trees using Affinity sub-
TLV.
Hao & Li Expires December 6, 2014 [Page 7]
Internet-Draft problem statement of RBridge edge group June 2014
For member RBridges node and link (all member link of LAG) failure,
other RBridges in the RBv should detect as soon as possible to
achieve fast failure recovery. Upon member RBridges node and link(all
member link of LAG) failure detection, other member RBridges in the
RBv will recalculate the multi-destination tree assignment and
advertise the related trees using Affinity sub-TLV.
So for CMT, communication protocol between member RBridges also
should be provided to achieve CMT configuration synchronization,
conflict elimination, node and link failure detection, and RBv
membership auto-discovery. Note that all these mechanisms SHOULD be
included in the CMT solution by itself. But they can also be provided
by the general communication channel for simplicity and robustness.
3.3. LACP configuration and
state synchronization
In IEEE802.1AX standard The Link Aggregation Control Protocol (LACP)
provides a standardized means for exchanging information between
Partner Systems on a link to allow their Link Aggregation Control
instances to reach agreement on the identity of the Link Aggregation
Group to which the link belongs, move the link to that Link
Aggregation Group, and enable its transmission and reception
functions in an orderly manner. The aggregated ports in one LAG are
located on one switch and cann't be located on two different switches
or chassis' in different locations. since IEEE802.1AX Link
Aggregation is only defined for a single system, the redundancy is
limited to a point to point connection between two devices and a
complete system failure on one end will bring down the LAG.
In the scenario that CE multi-homing to multiple RBridges in a edge
group link aggregation groups spanning two or multiple systems
should be provided. The standard as defined in IEEE802.1AX doesn't
provide for this. To support CE multi-homing with multi-chassis
Ethernet bundles, [802.1AX] LACP state should be synchronized or
shared between these systems. This ensures that the RBs can present a
single LACP bundle to the CE. This is required for initial system
bring-up and upon any configuration change.
Just similar to the description in [EVPN],at least the following LACP
specific configuration parameters should be synchronized amongst RBs
in RBv:
- System Identifier (MAC Address): uniquely identifies a LACP
speaker.
Hao & Li Expires December 6, 2014 [Page 8]
Internet-Draft problem statement of RBridge edge group June 2014
- System Priority: determines which LACP speaker's port
priorities are used in the Selection logic.
- Aggregator Identifier: uniquely identifies a bundle withina LACP
speaker.
- Aggregator MAC Address: identifies the MAC address of the
bundle.
- Aggregator Key: used to determine which ports can join an
Aggregator.
- Port Number: uniquely identifies an interface within a LACP
speaker.
- Port Key: determines the set of ports that can be bundled.
- Port Priority: determines a port's precedence level to join
a bundle in case the number of eligible ports exceeds the
maximum number of links allowed in a bundle.
Furthermore, the RBs should also synchronize operational (run-time)
data, in order for the LACP Selection logic state-machines to
execute. This operational data includes the following LACP
operational parameters, on a per port basis:
- Partner System Identifier: this is the CE System MAC address.
- Partner System Priority: the CE LACP System Priority
- Partner Port Number: CE's AC port number.
- Partner Port Priority: CE's AC Port Priority.
- Partner Key: CE's key for this AC.
- Partner State: CE's LACP State for the AC.
Hao & Li Expires December 6, 2014 [Page 9]
Internet-Draft problem statement of RBridge edge group June 2014
- Actor State: RB's LACP State for the AC.
- Port State: RB's AC port status.
The operational state needs to be communicated between RBs forming a
multi-chassis bundle during LACP initial bringup, upon any
configuration change and upon the occurrence of a failure.
If member RBridge of the virtual RBridge group has any node failure,
other RBridges of the group should invoke the Selection Logic and
select new SELECTED port. The failure detection timer is critical to
failure recovery performance. It is desired to achieve sub-second
detection of node failure (about 50 - 150 msec) in order to ensure
application SLA(service level agreement).
Upon detection of local link failure, RB1 in the RBv should notify
other RBs in the RBv immediately. Then other RBs in the RBv should
invoke the Selection Logic and select new SELECTED port as well.
Immediate notification of access-link state(up/down etc) changes
should also be provided to accomplish fast failure recovery. In other
words, the transmission of messages carrying link state of the LAG
should be on-demand rather than timer-based to minimize inter-chassis
state synchronization delay.
3.4. MAC table
synchronization
In active-active access scenario, virtual RBridge(RBv), along with
its pseudo-nickname(s), is introduced to address MAC flip-flopping on
remote RBridges. However, the RBv mechanism may cause new problems in
frame forwarding as described in [ESADI-EX]. For example, in Figure1
above native traffic from CE1 to CEx will enter a TRILL campus
through RB1 in an RBv, but the reverse traffic (i.e., traffic from
CEx to CE1) leaves the TRILL campus through RB2 in this RBv. Then RB1
loses the chance to learn where CEx is in data plane. If RB1 has no
other ways to get the location of CEx, it will have to always treat
the traffic from CE1 to CEx as unknown unicast traffic and flood it
to TRILL campus. Always flooding such traffic adds additional
forwarding burden on TRILL network. Thus, the learnt remote MAC
addresses SHOULD be shared among all member RBridges in an RBv. With
the shared information, RB1 can unicast traffic from CE1 to CEx
through the TRILL campus.
In addition to remote MAC addresses sharing, the local attached end
station MAC addresses should also be shared among all member RBridges
in an RBv. For example, native frames from CE1 to CEx will enter the
TRILL campus through one member RBridge of the RBv, such as RB1 in
Hao & Li Expires December 6, 2014 [Page 10]
Internet-Draft problem statement of RBridge edge group June 2014
Figure 1, so RB1 has CE1's MAC address; but with regard to traffic
returns from CEx to CE1, the traffic may be through RB2. If RB2
doesn't know the MAC address of ES1, it will always flood that to all
local access link. Always flooding such traffic consumes too much
link bandwidth and adds addition burden to local CEs.
To reduce flooding due to unknown unicast, MAC table that includes
local attached end station MAC addresses and remote MAC addresses
learnt from remote RBridges should be synchronized among all member
RBridges in an RBv. Communication protocol among member RBridges in
an RBv should be provided to satisfy the requirement.
3.5. Dynamic VLAN and
multicast group table
synchronization
To avoid duplicated frame from remote RBridges, VLAN and multicast
group based Designated Forwarder(DF) election [draft-hao-trill-dup-
avoidance-active-active-00] should be introduced for each MC-LAG,
only one RBridge in a edge group can forward the multicast traffic
from TRILL network to local CE. If VLANs is dynamically enabled
through VLAN registration protocol (VRP) (GVRP or MVRP), VLANs
enabled on for each MC-LAG should be synchronized among all RBridges
in a edge group. Similarly, If a CE dynamically joins a multicast
group through IGMP or MLD protocol, the multicast group should be
synchronized among all RBridges in a edge group. Each RBridge in a
edge group uses same algorithm to get consistent DF election result
per VLAN or per multicast group.
3.6. DHCP snooping table
synchronization
To harden the security on the LAN network, DHCP snooping feature is
normally enabled on edge RBs. With DHCP snooping, the physical
location of hosts can be tracked, only the IP addresses assigned for
the hosts can be used, only the authorized DHCP servers are
accessible. DHCP snooping can prevent attackers from adding their own
DHCP servers to the network. DHCP snooping allows only clients with
specific IP/MAC addresses to have access to the network. The
information tracked with DHCP snooping procedures should be
synchronized among edge RBs to ensure security.
4. Requirements for communication protocol in RBv
In summary, a communication protocol between member RBridges in RBv
should be provided to accomplish multi-homing access model. The
communication protocol is restricted to RBridge nodes in RBv edge
Hao & Li Expires December 6, 2014 [Page 11]
Internet-Draft problem statement of RBridge edge group June 2014
group and is used for configuration and state synchronization. It is
expected that LSP would not be used for this purpose since it may
cause campus wide fluctuation. Local behavior is preferred. After
member RBridges in RBv discover each other and establish connection
between each other, they can proceed with further state and
configuration synchronization which are addressed in the following
point.
The communication should accommodate multi-hop interconnection
between RBridges over TRILL campus. Because RBridges in RBv cann't
exchange information over access link of LAG, so RBridges in RBv
should exchange information over TRILL campus. The suggested control
channel for communication between member RBridges in RBv to exchange
state and configuration information is RBridge channel. Each member
RBridge establish connection to other RBridges of same RBv over
RBridge channel. This assumes that resiliency mechanisms are in place
to protect the route to the remote RBridge nodes, and hence loss of
TRILL data layer reachability to a given node can only mean that the
node itself has failed.
The communication protocol should satisfy the following requirements:
1. Support RBv membership static configuration and auto-discovery. A
mechanism that enables RB nodes to manage their RBv Membership
should be defined. RBv membership auto-discovery can simplify
configuration of RBv. After member RBridges in RBv discover each
other and establish connection between each other, the state and
configuration can be synchronized among them which are discussed
in the following point.
2. Support consistency check for static pseudo-nickname configuration
consistency. The pseudo-nickname configured on each member
RBridges in RBv should be same. If conflict exists, It is
recommended to send trap to NMS and let operator modify
configuration to eliminate conflict. Only when the conflict is
removed, each member RBridge in RBv can advertises the RBv's
pseudo-nickname in its LSPs.
3. Support dynamic pseudo-nickname allocation. To simplify
configuration of pseudo-nickname, dynamic pseudo-nickname
allocation through communication protocol should be allowed. After
pseudo-nickname is allocated, each member RBridge in RBv can
advertises the RBv's pseudo-nickname in its LSPs.
Hao & Li Expires December 6, 2014 [Page 12]
Internet-Draft problem statement of RBridge edge group June 2014
4. Support CMT configuration synchronization and conflict elimination.
CMT configuration should be synchronized in RBv to ensure
different member RBridges are assigned different distribution
trees. If conflict occurs, i.e. one tree is used by more than one
members, It is recommended to send trap to NMS. Conflict
elimination can rely on operator or automatic mechanism. After the
conflict is removed in local RBv, RBridges advertise Affinity
sub-TLVs to trill campus.
5. Support fast node failure detection. Upon detection other member
RBridges node failure, RBridges in RBv should invoke LACP re-
selection Logic and CMT re-calculation algorithm.
The communication protocol can either define its own keepAlive
mechanism for purpose of node failure detection or reuse existing
fault detection mechanisms. BFD over TRILL and TRILL OAM for RB
reachability monitoring are existing fault detection mechanisms
and may be used to detect RBridges node failure.
6. Support fast link failure detection. When a member RBridge in RBv
detects a failure of its access link, it should send an link
failure notification message immediately to inform other member
RBridges. Other member RBridges in RBv should invoke LACP re-
selection Logic and CMT re-calculation algorithm similar to node
failure process.
7. Support LACP configuration and state synchronization. To support
CE multi-homing with multi-chassis Ethernet bundles, LACP state
should be synchronized or shared between these systems. For CE
device, all RBridges in virtual RBridge group simulate one LACP
end system and perform same LACP selection logic. Member RBridges
in RBv can use RBridge channel as control channel to exchange LACP
configuration and state synchronization between each other.
8. Support MAC table synchronization. To reduce flooding due to
unknown unicast, communication protocol between member RBridges
should be provided to synchronize MAC table among all member
RBridges in an RBv.
9. Support Dynamic VLAN and multicast group table synchronization.
Dynamically joined VLANs and multicast groups on a edge RB should
be synchronized to other RBridges in a edge group.
Hao & Li Expires December 6, 2014 [Page 13]
Internet-Draft problem statement of RBridge edge group June 2014
10.Support DHCP snooping table synchronization. The information
tracked with DHCP snooping procedures on each edge RBridge should
be synchronized to other edge RBs in a edge group to ensure
security.
Additional requirements considerations such as flow-control, reliable
and in-order message delivery, and etc are being discussed.
5. Security Considerations
This document does not change the general TRILL security
considerations of the TRILL base protocol.
In the scenario where the members of an RBv are located in different
physical locations and connected over TRILL campus, transport
security between devices in an RBv should be provided with secure
authentication mechanism built into the communication protocol.
6. IANA Considerations
If RBridge channel is used for control channel of communication
protocol in RBv, then IANA is requested to allocate the new RBridge
channel protocol codes.
7. References
7.1. Normative References
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "TRILL Use of IS-IS", RFC 6326, July 2011.
[6326bis] Eastlake, D. et.al., ''Transparent Interconnection of Lots
of Links (TRILL) Use of IS-IS'', draft-eastlake-isisrfc6326bis-
07.txt, Work in Progress, December 2011.
[RFC6439] Eastlake, D. et.al., ''RBridge: Appointed Forwarder'', RFC
6439, November 2011.
Hao & Li Expires December 6, 2014 [Page 14]
Internet-Draft problem statement of RBridge edge group June 2014
[TRILLChannel] - Eastlake, D., V. Manral, Y. Li, S. Aldrin, D. Ward,
"RBridges: RBridge Channel Support in TRILL", draft-ietftrill-
rbridge-channel, work in progress.
[RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
6327, July 2011
[TRILLPN] Zhai,H., et.al ''RBridge: Pseudonode Nickname'', draft-hu-
trill-pseudonode-nickname, Work in progress, November 2011.
[TRILL-CMT] " Coordinated Multicast Trees (CMT) for TRILL ", draft-
ietf-trill-cmt-01, November 2012.
[8021AX] IEEE, ''Link Aggregration'', 802.1AX-2008, 2008.
[EVPN] " BGP MPLS Based Ethernet VPN ", draft-ietf-l2vpn-evpn-02,
October 2012.
[ESADI-EX] Zhai,H., et.al '' RBridge: ESADI-Extension'', draft-zhai-
trill-esadi-extension-for-rbv-00, Work in progress, October 2012.
7.2. Informative References
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
[802.1D] "IEEE Standard for Local and metropolitan area networks
/Media Access Control (MAC) Bridges", 802.1D-2004, 9 June
2004.
8. Acknowledgments
The authors wish to acknowledge the important contributions of
Changbao Liu, Donald EastLake, Mingui Zhang.
Authors' Addresses
Weiguo Hao
Hao & Li Expires December 6, 2014 [Page 15]
Internet-Draft problem statement of RBridge edge group June 2014
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Liang Xia(Frank)
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56624539
Email: frank.xialiang@huawei.com
Hongjun Zhai
ZTE Corporation
68 Zijinghua Road, Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: zhai.hongjun@zte.com.cn
Hao & Li Expires December 6, 2014 [Page 16]
