Internet DRAFT - draft-zhai-trill-esadi-extension-for-rbv

draft-zhai-trill-esadi-extension-for-rbv






TRILL Working Group                                             HJ. Zhai
Internet-Draft                                                   XH. Dai
Intended status: Standards Track                         ZTE Corporation
Expires: April 11, 2013                                 October 08, 2012


                        RBridge: ESADI-Extension
              draft-zhai-trill-esadi-extension-for-rbv-00

Abstract

   In a virtual RBridge(RBv), traffic from end station ES1 to ES2 will
   enter a TRILL campus through one member RBridge RB1 of RBv, but
   reverse traffic might choose another member RBridge RB2 to leave
   TRILL campus.  If RB1 can't obtain the location of ES2 via other
   means, it has to treat the traffic to ES2 as unknown destination
   traffic and multicasts it in TRILL campus.  However, if RB2 can share
   its learned MAC addresses with RB1, the above problem can be
   resolved.

   Based on appropriate extensions of ESADI, this document proposes, in
   control plane, an approach for informations synchronization within a
   group of RBridges.  Current informations mainly include end station
   addresses, but may include other informations in the future.

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 April 11, 2013.

Copyright Notice

   Copyright (c) 2012 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



Zhai & Dai               Expires April 11, 2013                 [Page 1]

Internet-Draft           ESADI-Extension for RBv            October 2012


   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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
     2.1.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Contributing authors . . . . . . . . . . . . . . . . . . . . .  4
   4.  Problems Statement . . . . . . . . . . . . . . . . . . . . . .  4
   5.  ESADI Extensions . . . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  General Extension  . . . . . . . . . . . . . . . . . . . .  6
       5.1.1.  Transmitting an Extended ESADI Frame . . . . . . . . .  7
       5.1.2.  Receiving an Extended ESADI Frame  . . . . . . . . . .  8
     5.2.  Extension for MAC Address Sharing  . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11






















Zhai & Dai               Expires April 11, 2013                 [Page 2]

Internet-Draft           ESADI-Extension for RBv            October 2012


1.  Introduction

   In TRILL, MAC flip-flopping problem will occur in case of service
   edge RBridge failure or other network unrest, this problem will be
   worsened under LAG or multi-homing scenario, please see section 1 in
   [DraftPN] for detailed descriptions. so virtual RBridge(RBv), along
   with its pseudo-nickname(s), is introduced to TRILL to address these
   problems.  An RBv represents a group of different RBridge ports
   through which member RBridges provide end-station services to a set
   of their attached end stations, Member RBridges announce their
   attachment to RBv in their LSP packets, then, based on these LSPs,
   other RBridges can compute the optimal path(s) to RBv.

   However, the RBv mechanism may cause new problems in frame
   forwarding.  For example, Native traffic from ES1 to ES2 will enter a
   TRILL campus through RB1 in an RBv, but the reverse traffic (i.e.,
   traffic from ES2 to ES1) leaves the TRILL campus through RB2 in this
   RBv.  Then RB1 loses the chance to learn where ES2 is in data plane.
   If RB1 has no other ways to get the location of ES2, it will have to
   always treat the traffic from ES1 to ES2 as unknown unicast traffic
   and multicast it in TRILL campus.  Furthermore, if RB2 does not know
   the location of ES1 and its link to ES1 fails, ES1 can't receive
   expected traffic even if RB1 has an active link to ES1.

   So, we propose to share MAC address informations among member
   RBridges in a group ,such as an RBv, to address the forwarding
   problems above.  Information shared may not limit to MAC addresses,
   it may include other informations as the progressing of TRILL in the
   future.  On the other hand, this information sharing is not bound to
   RBv , it may be used in other RBridge group cases, such as Border
   RBridges of an area in multi-level [MultiTRILL] [DraftDefault].

   Since ESADI protocol[RFC6325][ESADI] provides a way that an RBridge
   can announce and learn end station addresses, we can reuse it for
   information sharing.  However, at current, it is VLAN scoped, if an
   ESADI RBridge wants to share its end station addresses in several
   VLANs, it must enable several ESADI instances, each per VLAN.
   Furthermore, the current ESADI protocol can only be used to
   distribute MAC addresses of local end stations connected to the
   originating RBridge.  In order to share informations within a group
   of RBridges as well as information of remote end stations, ESADI
   should be extended to some extent.


2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Zhai & Dai               Expires April 11, 2013                 [Page 3]

Internet-Draft           ESADI-Extension for RBv            October 2012


   document are to be interpreted as described in [RFC2119].

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   [RFC2119].

2.1.  Abbreviations

   ES: End Station

   ESADI: End Station Address Distribution Information

   LAG: Link Aggregation Group


