TRILL                                                            H. Zhai
Internet-Draft                                                     F. Hu
Intended status: Standards Track                         ZTE Corporation
Expires: January 5, 2012                                  Radia. Perlman
                                                              Intel Labs
                                                    Donald. Eastlake 3rd
                                                       Huawei technology
                                                             Jul 4, 2011


                      RBridge: Pseudonode Nickname
               draft-hu-trill-pseudonode-nickname-00.txt

Abstract

   The Appointed Forwarder on a link for VLAN-x is the RBridge that
   ingresses native frames from the link and egresses native frames to
   the link in VLAN-x.  If the appointed forwarder for an end station is
   changed, the remote data traffic to the end station could fail.  This
   document is proposed to assign a nickname for pseudonode identifying
   a multi-access link to solve the issue.  When any appointed forwarder
   encapsulates a packet, it uses the pseudonode nickname as "ingress
   nickname" rather than its own nickname.  If it does, then if the
   appointed forwarder changes, or the DRB changes, and the pseudonode
   still uses the same nickname, then the remote RBridge caches won't
   need to change, and the data traffic to the end station would reach
   the link uninterruptedly.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 5, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the



Zhai, et al.             Expires January 5, 2012                [Page 1]


Internet-Draft             Pseudonode Nickname                  Jul 2011


   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.


Table of Contents

   1.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Pseudonode Nickname  . . . . . . . . . . . . . . . . . . . . .  4
   3.  LSP Announcement . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Unicast TRILL Data Frames Processing . . . . . . . . . . . . .  5
     4.1.  Ingress processing . . . . . . . . . . . . . . . . . . . .  5
     4.2.  Egress processing  . . . . . . . . . . . . . . . . . . . .  5
       4.2.1.  Unicasting to VLAN-x Forwarder . . . . . . . . . . . .  6
       4.2.2.  Multicasting to VLAN-x forwarder . . . . . . . . . . .  6
       4.2.3.  Comparison . . . . . . . . . . . . . . . . . . . . . .  7
   5.  TLV Extensions for Pseudonode Nickname . . . . . . . . . . . .  8
     5.1.  Pseudonode Nickname Capability in Hellos . . . . . . . . .  8
     5.2.  Pseudonode Nickname TLV  . . . . . . . . . . . . . . . . .  9
       5.2.1.  Pseudonode Nickname TLV in Hellos  . . . . . . . . . . 10
       5.2.2.  Pseudonode Nickname TLV in DRB's LSPs  . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
















Zhai, et al.             Expires January 5, 2012                [Page 2]


Internet-Draft             Pseudonode Nickname                  Jul 2011


1.  Problem Statement

   The IETF TRILL protocol [RFCtrill] provides optimal pair-wise data
   frame forwarding without configuration, safe forwarding even during
   periods of temporary loops, and support for multipathing of both
   unicast and multicast traffic.  TRILL accomplishes this by using
   [IS-IS] [RFC1195] link state routing and encapsulating traffic using
   a header that includes a hop count.  The design supports VLANs and
   optimization of the distribution of multi-destination frames based on
   VLANs and IP derived multicast groups.  Devices that implement TRILL
   are called RBridges.

   The AF (Appointed Forwarder) on a link for VLAN-x is the RBridge that
   ingresses native frames from the link and egresses native frames to
   the link in VLAN-x.  If the appointed forwarder for an end station
   goes down and a different RBridge is appointed as appointed forwarder
   on the link, the end station will not perceive the changes.Therefore,
   the cache in remote RBridge could not be correct until it receives
   the data traffic from the end station, and the traffic from the
   remote RBridge to the end station could fail for a while.  It is even
   worse for the Swap Nickname Field approach in multi-level TRILL
   network, for the egress RBridge of remote level 1 area cannot update
   the correspondence of MAC/VLAN-x and the pair of {ingress nickname,
   swap ingress nickname} until it receives the data traffic from end
   station [MultilevelTrill].

   Pseudonode nickname is proposed in this document to solve the above
   issue.  Pseudonode nickname is assigned by DRB and used to identify a
   multi-access link.  With pseudonode nickname, the data traffic to the
   end station can reach the destination link uninterruptedly and be
   forwarded to the end station by other RBridge even if the appointed
   forwarder for the VLAN on the link is changed.

   The pseudonode nickname is only used in unicast data traffic and not
   used in multicast data traffic in this document.  For the multicast
   data traffic, the data traffic goes through the distribution tree,
   and all the RBridge with the same VLAN can receive the multicast
   traffic.

   This document is organized as following: Section 2 is the concept of
   pseudonode nickname.  Section 3 introduces the LSP announcement
   mechanism for the pseudonode nickname.  Section 4 describes the
   ingress, transit and egress RBridge processing of the TRILL data
   traffic when considering pseudonode nickname.  Section 5 specifies
   pseudonode nickname capability TLV and pseudonode nickname TLV
   format.





