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]