<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-trill-lsp-ext-tree-distr-opt-01"
     ipr="trust200902" updates="6325">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="LSP extension for Distribution Tree">LSP extension for Tree
    Distribution Optimization across sites</title>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <author fullname="Weiguo Hao" initials="W." surname="Hao">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>haoweiguo@huawei.com</email>
      </address>
    </author>

    <date year="2012" />

    <area>Internet Area</area>

    <workgroup>Transparent Interconnection of Lots of Links Working
    Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Transparent Interconnection of Lots of Links Protocol</keyword>

    <abstract>
      <t>This document specifies an extension to LSP for the Rbridge in one
      site to advertise Global VLAN scope and associated link attribute to all
      the Rbridges both in the site of that Border Rbridge and the other
      adjacent sites in the same campus. With this extension, RBridges can
      prune the distribution tree of multi-destination frames according to the
      scope of the VLAN and link attribute defined in this document.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>Large datacenters are often multi-site in nature and may contain a
      large number of Rbridges in each site. A trill Campus network may also
      be designed to be multilevel can be divided in to multiple IS-IS <xref
      target="IS-IS"></xref><xref target="RFC1195"></xref>L1 Areas
      interconnected by L2 backbone area. Routing between Rbridges within a
      IS-IS L1 area/ site is known as "Level 1 routing". Routing between IS-IS
      L1 areas or sites is known as "Level 2 routing". The IS-IS L1 area
      supports Level 1 routing and consists of Rbridges within the site and
      link between Rbridges within the site. The L2 backbone area supports
      Level 2 routing and consists of Border Rbridges and links between the
      Border Rbridges. Border Rbridges may participate in one or more L1 areas
      as Level-1 Rbridges inside each site, in addition to their role as Level
      2 Rbridge across sites.</t>

      <t>In Trill campus network, RBridges use distribution trees to forward
      multi-destination frames. In case of one Trill campus network having
      multiple sites, the traffic associated with some distributed trees may
      travel between sites while the traffic associated with other distributed
      trees may be limited to only one site and not allowed to go across other
      sites. The traffic spanning across sites is also referred to as the
      traffic with global scope. In order to support scaling and performance
      of large TRILL networks in the real deployments, it is desirable to
      forward most of Multi-destination Trill traffic within the site and
      reduce the traffic that is required to span across sites within the
      entire TRILL campus. According to The TRILL base protocol, each
      distribution tree SHOULD be pruned per VLAN. When it is inevitable to
      construct trees that have a scope across sites throughout the TRILL
      campus, it is necessary to treat traffic tagged with VLAN differently
      based on VLAN scope and distinct the link between Rbridges in one site
      and link between two Border Rbridge in two sites to support large scale
      multi-tenants application.</t>

      <t>This document specifies an extension to LSP for the Rbridge in one
      site to advertise Global VLAN scope and associated link attribute to all
      the Rbridges both in the site of that Border Rbridge and the other
      adjacent sites in the same campus. With this extension, RBridges can
      prune the distribution tree of multi-destination frames according to the
      scope of the VLAN and link attribute defined in this document.</t>
    </section>

    <section title="Conventions used in this document">
      <t>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 <xref
      target="RFC2119">RFC2119</xref>.</t>
    </section>

    <section title="Motivations">
      <t>Distinguishing global vlan from local vlan is to increase the number
      of tenants by not breaking the VLAN tag size limits. E.g. one campus
      being divided into n sites, without distinction between global vlan and
      local vlan, at most support 4K tenants. However, if we distinguish
      global vlan from local vlan, suppose each site support only local vlan.
      Then each site support 4K tenants, the total number of tenants supported
      by one campus can be increased to 4n*K.Suppose some sites support local
      vlan, some sites support both local vlan and global vlan, the total
      number of tenants supported by one campus (4K,4n*K).</t>
    </section>

    <section title="TLV and Sub-TLV Extensions to IS-IS for Inter-site Distribution Tree">
      <t>This section describes data formats and code points for the TLVs and
      sub-TLVs added to IS-IS defined by this specification to support the
      multi-level TRILL or re-used from that already contained in the standard
      IS-IS extensions defined in <xref target="RFC6326"></xref>.</t>

      <section title="Global-VLANs Sub-TLV for the Router Capability TLV">
        <t>The optional Global-VLANs sub-TLV specifies the VLANs that have
        global scope and enable Construction of global multi-destination trees
        among different sites. It has the following format:<figure
            title="Figure 1: Report Block Structure">
            <artwork>
   +-+-+-+-+-+-+-+-+
   |     Type      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV  |  Start VLAN ID        |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VLAN bit-map....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure></t>

        <section title="Definition of Fields in Sub-TLV">
          <t><list style="hanging">
              <t hangText="Type: 8bits"><vspace blankLines="1" />Router
              Capability sub-TLV type, set to TBD (GLOBAL-VLANs).<vspace
              blankLines="1" /></t>

              <t hangText="Length: 8bits"><vspace blankLines="1" />Variable,
              minimum 3.<vspace blankLines="1" /></t>

              <t hangText="RESV: 4bits"><vspace blankLines="1" />4 reserved
              bits that MUST be sent as zero and ignored on receipt.<vspace
              blankLines="1" /></t>

              <t hangText="Start VLAN ID:12bits"><vspace blankLines="1" />The
              12-bit VLAN ID that is represented by the high order bit of the
              first byte of the VLAN bit-map.<vspace blankLines="1" /></t>

              <t hangText="VLAN bit-map:"><vspace blankLines="1" />The highest
              order bit indicates the VLAN equal to the start VLAN ID, the
              next highest bit indicates the VLAN equal to start VLAN ID + 1,
              continuing to the end of the VLAN bit-map field.<vspace
              blankLines="1" /></t>
            </list></t>
        </section>
      </section>

      <section title="Link-Attributes Sub-TLV extension for extended IS reachability TLV">
        <t>The link-attribute sub-TLV is carried within the TLV 22 and has a
        format identical to the sub-TLV format used by the Traffic Engineering
        Extensions for IS-IS (<xref target="RFC3784"></xref>): 1 octet of
        sub-type, 1 octet of length of the value field of the sub-TLV followed
        by the value field -- in this case, a 16 bit flags field.</t>

        <t>The Link-attribute sub-type is 19 and the link-attribute has a
        length of 2 octets.</t>

        <t>This sub-TLV is OPTIONAL and MUST appear at most once for a single
        IS neighbor. If a received Link State Packet (LSP) contains more than
        one Link-Attribute Sub-TLV, an implementation SHOULD decide to
        consider only the first encountered instance. The following bit is
        defined:<list style="hanging">
            <t hangText="Public Link Type For TRILL(0x03)">When set, this
            indicates that the link is public link for TRILL sites
            interconnection.</t>
          </list></t>
      </section>
    </section>

    <section title="Use of TLV and Sub-TLV for Tree Distribution Optimization across sites">
      <t>When the TRILL campus is divided into multiple sites, each site may
      have one or more Border Rbridges used to interconnect other remaining
      sites and form the Level 2 IS-IS Trill network. Such Level2 IS-IS Trill
      network can be used to construct global multi-destination tree spanning
      across various sites. <figure anchor="fig1"
          title="Example of multiple sites within one Trill Campus">
          <artwork>
     TRILL Site 1                              TRILL Site 2
