The problem statement of RBridge edge group state synchronization
draft-hao-trill-rb-syn-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Hao Weiguo , Yizhou Li | ||
| Last updated | 2013-01-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hao-trill-rb-syn-00
TRILL Weiguo Hao
Yizhou Li
Internet Draft Huawei Technologies
Intended status: Standards Track January 16, 2013
Expires: July 2013
The problem statement of RBridge edge group state synchronization
draft-hao-trill-rb-syn-00.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 time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
Hao & Li Expires July 16, 2013 [Page 1]
Internet-Draft problem statement of RBridge edge group January 2013
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 July 16, 2013.
Copyright Notice
Copyright (c) 2013 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, and
node/link failure detection. To address these problems, a
communication protocol among members of a virtual RBridge group
should be provided. Requirements for this protocol is also discussed.
Hao & Li Expires July 16, 2013 [Page 2]
Internet-Draft problem statement of RBridge edge group January 2013
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
4. Requirements for communication protocol in RBv ............. 10
5. Security Considerations..................................... 12
6. IANA Considerations ........................................ 12
7. References ................................................. 12
7.1. Normative References................................... 12
7.2. Informative References................................. 13
8. Acknowledgments ............................................ 14
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.
Hao & Li Expires July 16, 2013 [Page 3]
Internet-Draft problem statement of RBridge edge group January 2013
+------+
| CEx |
+------+
|
+------+
|(RBx) |
+------+
|
-------------------
/ \
| |
| 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
Hao & Li Expires July 16, 2013 [Page 4]
Internet-Draft problem statement of RBridge edge group January 2013
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.
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.
Hao & Li Expires July 16, 2013 [Page 5]
Internet-Draft problem statement of RBridge edge group January 2013
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.
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.
RB: Router Bridge. RBs are a switch that implement implement the
TRILL protocol and combine the advantages of bridges and routers.
CMT: Coordinated Multicast Trees.
LAG: Link Aggregation, as specified in [8021AX].
LACP: Link Aggregation Control Protocol.
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.
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
Hao & Li Expires July 16, 2013 [Page 6]
Internet-Draft problem statement of RBridge edge group January 2013
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. 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 TRILL VLAN-x Appointed Forwarder, TRILL Hello protocol
specified in [RFC6325] is used for DRB election and for VLAN-x AFs
appointment on those ports. Pseudo-nickname can be dynamic allocated
by DRB and be notified to other member RBs through TRILL Hello. For
LAG multi-homed access scenario, as there is no HELLOs on LAG 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 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.
Hao & Li Expires July 16, 2013 [Page 7]
Internet-Draft problem statement of RBridge edge group January 2013
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.
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.
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.
Hao & Li Expires July 16, 2013 [Page 8]
Internet-Draft problem statement of RBridge edge group January 2013
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.
- 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
Hao & Li Expires July 16, 2013 [Page 9]
Internet-Draft problem statement of RBridge edge group January 2013
- 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.
- 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 (~ 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.
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
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
Hao & Li Expires July 16, 2013 [Page 10]
Internet-Draft problem statement of RBridge edge group January 2013
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.
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.
Hao & Li Expires July 16, 2013 [Page 11]
Internet-Draft problem statement of RBridge edge group January 2013
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.
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.
Hao & Li Expires July 16, 2013 [Page 12]
Internet-Draft problem statement of RBridge edge group January 2013
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.
[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.
7.2. Informative References
[RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
Systems", RFC 6165, April 2011.
Hao & Li Expires July 16, 2013 [Page 13]
Internet-Draft problem statement of RBridge edge group January 2013
[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
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
Hao & Li Expires July 16, 2013 [Page 14]