3.  Contributing authors

   Thanks Ting Liao and Bo Wu for their discussions and inputting.


4.  Problems Statement

   With the introduction of virtual RBridge, MAC flip-flopping problem
   in LAN or LAG can be resolved, for more informations on virtual
   RBridge, please refer to [DraftPN].  However, some new problems may
   occur with the introduction of RBv.  For example, see Figure 1 shown
   below.
























Zhai & Dai               Expires April 11, 2013                 [Page 4]

Internet-Draft           ESADI-Extension for RBv            October 2012


                                  ES2
                                  O
                                  |
                 ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
                 ^                |                      ^
                 ^            +-------+                  ^
                 ^            |  RBn  |         TRILL    ^
                 ^            +-------+         CAMPUS   ^
                 ^                |                      ^
                 ^       * * * * * * * * * * *           ^
                 ^       *                   *           ^
                 ^       *  other RBridges   *           ^
                 ^       *                   *           ^
                 ^       *                   *           ^
                 ^       * * * * * * * * * * *           ^
                 ^           |              |            ^
                 ^       +------+        +-----+         ^
                 ^       |  RB1 |        | RB2 |         ^
                 ^       +------+        + ----+         ^
                 ^          \............/               ^
                 ^ ^ ^ ^ ^ ^:\     RBv  /:^ ^ ^ ^ ^ ^ ^ ^
                             :\......../:
                                \    /
                                  O
                                 ES1

                       Figure 1 RBv in LAG scenario

   Native frames from ES1 to ES2 will enter the TRILL campus through one
   member RBridge of the RBv, such as RB1 in Figure 1, so RB1 has ES1's
   MAC address; but with regard to traffic returns from ES2 to ES1, RBx
   excutes SPF and finds that the shortest path to this RBv is through
   RB2.  If the link between RB2 and ES1 fails, and RB2 does not know
   how to reach ES1 for lack of MAC address of ES1, the received traffic
   will not be transmitted to ES1 properly by RB2.

   Thus, the MAC addresses of locally attached end stations on a member
   RBridge SHOULD be shared among all other member RBridges in an RBv.
   With these shared informations, if RB2 receives native frames
   destinationed to ES1, it can determine how to forward these frames to
   ES1.

   Furthermore, if the link between RB2 and ES1 is good, the reverse
   traffic will be egressed out of TRILL by RB2.  Then RB2 learns the
   location of ES2 by decapsulating such traffic into its native form.
   If RB1 has no other ways to get the location of ES2 and RB2 does not
   share this information with RB1, RB1 will not know where ES2 is.
   Then it has to always treat the traffic from ES1 to ES2 as unknown



Zhai & Dai               Expires April 11, 2013                 [Page 5]

Internet-Draft           ESADI-Extension for RBv            October 2012


   unicast traffic and multicast it in TRILL if it is responsible to
   ingress such traffic.  Always multicasting such traffic adds
   additional forwarding burden on TRILL network.

   Therefore, in addition to local attached end station MAC addresses,
   the learned remote MAC addresses should also be shared among all
   member RBridges in an RBv.  With the shared information, RB1 can
   unicast traffic from ES1 to ES2 through the TRILL campus.


5.  ESADI Extensions

   As described before, current ESADI is based on VLAN, and only
   destributes MAC addresses of locally attached end stations.  In order
   to be used to solve the above problems, ESADI defined in [RFC6325]
   and [ESADI] should be extended to a certain extent.  In the following
   sections, we call ESADI defined in [RFC6325] and [ESADI] as base
   ESADI.

   Extended ESADI definded in this document is used on a group base,
   such as an RBv, and can be used to distribute MAC address &VLAN
   informations of locally attached end stations as well as learned MAC
   addresses & VLAN of remote end stations.  The following sections will
   give detailed extensions on base ESADI.

5.1.  General Extension

   If member RBridges want to share informations (such as the learned
   MAC addresses) within the scope of their RBridge group (such as an
   RBv), each of them should create and enable a separate ESADI instance
   for that group, we call this kind of ESADI instance as non-VLAN-
   scoped ESADI instance.  Then the shared informations can be carried
   in the ESADI frames originated by that instance and be flooded to
   other member RBridges.  In the payload of those frames, the nickname
   of the group is also carried to indicate the scope in which the
   informations are expected to share.

   When receiving such frames, if the RBridge is (1) interested in the
   specified group, (2) implements this ESADI protocol extension, and
   (3) has an enabled ESADI instance for that group, the inner frame is
   decapsulated and provided to that local ESADI instance.  Then the
   shared informations carried in the frames are learned by the RBridge.
   Otherwise, the shared informations carried in those frames SHOULD not
   be learned.

   Similar to ESADI instances for a VLAN, it appears to the instance for
   a group at one RBridge that it is directly connected by a multi-
   access virtual link to all other member RBridges in the group running