Zhai, et al.             Expires January 5, 2012                [Page 3]


Internet-Draft             Pseudonode Nickname                  Jul 2011


2.  Pseudonode Nickname

   Pseudonode nickname is used to identify a link.  It is assigned by
   DRB on the link.  When the RBridge becomes DRB and it doesn't find
   the pseudonode nickname from TRILL Hello of other RBridges, DRB
   assigns and announces a pseudonode nickname in its TRILL Hello on the
   link.  If the new DRB obtains the pseudonode nickname from the TRILL
   Hellos of adjacent RBridges on the link, it reuses this nickname.
   The nickname for the pseudonode should keep unchanged even if the DRB
   or AF changed.

   All the RBridges on the link should support pseudonode nickname,
   otherwise the RBridges that don't understand pseudonode nickname on
   the link cannot forward the encapsulated TRILL frame with pseudonode
   nickname.  Each RBridge on the link announces its pseudonode nickname
   capability in its TRILL Hello.  Only if DRB checks that all the
   adjacencies in Report state support and enable the pseudonode
   nickname capability, DRB assigns pseudonode nickname on the link.  If
   not, DRB MUST NOT announce the pseudonode nickname in its pseudonode
   LSP in the TRILL campus network, otherwise, the remote data traffic
   may be forwarded to the RBridge without pseudonode nickname
   capability, and be discarded in the RBridge.

   The bypass pseudonode bit is used to determine whether DRB should
   generate the pseudonode LSP.  When bypass pseudonode bit is reset,
   the DRB should support pseudonode function and generate the
   pseudonode LSP [TrillAdj].  So if DRB assigns pseudonode nickname on
   the link, the bypass pseudonode bit MUST be reset in its TRILL Hello.


3.  LSP Announcement

   Pseudonode nickname is only announced in the DRB's pseudonode LSP in
   the TRILL Network.  If one of the RBridges on the link is disabled of
   the pseudonode nickname function, that is, DRB receives a TRILL Hello
   without pseudonode nickname capability from the port on the link, the
   pseudonode nickname function should be disabled on the link, and then
   DRB updates its pseudonode LSP which doesn't include pseudonode
   nickname TLV in the TRILL campus network.  While if an RBridge (not
   DRB) supporting pseudonode nickname joins into or exits from the link
   , it is no influence to the pseudonode nickname LSP originated by
   DRB.  If an RBridge is selected as new DRB and the pseudonode
   nickname capability on the link is confirmed, it will generate and
   flood pseudonode LSP including the pseudonode nickname TLV in the
   TRILL campus network.If DRB finds that the pseudonode nickname
   function is disabled on the link, it will updates its pseudonode LSP
   which doesn't include pseudonode nickname TLV in the TRILL campus
   network.



Zhai, et al.             Expires January 5, 2012                [Page 4]


Internet-Draft             Pseudonode Nickname                  Jul 2011


   The pseudonode nickname is participated in path computing.  The
   procedure of path computing of pseudonode nickname is same as the
   routing computing of IPv4 or IPv6 address in layer 3 IS-IS
   network[RFC1195].