+-------------------+  +---------------+   +-------------------+
|                   |  |               |   |                   |
| +---+      +----+ |  |      WAN      |   |+----+       +---+ |
| |RB1|------+BRB2| |--|L2 Connectivity|---||BRB3|-------|RB4| |
| +---+      +----+ |  |               |   |+----+       +---+ |
|                   |  |               |   |                   |
+-------------------+  +---------------+   +-------------------+
                                |
                                |
                      +-------------------+
                      |      +----+       |
                      |      |BRB5|       |
                      |      +----+       |
                      | +---+   |   +---+ |
                      | |RB6|---+---|RB7| |
                      | +---+       +---+ |
                      +-------------------+
                          TRILL Site 3
</artwork>
        </figure></t>

      <t>In order to support scaling and performance of large TRILL networks
      in the real deployments, firstly, not all the links between the level 2
      Rbridges need to be used to Construct global multi- destination trees.
      If the link between the level 2 Rbridges is allowed to construct global
      multi-destination trees, we can set this link attribute into “public
      interface for global tree construction”. In this document, we reuse Link
      Attribute sub-TLV for the extended IS reachability TLV and allocate a
      new bit value inside link Attribute Sub-TLV to support indication of
      “public link for global tree Construction”. The Border Rbridge in one
      site need to advertise this link attribute Sub-TLV to all the
      neighboring Border Rbridges in other neighboring sites and then this
      sub-TLV will be further forwarded to all the Rbridges in the site of
      each neighboring Border Rbridge. RBridges in each site can prune the
      distribution tree of multi-destination frames according to such link
      attribute.</t>

      <t>Secondly, not all traffic should have global scope and need to span
      across sites. Since each distribution tree SHOULD be pruned per VLAN
      according to <xref target="RFC6325"></xref>, we can specify a set of
      Global VLANs to identify the traffic that has global scope. In this
      document, we define one new sub-TLV for the Router Capability TLV, i.e.,
      Global- VLANs Sub- TLV. This Sub-TLV can be used by Rbriges in one site
      to determine whether Construction of global multi-destination trees
      across sites is allowed. In order to achieve this, the tree root or
      highest priority RBridge in one site configured to know a number of
      appropriate VLANs as Global VLANs and announce such information to the
      nearest border Rbridge; Then such Border Rbridge in this site need to
      advertise Global VLAN Sub-TLV to all the neighboring Border Rbridges in
      other neighboring sites and then this sub-TLV will be further forwarded
      to all the Rbridges in the site of each neighboring Border Rbridge. When
      Global VLAN and link attribute Sub-TLV described above has been
      distributed to all the corresponding Rbridges in the downstream of the
      tree root or highest priority RBridge, RBridges can prune the
      distribution tree of multi-destination frames according to the scope of
      the VLAN and link attribute defined in this document, eliminating
      branches that own link type mismatching with Distribution Tree scope
      identified by VLAN. If the distribution tree is local tree and has
      branches including a link with link attribute is set to public link for
      global tree construction, those branches should be eliminated. If the
      distribution tree is global tree and has branches containing a link with
      link attribute not set to public link for global tree construction,
      those branches also should be eliminated. <figure anchor="fig2"
          title="Distribution Tree">
          <artwork>
          +---+
          | a |
          +---+
     L1 \       \  L2
      \           \
     \              \
   +---+           +---+
   | b |           | c |
   +---+           +---+
              L3  \      \ L4
  VLAN20         \         \
               \             \
             +---+         +---+
             | d |         | e |
             +---+         +---+
               _             _
               _             _     \