Zhai & Dai               Expires April 11, 2013                 [Page 6]

Internet-Draft           ESADI-Extension for RBv            October 2012


   ESADI for that group.  From all the instances on the virtual link,
   one is selected as ESADI-DRB to send ESADI-CSNPs periodically to keep
   Link State Database synchronized among its neighbors on that virtual
   link.  After receiving an ESADI-PSNP PDU, the DRB will send the
   ESADI-LSPs requested by the ESADI-PSNP on the virtual link.  The
   winner is the instance with the highest ESADI priority with System ID
   as tie-breaking.

5.1.1.  Transmitting an Extended ESADI Frame

   Transmitting an extended ESADI frame is similar to base ESADI
   protocol, except differences described below.

   First, there are two methods to send such extended ESADI frames, with
   these methods, a receiving RBridge can distinguish such frames from
   the base ESADI frames:

   1.  Unicast method:

          In an ESADI frame originated by a VLAN-scoped ESADI instance,
          the VLAN specified in the Inner.VLAN information is the VLAN
          to which this ESADI frame applies, and neither 0x0 nor 0xFFF
          is a valid value for Inner.VLAN.  When a VLAN-scoped ESADI
          instance receives an ESADI frame with an invalid Inner.VLAN,
          it discards the frame.  Maybe the two values might be used as
          value of Inner.VLAN in the frame originated by a non-VLAN-
          scoped ESADI instance.  Since VLAN ID 0xFFF is reserved, we
          proposed 0x0 is used as one method for this purpose in this
          document.

          For a non-VLAN-scoped ESADI instance, if 0x0 is used as
          Inner.VLAN, ESADI frames can be only unicast to its neighbors;
          since 0x0 is not a valid Inner.VLAN in multi-destination TRILL
          frames (which include ESADI frames), ESADI frames with 0x0 as
          Inner.VLAN may be discarded by a transit RBridge.

          Except for Inner.VLAN, other fields in Inner Ethernet header
          of such a frame are as same as those of VLAN-scoped ESADI
          frame.

   2.  Multicast method:

          In basic ESADI protocol, a VLAN-scoped ESADI instance MUST use
          a globally unique unicast MAC address as the Inner.MacSA in
          its originated multi-destination ESADI frames.  Therefore, a
          non-unicast MAC address can be employed by a non VLAN-scope
          ESADI instance to indicate its multi-destination frames are
          not VLAN-scoped.  In this document, we propose the multicast



Zhai & Dai               Expires April 11, 2013                 [Page 7]

Internet-Draft           ESADI-Extension for RBv            October 2012


          MAC address of ALL-Egress-Address for this purpose.  For such
          a frame, while any valid VLAN ID can be used as Inner.VLAN in
          such a frame, we RECOMMEND that VLAN ID 1 is used as
          Inner.VLAN since it is a default VLAN supported by all
          RBridges.  Then a non-VLAN-scoped ESADI instance can multicast
          such ESADI frames to its neighbors for the necessary
          informations sharing.

          Except for proposed Inner.MacSA and the recommended VLAN ID,
          other fields in Inner Ethernet header of such a frame are the
          same as those of VLAN-scoped ESADI frame.

          Notes: an RBridge may use unicast method to send extended
          ESADI frames to each member in a same group if there are few
          members in this group; otherwise, if there are larger numbers
          of RBridgs in this group, we suggest using multicast method.

   Second, an extended ESADI frame MUST carry a group TLV in its payload
   to indicate the group to which the ESADI frame applies, and this TLV
   contains the nickname of the group.  This TLV MUST be the first TLV
   in payload of each of such ESADI frames (such as ESADI-LSPs, ESADI-
   PSNP and ESADI-CSNP if the originator believes it is ESADI-DRB), then
   it is convenient for an RBridge to decide which the extended ESADI
   instance is proper to process the frame when receiving it.