4.  Unicast TRILL Data Frames Processing

   The processing of TRILL data frames on ingress and egress RBridges
   will be influenced when the pseudonode nickname capability is enabled
   on the link.  However, the processing on transit RBridges remains
   unchanged.

   Section 4.1 covers the changes of processing TRILL data frames on a
   pseudonode nickname participated ingress RBridge.  Section 4.2
   describes two methods to process TRILL data frames on egress RBridge.

4.1.  Ingress processing

   When a VLAN-x tagged native frame is sent onto a multi-access link,
   only the appointed forwarder for that VLAN-x can ingress this frame
   into TRILL campus.  If the pseudonode nickname capability is enabled
   on the link, the forwarder will encapsulate the frame with a TRILL
   header, where the ingress nickname is the pseudonode nickname rather
   than RBridge's nickname on the link.  The encapsulation of the native
   frame is as same as Section 4.1 in [RFCtrill] except for the ingress
   nickname in TRILL header.

4.2.  Egress processing

   On receiving a unicast TRILL data frame, the egress nickname in the
   TRILL header is examined, and if it is unknown or reserved, the frame
   is discarded.  Then the Inner.VLAN ID, i.e., VLAN-x, is checked.  If
   it is 0x0 or 0xFFF, the frame is discarded.

   This RBridge will be the egress RBridge for the TRILL data frame, if
   the egress nickname is one of the RBridge's nicknames or one of the
   pseudonode nicknames of the connected links.  If the egress RBridge
   is the VLAN-x forwarder on the destination link for this TRILL data
   frame, the frame is processed and the original self-learning is
   performed by this RBridge as described in [RFCtrill].  Otherwise, the
   frame will be re-encapsulated and transmitted on the link by the
   egress RBridge.  Only the VLAN-x forwarder can decapsulate the TRILL
   data frame to native form and forward it to the end station on the
   link, which is consistent with the principle of ingressing and
   egressing native frame into and out of TRILL campus, i.e., there is
   only a single RBridge on each link that is in charge of ingressing
   and egressing native frames from and to that link[TrillAdj].



Zhai, et al.             Expires January 5, 2012                [Page 5]


Internet-Draft             Pseudonode Nickname                  Jul 2011


   There are two methods for the egress to transmit the re-encapsulated
   TRILL data frame to VLAN-x forwarder on the link.  In section 4.2.1,
   the egress unicasts the re-encapsulated TRILL data frame to the
   VLAN-x forwarder, and in 4.2.2, the egress multicasts the TRILL data
   frame on the link.

4.2.1.  Unicasting to VLAN-x Forwarder

   To make the final hop, i.e., the egress RBridge (not VLAN-x
   forwarder), work for a frame addressed to the pseudonode, the
   forwarding table has to be based on {nickname, VLAN}, instead of
   {nickname} currently.  In the couple of {nickname, VLAN}, nickname is
   the pseudonode nickname, and VLAN is the VLAN Id of VLAN-x forwarder
   on this link.  If there are several appointed forwarders, each for a
   VLAN, on this link, several entries exist in the forwarding table,
   each for a forwarder.  In the couple of {nickname, VLAN}, the VLAN
   will be ignored if the nickname is not a pseudonode nickname on one
   of local links, and will be set to invalid value(such as 0x0 or
   0xFFF).  In other words, if the VLAN in an entry is invalid, the
   nickname is not a pseudonode nickname.

   If the RBridge is not VLAN-x forwarder on the link, it goes to its
   forwarding table that says, based on the pseudonode nickname and
   VLAN-x Id, which of its RBridge neighbors, i.e., VLAN-x forwarder on
   this link, to forward to.  The forwarder is identified by the next
   hop MAC address in the found entry from the above table, which is one
   of the unicast MAC addresses on one of its ports connected directly
   on this link.  The TRILL data frame is discarded if no entry is
   found.  Otherwise, the outer frame header of the TRILL data frame is
   stripped, the TRILL header remains unchanged, and a new outer frame
   header is prepended before the frame is forwarded to the VLAN-x
   forwarder on the link.  For the forwarded frame, the Outer.MacSA is
   the MAC address of the transmitting port on the destination link, the
   Ouer.MacDA is the next hop MAC address in the found entry and the
   Outer.VLAN is the designated VLAN on the destination link.

   If the above re-encapsulated TRILL data frame is received by a stale
   VLAN-x forwarder on the destination link, it will be dropped by the
   RBridge.  Otherwise, the re-encasulated frame is processed as
   [RFCtrill], and the Inner.MacSA and Inner.VLAN ID are, by default,
   learned as associated with the ingress nickname unless that nickname
   is unknown.