public link    _L5           _L6     \ L7
               _             _         \
             +---+         +---+      +---+
             | f |         | g |      | h |
             +---+         +---+      +---+

             VLAN10        VLAN10    VLAN20
</artwork>
        </figure></t>

      <t>Take distribution tree in <xref target="fig2"></xref> as an example,
      Rbridge a is root node. Rbridge f,g are leaf nodes that have end station
      on VLAN 10 while Rbridge b,h are another two leaf nodes and that have
      end station on VLAN 20. The link between Rbridge d and f is public link
      used across sites while the other links in the figure 2 are links owned
      by one single site. Assume VLAN 10 are local VLAN and VLAN 20 are Global
      VLAN, after distribution tree pruning is done, Rbrige c should eliminate
      branch that has Rridge d and f since distribution tree is pruned based
      on local VLAN 10 and Link 5 in that branch is public link, which
      mismatch with each other.</t>
    </section>

    <section title="Unicast Forwarding Consideration">
      <t>In unicast forwarding, the MAC forwarding table for a Trill Border
      Rbridge is usually learned through the data plane, i.e.,MAC address is
      learnt from received Broadcast,Unknown, Unicast,Multicast packet through
      distribution tree. For end stations on the local vlan, the broadcast
      scope is limited to one local site, the Border Rbridge only learns MAC
      address of locally attached end station and the forwarding path between
      end stations within one site can be built for unicast. For end stations
      on global VLAN, end stations between two sites are within the same layer
      2 broadcast domain, the Border Rbridge can learn MAC address of end
      stations across sites and the forward path between two sites can be
      built as well for unicast. Therefore unicast forwarding between sites
      can be controlled through LSP extension we defined in this document.</t>

      <t>If the Border Rbridge is statically configured with unicast
      forwarding table and the nickname of the destination Rbridge is
      specified as one Rbridge’s nickname in other sites, the unicast packet
      must be forced to forward to the other sites. In this case, the Border
      Rbridge in other sites performs security check to the received packet.
      If the VLAN associated with the received packet is local VLAN and the
      packet is ingressed from public link across site, the packet should be
      discarded. If the VLAN associated with the received packet is Global
      VLAN, the packet should be allowed to ingress from public link across
      sites.</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA is requested to assign a new codepoint for the Global-VLANs
      Sub-TLV defined in this document and carried within TLV 242.</t>

      <t>IANA has created a registry for bit values inside the link-attributes
      sub-TLV called “link-attribute bit values for sub-TLV 19 of TLV 22”.</t>

      <t>This document instructs IANA to add a new bit value in the
      link-attribute bit values for sub-TLV 19 of TLV 22 registry as
      follows:<figure>
          <artwork>