5.1.2.  Receiving an Extended ESADI Frame

   For an RBridge RBn, when receiving a TRILL frame, it does the general
   examinations (specified in Section 4.6.2 of RFC6325) on the frame.
   If it confirms the frame is an ESADI frame, that is, Inner.MacDA is
   the ALL-Egress-Address multicast MAC address, and then the following
   additional tests are done:

   o  If M=0 and the egress nickname is not that of RBn, the frame is
      forwarded as known unicast TRILL data frame.  If M=0 and the
      egress nickname is that of the receiving RBridge, then the frame
      is de-capsulated and processed locally.  The Inner.VLAN is
      examined, if being not 0x0, the frame is a VLAN-scoped ESADI frame
      and provided to its associated local ESADI instance.  If being
      0x0, the frame is a non-VLAN-scoped ESADI frame, then the first
      TLV in payload is checked.  If it is a group TLV, the frame is a
      group-scoped ESADI frame and the frame is provided to the
      interested group-scoped ESADI instance.

   o  If M=1, the frame is a multicast ESADI frame and is forwarded down
      the tree specified by the egress RBridge nickname.  In addition,
      the Inner.MacSA is examined.  If it is a unicast MAC address, the
      frame is a VLAN-scoped ESADI frame and provided to its associated



Zhai & Dai               Expires April 11, 2013                 [Page 8]

Internet-Draft           ESADI-Extension for RBv            October 2012


      local ESADI instance.  If Inner.MacSA is ALL-Egress-Address, the
      frame is not a VLAN-scoped ESADI frame, then the first TLV in
      payload is checked.  If it is a group TLV, the frame is a group-
      scoped ESADI frame and the frame is provided to the interested
      group-scoped ESADI instance.

5.2.  Extension for MAC Address Sharing

   In order to realize MAC address sharing within a group of RBridges,
   we reuse the MAC reachability TLV defined in [RFC6165] and [ESADI] to
   carry MAC addresses of attached end stations.  And the main
   differences covers the nickname and the VLAN ID fields in the MAC
   Reachability TLV, please see the following paragraph.

   There are two cases on the MAC addresses in MAC Reachability TLV, one
   is that the MAC addresses are addresses of local attached end
   stations; the other is MAC addresses of end stations attached to a
   remote RBridge.  When transmitting an extended ESADI frame, for the
   former case, a MAC Reachability TLV might not contain a nickname, if
   must have one, this should be the device nickname of the originating
   RBridge; For the latter case, the nickname in a MAC Reachability TLV
   is the egress nickname of the end station identified by the MAC
   address.  So when an RBridge receives a group-scoped ESADI frame, it
   can learn the location of the end station, i.e, if a MAC Reachability
   TLV contains a nickname, then the end station is attached to the
   RBridge identified by this nickname, otherwise, to the RBridge
   identified by the ingress nickname in TRILL header.

   In this document, it is RECOMMENDED that the preference of MAC
   addresses learned through group-scoped ESADI instance frames is lower
   than those learned from local native frames.


6.  IANA Considerations

   TBD.


7.  Security Considerations

   TBD.


8.  Acknowledgements

   TBD





Zhai & Dai               Expires April 11, 2013                 [Page 9]

Internet-Draft           ESADI-Extension for RBv            October 2012


9.  References

9.1.  Normative References

   [CMT]      Senevirathne, T., Pathangi, J., and J. Hudson,
              "Coordinated Multicast Trees (CMT)for TRILL",
              draft-ietf-trill-cmt-00.txt Work in Progress, April 2012.

   [ESADI]    Zhai, H., Hu, F., Eastlake 3rd, D., and R. Perlman, "TRILL
              (Transparent Interconnection of Lots of Links): The ESADI
              (End Station Address Distribution Information) Protocol",
              draft-ietf-trill-esadi-00.txt Work in Progress, June 2012.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC6325]  Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, July 2011.

9.2.  Informative References

   [DraftDefault]
              Senevirathne, T., Pathangi, J., Hudson, J., Aldrin, S.,
              Banerjee, A., and S. Merchant, "Default Nickname Based
              Approach for Multilevel TRILL",
              draft-tissa-trill-multilevel-00.txt Work in Progress,
              February 2012.

   [DraftPN]  Zhai, H., Hu, F., Eastlake 3rd, D., and R. Perlman,
              "RBridge: Pseudo-Nickname",
              draft-hu-trill-pseudonode-nickname-03.txt Work in
              Progress, Aug 2012.

   [MultiTRILL]
              Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai,
              "Multilevel TRILL (Transparent Interconnection of Lots of
              Links)",
              draft-perlman-trill-rbridge-multilevel-04.txt Work in
              Progress, May 2012.





Zhai & Dai               Expires April 11, 2013                [Page 10]

Internet-Draft           ESADI-Extension for RBv            October 2012


Authors' Addresses

   Hongjun Zhai
   ZTE Corporation
   68 Zijinghua Road, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Email: zhai.hongjun@zte.com.cn


   Xuehui Dai
   ZTE Corporation

   Email: dai.xuehui@zte.com.cn




































Zhai & Dai               Expires April 11, 2013                [Page 11]