4.2.2.  Multicasting to VLAN-x forwarder

   Alternatively, a special multicast MAC address, named "AF RBridges on
   this link", can be introduced for the final hop to forward such a
   TRILL data frame.  The scope of the above MAC is limited to local



Zhai, et al.             Expires January 5, 2012                [Page 6]


Internet-Draft             Pseudonode Nickname                  Jul 2011


   link, just as the MAC for IS-IS hello PDUs.  If a TRILL data frame is
   addressed to this special MAC and transmitted on a link, all the
   Appointed Forwarder (AF) RBridges on the link will process it to some
   extent.

   With "AF RBridges on this link", the forwarding table remains
   unchanged in form, i.e., still based {nickname}.  For an entry, the
   next hop MAC address will be "AF RBridges on this link", if the
   nickname is the pseudonode nickname on one of local links.  In other
   words, if the nickname is a pseudonode nickname, the next hop MAC
   MUST be "AF RBridges on this link".

   If not VLAN-x forwarder, the final hop RBridge, RBn, looks up its
   forwarding table, based on the egress nickname in TRILL header of the
   received frame.  The frame will be discarded if no entry is found.
   Otherwise, RBn will re-encapsulate the frame, i.e., strip the outer
   frame header, remain the TRILL header unchanged, prepend a new outer
   frame header before the frame is transmitted onto the link.  For the
   forwarded frame, the Outer.MacSA is one unicast MAC address on the
   transmitting port connected to the link, the Ouer.MacDA is the next
   hop MAC address in the found entry and the Outer.VLAN is the
   designated VLAN on the link.  If the egress nickname is pseudonode
   nickname, the Outer.VLAN is "AF RBridges on this link" and the re-
   encapsulated TRILL data frame is multicasted onto the link.

   The TRILL data frame with "AF RBridges on this link" as Ouer.MacDA is
   discarded by other RBridges, which are not AF RBridges, on the link.
   Otherwise, the Inner.VLAN ID, i.e., VLAN-x, is checked.  If the VLAN
   ID is not valid or the receiving RBridge, RBi, is not VLAN-x
   forwarder on this link, the frame is also discarded.  Else, the TRILL
   data frame is decapsulated into native form and forwarded to the
   destination end station, and the Inner.MacSA and Inner.VLAN ID are
   also, by default, learned as associated with the ingress nickname
   unless that nickname is unknown by RBi.

4.2.3.  Comparison

   With the Unicasting method described in Section 4.2.1 above, the re-
   encapsulated TRILL data frame by the final hop RBridge is only
   processed by the VLAN-x forwarder on the link, which can reduce the
   burden of other RBridges as much as possible.  But the forwarding
   table on ingress/egress SHOULD be changed to be based on {nickname,
   VLAN}, instead of {nickname}, where each AF Rbridge on a local link
   is identified by the pseudonode nickname and the vlan id of the AF on
   the link.

   With Multicasting method described in Section 4.2.1 above, although
   all the AF RBridges, except for the final hop RBridge, on the link



Zhai, et al.             Expires January 5, 2012                [Page 7]