Value   Name                              Reference
-----   ----                              ---------
0x3    Public Link Type between sites   [This document]
</artwork>
        </figure></t>

      <t>Further values are to be allocated by the Standards Action process
      defined in <xref target="RFC2434"></xref>, with Early Allocation
      (defined in <xref target="RFC4020"></xref>) permitted.</t>
    </section>

    <section title="Security Considerations">
      <t>The security considerations documented in <xref
      target="RFC4971"></xref><xref target="RFC5305"></xref> are applicable
      for the Sub-TLV extension defined in this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>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.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC1195">
        <front>
          <title>Use of OSI IS-IS for routing in TCP/IP and dual
          environments</title>

          <author fullname="Masataka Ohta" initials="M." surname="Ohta">
            <organization></organization>
          </author>

          <date month="December" year="1990" />

          <abstract>
            <t>This document defines the Extended Report (XR) packet type for
            the RTP Control Protocol (RTCP), and defines how the use of XR
            packets can be signaled by an application if it employs the
            Session Description Protocol (SDP). XR packets are composed of
            report blocks, and seven block types are defined here. The purpose
            of the extended reporting format is to convey information that
            supplements the six statistics that are contained in the report
            blocks used by RTCP's Sender Report (SR) and Receiver Report (RR)
            packets. Some applications, such as multicast inference of network
            characteristics (MINC) or voice over IP (VoIP) monitoring, require
            other and more detailed statistics. In addition to the block types
            defined here, additional block types may be defined in the future
            by adhering to the framework that this document provides.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC6326">
        <front>
          <title>Transparent Interconnection of Lots of Links (TRILL) Use of
          IS-IS</title>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake ">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Ayan Banerjee" initials="A." surname="Banerjee">
            <organization></organization>
          </author>

          <author fullname="Dinesh Dutt" initials="D." surname="Dutt">
            <organization></organization>
          </author>

          <author fullname="Radia Perlman" initials="R." surname="Perlman">
            <organization></organization>
          </author>

          <author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
            <organization></organization>
          </author>

          <date month="July" year="2011" />
        </front>

        <seriesInfo name="RFC" value="6326" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC6325">
        <front>
          <title>Routing Bridges (RBridges): Base Protocol
          Specification</title>

          <author fullname="Radia Perlman" initials="R." surname="Perlman">
            <organization></organization>
          </author>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake ">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Dinesh Dutt" initials="D." surname="Dutt">
            <organization></organization>
          </author>

          <author fullname="Silvano Gai" initials="S." surname="Gai">
            <organization></organization>
          </author>

          <author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
            <organization></organization>
          </author>

          <date month="July" year="2011" />
        </front>

        <seriesInfo name="RFC" value="6325" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC3784">
        <front>
          <title>Intermediate System to Intermediate System (IS-IS) Extensions
          for Traffic Engineering (TE)</title>

          <author fullname="H. Smit" initials="H." surname="Smit">
            <organization></organization>
          </author>

          <date month="June" year="2004" />
        </front>
      </reference>

      <reference anchor="RFC5029">
        <front>
          <title>SDP: Session Description Protocol</title>

          <author fullname="JP Vasseur" initials="J." surname="Vasseur">
            <organization></organization>
          </author>

          <author fullname="Stefano Previdi" initials="S." surname="Previdi">
            <organization></organization>
          </author>

          <date month="September" year="2007" />
        </front>
      </reference>

      <reference anchor="RFC2434">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in
          RFCs</title>

          <author fullname="Thomas Narten" initials="T." surname="Narten">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Harald Tveit Alvestrand" initials="H."
                  surname="Alvestrand">
            <organization></organization>
          </author>

          <date month="October" year="1998" />
        </front>

        <seriesInfo name="RFC" value="2434" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC4020">
        <front>
          <title>Early IANA Allocation of Standards Track Code Points</title>

          <author fullname="K.Kompella" initials="K." surname="Kompella">
            <organization>Columbia University</organization>
          </author>

          <author fullname="A. Zinin" initials="A." surname="Zinin">
            <organization></organization>
          </author>

          <date month="February" year="2005" />
        </front>

        <seriesInfo name="RFC" value="4020" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC4971">
        <front>
          <title>Intermediate System to Intermediate System (IS-IS) Extensions
          for Advertising Router Information</title>

          <author fullname="Jean-Philippe Vasseur" initials="J."
                  surname="Vasseur">
            <organization></organization>
          </author>

          <date month="July" year="2007" />
        </front>
      </reference>

      <reference anchor="RFC5305">
        <front>
          <title>S-IS Extensions for Traffic Engineering</title>

          <author fullname="Tony Li" initials="T." surname="Li">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Henk Smit" initials="H." surname="Smit">
            <organization></organization>
          </author>

          <date month="October" year="2008" />
        </front>

        <seriesInfo name="RFC" value="5305" />

        <format type="TXT" />
      </reference>

      <reference anchor="IS-IS">
        <front>
          <title>Intermediate System to Intermediate System Intra-Domain
          Routing Exchange Protocol for use in Conjunction with the Protocol
          for Providing the Connectionless-mode Network Service (ISO
          8473)</title>

          <author>
            <organization></organization>
          </author>

          <date year="2002" />
        </front>

        <seriesInfo name="ISO/IEC 10589:2002" value="Second Edition" />
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="TRILL-ML">
        <front>
          <title>RBridges: Multilevel TRILL</title>

          <author fullname="Radia Perlman" initials="R." surname="Perlman ">
            <organization></organization>
          </author>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake">
            <organization></organization>
          </author>

          <author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
            <organization></organization>
          </author>

          <author fullname="Hongjun Zhai" initials="H." surname="Zhai">
            <organization></organization>
          </author>

          <date month="October" year="2011" />
        </front>

        <seriesInfo name="ID"
                    value="draft-perlman-trill-rbridge-multilevel-03" />
      </reference>
    </references>

    <section title="Change Logs">
      <section title="draft-wu-trill-lsp-ext-tree-distr-opt-01">
        <t>The following are the major changes to previous version
        draft-wu-trill-lsp-ext-tree-distr-opt-00: <list style="symbols">
            <t>Add one new section to discuss Unicast Forwarding.</t>

            <t>Add one new section to clarify the motivation to write this
            draft.</t>

            <t>Some other editorial changes.</t>
          </list></t>
      </section>
    </section>
  </back>
</rfc>