Internet-Draft             Pseudonode Nickname                  Jul 2011


   are required to process, to some extent, the re-encapsulated TRILL
   data frame, only the VLAN-x forwarder decapsulates the frame to its
   native form and forwards it to the destination end station.  However,
   the forwarding table can remain the same as current table in form,
   i.e., only based on {nickname}.


5.  TLV Extensions for Pseudonode Nickname

5.1.  Pseudonode Nickname Capability in Hellos

   The Pseudonode nickname capability of an RBridge MUST be included in
   one subTLV of Port Capability TLV in the RBridge's TRILL Hello PDUs.
   This capability is included in Special VLANs and Flags (subTLV Type
   #1) [TrillISIS].  This subTLV MUST appear exactly once in a Port
   Information TLV in every TRILL Hello PDU.  The length of the value is
   four octets.

   Pseudonode Nickname capability TLV

      +-+-+-+-+-+-+-+-+
      |Type=VLAN Flags|                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +---------------+---------------+
      |    Port ID                    |  (2 bytes)
      +-------------------------------+
      |     Sender Nickname           |  (2 bytes)
      +--+--+--+--+-------------------+
      |AF|AC|VM|BY|    Outer.VLAN     |  (2 bytes)
      +--+--+--+--+-------------------+
      |TR|PN|R |R |    Desig.VLAN     |  (2 bytes)
      +--+--+--+--+-------------------+

                                 Figure 1

   The PN bit, if one, indicates that the sending RBridge supports and
   enables the pseudonode nickname capability.  If an RBridge does not
   support or not enable this capability, the PN bit MUST be set zero.

   Other bits and fields refer to [TrillISIS].

   When receiving this subTLV from other RBridges on the link, the DRB
   can confirm whether all the adjacencies, in Report state [TrillAdj],
   support and enable this capability.  If not, DRB MUST NOT announce
   pseudonode nickname in its pseudonode LSPs to the TRILL campus, which
   can avoid the issue that remote traffic is forwarded to a RBridges
   without pseudonode nickname capability.



Zhai, et al.             Expires January 5, 2012                [Page 8]


Internet-Draft             Pseudonode Nickname                  Jul 2011


5.2.  Pseudonode Nickname TLV

   If the DRB has confirmed that pseudonode nickname capability can be
   enabled on this link, it will announce the pseudonode nickname to be
   used on this link in its hello PDUs and in its pseudonode nickname.
   The pseudonode nickname is carried in Pseudonode Nickname TLV, which
   is formatted as following:

   Pseudonode Nickname TLV

       +-+-+-+-+-+-+-+-+
       |Type= PSEU-NICK|                           (1 byte)
       +-+-+-+-+-+-+-+-+
       |     Length      |                         (1 byte)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   PSEUDONODE NICKNAME RECORDS (1)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        ...................                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   PSEUDONODE NICKNAME RECORDS (n)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     where each pseudonode nickname record is of the form:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Nickname.Pri |SType| Reserved|       (2 byte)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             Nickname          |       (2 bytes)
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 2

   o Type: Pseudonode Nickname Type, TBD (NICKNAME).

   o Length: 4*N, where N is the number of pseudonode nickname records
   present.

   o SType: An 3-bit unsigned integer sub-type for nickname.  If this
   nickname is pseudonode nickname, value of this field is 1.

   o Nickname.Pri: An 8-bit unsigned integer priority to hold a nickname
   as specified in Section 3.7.3 of [RFCtrill].

   o Nickname: This is an unsigned 16-bit integer as specified in
   Section 3.7 of [RFCtrill].



Zhai, et al.             Expires January 5, 2012                [Page 9]


Internet-Draft             Pseudonode Nickname                  Jul 2011


5.2.1.  Pseudonode Nickname TLV in Hellos

   For an RBridge enabled pseudonode nickname capability on this link,
   it announces one pseudonode nickname TLV in Hellos if it knows
   nickname for the pseudonode, otherwise, it MUST NOT announce
   pseudonode nickname in its Hellos.  If DRB has confirmed that
   pseudonode nickname capability is enabled on this link, the
   Nickname.Pri in the nickname record MUST be 255, otherwise the
   Nickname.Pri MUST NOT be 255, and SHOULD be 100 by default.

   For an RBridge that is not DRB, it only processes the pseudonode
   nickname announced by DRB, and MUST overwrite its own pseudonode
   nickname with the DRB's pseudonode nickname if the two nicknames are
   different and the Nickname.Pri of DRB is 255.DRB should process the
   pseudonode nickname TLV from all the adjacencies in the Report state
   on the link in order to obtain the pseudonode nickname that was being
   used on this link.

   This TLV MUST appear no more than once in a Port Information TLV in
   every Hello PDU.  Only one nickname record can be contained in this
   TLV, if this subTLV appears in Hello PDUs.

5.2.2.  Pseudonode Nickname TLV in DRB's LSPs

   For a DRB on a link, it MUST originate and flood a pseudonode LSP for
   this link if the bypass pseudonode bit is reset.  All the adjacencies
   in the Report state on this link are contained in its pseudonode LSP.
   Furthermore, if a pseudonode nickname capability is enabled on this
   link, a Pseudonode Nickname TLV MUST be contained in its pseudonode
   LSP.

   For a pseudonode LSP, the only one record in this TLV contains the
   nickname for the pseudonode standing for the link.  In this case, the
   value of Nickname.Pri varies from 1 to 255, which describes the DRB's
   priority to hold this nickname as specified in [RFCtrill] Section
   3.7.3.


6.  Security Considerations


7.  Acknowledgements


8.  References






Zhai, et al.             Expires January 5, 2012               [Page 10]


Internet-Draft             Pseudonode Nickname                  Jul 2011


8.1.  Normative references

   [MultilevelTrill]
              Perlman, R., Eastlake, D., and A. Ghanwani, "RBridges:
              Multilevel TRILL",
              draft-perlman-trill-rbridge-multilevel-02.txt, work in
              process, April 2011.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC6165]  Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
              Systems", RFC 6165, April 2011.

   [RFCtrill]
              Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
              Ghanwani, "RBridges: Base Protocol Specification",
              draft-ietf- trill-rbridge-protocol-16.txt, in RFC Editor's
              queue, Mar 2010.

   [TRILLisis]
              Eastlake, D., Dutt, D., Perlman, R., and A. Ghanwani,
              "TRILL Use of IS-IS", draft-ietf-isis-trill-05.txt work in
              process, Feb 2011.

   [TrillAdj]
              Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V.
              Manral, "RBridges: Adjacency",
              draft-ietf-trill-adj-02.txt, work in process, Feb 2011.

   [TrillAf]  Perlman, R., Eastlake, D., Banerjee, A., and F. Hu,
              "RBridges: Appointed Forwarders",
              draft-ietf-trill-rbridge-af-03.txt work in process,
              May 2011.

8.2.  Informative References















Zhai, et al.             Expires January 5, 2012               [Page 11]


Internet-Draft             Pseudonode Nickname                  Jul 2011


Authors' Addresses

   Hongjun Zhai
   ZTE Corporation
   68 Zijinghua Road
   Nanjing 200012
   China

   Phone: +86-25-52877345
   Email: zhai.hongjun@zte.com.cn


   Fangwei Hu
   ZTE Corporation
   889 Bibo Road
   Shanghai 201203
   China

   Phone: +86-21-68896273
   Email: hu.fangwei@zte.com.cn


   Radia Perlman
   Intel Labs
   2200 Mission College Blvd.
   Santa Clara, CA 95054-1549
   USA

   Phone: +1-408-765-8080
   Email: Radia@alum.mit.edu


   Donald Eastlake,3rd
   Huawei technology
   155 Beaver Street
   Milford, MA 01757
   USA

   Phone: +1-508-634-2066
   Email: d3e3e3@gmail.com











Zhai, et al.             Expires January 5, 2012               [Page 12]