Network Working Group                                Donald Eastlake 3rd
INTERNET-DRAFT                                      Eastlake Enterprises
Intended status: Proposed Standard                         Radia Perlman
                                                        Sun Microsystems
                                                             Dinesh Dutt
                                                                   Cisco
Expires: May 2, 2009                                    November 3, 2008


                         RBridges: Use of IS-IS

               <draft-eastlake-trill-rbridge-isis-02.txt>


Status of This Document

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Distribution of this document is unlimited. Comments should be sent
   to the TRILL Working Group <rbridge@postel.org>.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   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.



Abstract

   RBridges implement the TRILL protocol, which in turn makes use of an
   extended version of the IS-IS (Intermediate System to Intermediate
   System) routing protocol to determine topology and frame forwarding
   and for the distribution and synchronization of data. RBridges
   provide optimal pair-wise forwarding with zero configuration, safe
   forwarding even during periods of temporary loops, and multipathing
   for both unicast and multicast traffic. Rbridges also support VLANs.
   This document specifies some details of IS-IS PDUs used in TRILL.



D. Eastlake, R. Perlman, & D. Dutt                              [Page 1]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


Table of Contents

      Status of This Document....................................1
      Abstract...................................................1

      1. Introduction............................................3
      1.1 Terminology............................................3
      1.2 Ackowledgements........................................3

      2. Separation of IS-IS Instances...........................4

      3. TRILL IS-IS PDU Details.................................6
      3.1 Hello PDUs.............................................6
      3.2 LSP PDUs...............................................8
      3.2.1 Core TRILL IS-IS LSP.................................8
      3.2.2 TRILL ESADI LSP.....................................12
      3.3 CSNP/PSNP and MGROUP CSNP/PSNP PDUs...................13
      3.4 MGROUP PDUs...........................................13

      4. TRILL IS-IS TLVs.......................................14
      4.1 Port Capability TLV...................................14
      4.2 Area Address..........................................14
      4.3 Protocols Supported...................................14

      5. Bridged LAN Link Costs.................................15

      6. IANA Considerations....................................16
      7. Security Considerations................................16

      8. Normative References...................................17
      9. Informative References.................................17

      Disclaimer................................................18
      Additional IPR Provisions.................................18
      Author's Address..........................................19
      Expiration and File Name..................................19
















D. Eastlake, R. Perlman, & D. Dutt                              [Page 2]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


1. Introduction

   [RBRIDGE] specifies the TRILL base protocol which provides optimal
   pair-wise forwarding with zero configuration, safe forwarding even
   during periods of temporary loops, and multipathing for both unicast
   and multicast traffic. Rbridges also support VLANs.  The TRILL
   protocol, in turn, makes use of the IS-IS [ISIS] protocol with
   certain extensions.  [ISIS-L2] is intended to specify general [ISIS]
   facilities to provide true link state routing to any protocol running
   directly over Layer-2.

   This is a specification of details of TRILL use of IS-IS
   concentrating on IS-IS PDU content in TRILL. It makes use of the
   Router Capabilities TLV [RFC4971]. It also adds a new Port
   Capabilities TLV used only within Hello PDUs.

   [RBRIDGE] specifies the TRILL handling and flow of IS-IS PDUs, along
   with the determination of the Designated RBridges (DRB, equivalent to
   the DIS (Designated Intermediate System)) on a link and the like.

   {{Comments in double curly braces relate to version -03 of [ISIS-
   L2].}}



1.1 Terminology

   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.

   The same acronyms and terminology are used in this document as in
   [RBRIDGE].



1.2 Ackowledgements

   The comments of Ayan Banerjee are gratefully acknowledged.













D. Eastlake, R. Perlman, & D. Dutt                              [Page 3]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


2. Separation of IS-IS Instances

   TRILL implements separate IS-IS instances from those used by Layer 3,
   that is, different from the one used by IP routers.  It is important
   that these be distinguishable to avoid possible confusion that would
   occur if an IS-IS instance attempted to process IS-IS PDUs intended
   for a different instance.

   TRILL implements multiple instances of IS-IS for its own use.  One
   mandatory instance includes information such as basic connectivity
   between RBridges, VLAN attachment, location of IP multicast routers,
   and the like. RBridges also optionally implement TRILL ESADIs (End
   Station Address Distribution Instances) of IS-IS, to carry
   information about attached end nodes.

   This section explains how TRILL encodes IS-IS frames for its
   instances to ensure that there is no confusion between TRILL
   instances of IS-IS and Layer-3 instances of IS-IS or between the
   mandatory core instance of TRILL IS-IS and TRILL ESADIs.

   The first level of discrimination is based on the destination address
   of IS-IS frames as follows:

   1. Layer 3 IS-IS frames have a destination multicast MAC address of
      AllL1ISs or AllL2ISs. (Proposals are under consideration which
      would add other multicast addresses to this list but they would
      not in duplicate

   2. TRILL IS-IS frames are used for the core instance which all
      RBridges MUST participate in. The have the multicast destination
      address All-IS-IS-RBridges.

   3. TRILL ESADI frames are used for the optional per VLAN instances.
      An RBridge which is an appointed forwarder for a link in VLAN-x
      MAY participate in the ESADI for VLAN-x if the ESADI feature is
      implemented in that RBridge and it is configured to so
      participate. TRILL ESADI frames will never have the outer MAC
      destination addresses listed in items 1 and 2 above.  They look
      just like TRILL data frames and have an outer TRILL Ethertype, but
      the encapsulated IS-IS PDU has a destination MAC multicast address
      of All-ESADI-RBridges. Thus TRILL ESADI frames are transparently
      tunneled thorough non-participating RBridges exactly as if they
      were TRILL data frames. The VLAN to which they apply is indicated
      by the encapsulated frames VLAN tag.

   In addition, TRILL uses a distinct, constant IS-IS Area Address that
   would not appear as a real Layer-3 IS-IS area address. This Area
   Address is the value zero. (See Section 4.2.)

   The multiple instance mechanism described in [ISIS-MI] is not used to


D. Eastlake, R. Perlman, & D. Dutt                              [Page 4]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


   distinguish these TRILL IS-IS instances, although TRILL IS-IS PDUs
   for the mandatory core instance MAY include the MI TLV with the
   instance number of zero. In order to facilitate the optional RBridge
   VLAN mapping feature, TRILL ESADI frames MUST NOT contain an instance
   identifier. The instance identifier TLV is type #7.















































D. Eastlake, R. Perlman, & D. Dutt                              [Page 5]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


3. TRILL IS-IS PDU Details

   [ISIS], as extended by [ISIS-L2], supports 7 types of PDUs: Hello,
   LSP, CSNP, PSNP, MGROUP, MGROUP CSNP, and MGROUP PSNP. TRILL aspects
   of the contents of each of the PDU types are specified in this
   Section. Some individual TLVs types are discussed in Section 4 below.

   All RBridges have a 6-octet System ID that is conveyed in the header
   of every TRILL IS-IS PDU they produce, just as in Layer-3 IS-IS. The
   Maximum Area Addresses octet in the common fixed header is set to
   0x01. An RBridge campus is always a single Level 1 IS-IS Area.

   Where some IS-IS TLVs assume a unique 32-bit Router ID, in TRILL IS-
   IS this field is zero

   All TRILL IS-IS PDUs MAY contain an Authentication TLV (Type #10)
   [RFC5304].



3.1 Hello PDUs

   Hellos are only used in the core instance of TRILL IS-IS. (The core
   instance link state contains enough information that the DRB,
   adjacencies, and holding time for any ESADI can be determined without
   Hellos. See Section 4.2.4.1 of [RBRIDGE].)

   All TRILL Hello PDUs contain the TRILL Area Address TLV (see Section
   4.2). The Circuit Type two bit field of TRILL IS-IS Hello PDUs MUST
   be set to 0b01 indicating Level 1 only.

   An IS Neighbor TLV (Type #6) MUST be included in a TRILL Hello if the
   Hello is sent on the Designated VLAN and MAY be included if it is
   sent on any other VLAN. (See Section 4.2.3 of [RBRIDGE].)

   Core IS-IS instance Hello PDUs MUST include one or more Port
   Capability TLVs (Type #<tbd4.1>). The following TRILL related subTLVs
   can appear within a Port Capability TLV:

   1. Special VLANs and Flags (subTLV Type #10). This subTLV MUST appear
      excatly once in a Port Information TLV in every TRILL Hello PDU.
      The length of the value is four octets.

         0    1    2    3     4 - 15      16 - 19     20 - 31
      +----+----+----+----+------------+----------+------------+
      | AF | AC | VM |  R | Outer.VLAN | Reserved | Desig.VLAN |
      +----+----+----+----+------------+----------+------------+

      The first and second octets have a copy of the Outer.VLAN ID
      associated with the Hello frame when it was sent.  The lower 4


D. Eastlake, R. Perlman, & D. Dutt                              [Page 6]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


      bits of the first octet give the upper ID bits of the VLAN ID and
      the second octet gives the lower VLAN ID bits.

      The upper 4 bits of the first octet are flag bits as shown. The AF
      bit, if one, indicates that the sending RBridge believes it is
      Appointed Forwarder for the VLAN and port on which the Hellos was
      sent. The AC bit, if one, indicates that the sending port is
      configured as an access port. The VM flag, if a one, indicates
      that the sending RBridge has detected VLAN mapping within the
      link. The R bit is reserved and MUST be sent as zero and ignored
      on receipt.

      The third and forth octets give the Designated VLAN for the link.
      The lower 4 bits of the third octet give the upper ID bits of the
      Designated VLAN and the forth octet gives the lower VLAN ID bits.
      The upper 4 bits of the third octet are reserved and MUST be sent
      as zero and ignored on receipt.

   2. Enabled VLANs (subTLV Type #11). Specifies the VLANs enabled for
      end station service at the port on which the Hello was sent. The
      minimum size of the value is 3 octets. The third and subsequent
      octets provide a bit map of enabled VLANs starting at the VLAN ID
      indicated in the first two octets. The lower order four bits of
      the first octet give the upper bits of the starting VLAN ID and
      the second octet gives the lower bits of that VLAN ID. The upper
      four bits of the first octet are reserved and MUST be sent as zero
      and ignored on receipt. The highest order bit of the third octet
      indicates the VLAN equal to the starting ID while the lowest order
      bit of the third octet indicated that ID plus 7. For example,
      VLANs 1 and 14 being enabled for end station service could be
      encoded in 4-octets value 0x00 0x01 0x80 0x04 or, alternatively,
      as 0x00 0x00 0x40 0x02.

      This subTLV may occur more than once in a TRILL Hello and a VLAN
      is enabled for end station service on the port where the Hellos
      was sent if this is indicated by any occurrence in the Hello. For
      example, a receiver could allocate a 512-octet buffer and, with
      appropriate shifting operations, OR in the enabled bits for each
      subTLV of this type it finds in a Hello to derive the complete bit
      map of these VLANs.

   3. Appointed Forwarders (subTLV Type #12). This subTLV provides the
      mechanism by which the DRB can inform other RBridges on the link
      that they are the designated VLAN-x forwarder for that link for
      one or more ranges of VLAN IDs. The size of the value is 6*n
      octets where there are n appointments. Each 6 octet part of the
      value is formatted as follows:





D. Eastlake, R. Perlman, & D. Dutt                              [Page 7]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


      |  octet 1 - 2   |  octet 3  | octet 4 |  octet 5 | octet 6 |
      +----------------+-----+-----+---------+-----+----+---------+
      | Appointee Nick | Res | Start VLAN ID | Res | End VLAN ID  |
      +----------------+-----+-----+---------+-----+----+---------+

      The appointed forwarder RBridge is specified by its nickname in
      the first two octets.

      The "Res" fields of 4 bits each are reserved and MUST be sent as
      zero and ignored on reciept.

      The VLAN range give is inclusive. To specify a single VLAN, that
      VLAN ID appears as both the start and end VLAN. The RBridge whose
      nickname is given is appointed forwarder for those VLANs for which
      it has end station service enabled (see item 2 above) in the
      inclusive range. For example, assume an RBridge with end station
      service enabled on VLANs 100, 101, 199, and 200 (and possibly
      other VLANs less than 100 or greater than 200), but not enabled
      for VLANS 102 through 198. It could be appointed forwarder for
      these four VLANs through either (1) a single 6-octet value
      sequence with start and end VLAN IDs of 100 and 200, or (2) a
      12-octet value sequence with start and end VLAN IDs of 100 and 101
      in the first part and 199 and 200 in the second part.

      An RBridge's nickname may occur as appointed forwarder for
      multiple VLAN ranges within the same or different Port Capability
      TLVs within a DRB's Hello. In the absence of appointed forwarder
      subTLVs referring to a VLAN, the DRB acts as the appointed
      forwarder for that VLAN if end station service is enabled.



3.2 LSP PDUs

   The TLVs to be included in TRILL LSP PDUs are different for the
   mandatory core TRILL IS-IS instance of a campus, discussed in Section
   3.2.1 below, and in the optional TRILL ESADIs, discussed in section
   3.2.2 below.

   All TRILL LSP PDUs contain the TRILL Area Address TLV (see Section
   4.2). In addition, in the LSP header, the P Flag and Att flags MUST
   be zero and the IS type two bit field MUST be set to 0b01 indicating
   Level 1.



3.2.1 Core TRILL IS-IS LSP

   The content of core TRILL IS-IS instance LSP PDUs includes:



D. Eastlake, R. Perlman, & D. Dutt                              [Page 8]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


   1. Information on reachable RBridge neighbors and the cost of the hop
      via the Extended IS Reachability TLV (Type #22) [RFC5305] (wide
      metric). TRILL IS-IS does not use the IS Reachability TLV (Type
      #2) (narrow metric).

   2. The RBridge flags, nickname, VLANs, and other information via one
      or more Router Capability TLVs [RFC4971] (Type #242). The D and S
      flags in the Router Capability TLV MUST be zero. Other information
      is included by instances of the following TRILL related Router
      Capability TLV subTLVs:

      2.a TRILL Flags (subTLV Type #<tbd3.2.1a>). Exactly one TRILL
          Flags subTLV must occur in the link state of every RBridge.
          The length of the value of this subTLV is variable with a
          minimum size of 1 octet.  The top four bits of the first octet
          are defined as below. Additional bits may be specified in the
          future and those bits may extend into subsequence octets.  The
          value of all bits in any octets not present is assumed by a
          receiver to be zero.

                  first  octet
                0    1    2    3    4 - 7
              +----+----+----+----+-----------+---
              | V0 | V1 | V2 | V3 | reserved  |
              +----+----+----+----+-----------+---

          V0 through V4 indicate support of TRILL Header Versions 0
          through 4. The remaining bits of the first octet (and all bits
          of subsequent octets if present) are reserved and MUST be zero
          when sent and ignored on receipt.

      2.b Nickname and Tree Root (subTLV Type #<tbd3.2.1b>). If an
          RBridge is to be able to act as an ingress, egress, or tree
          root, it must have a nickname.  The value is 7 octets in
          length. The first octet is the RBridge's nickname priority,
          the second and third octets are its nickname. Octets 4 and 5
          are the RBridge's priority to be a tree root as an unsigned
          16-bit integer. Octets 6 and 7 are an unsigned 16-bit integer
          that gives the number of additional trees every RBridge in the
          campus is to compute if the RBridge in whose link state this
          occurs is the highest priority tree root. (See [RBRIDGE]
          Section 4.3.)

          {{While the Device ID subTLV in [ISIS-L2] could be used for
          Nickname, putting the Nickname priority in 8 of the Options
          bits, the Root Priority subTLV and Root Identity subTLV in
          [ISIS-L2] does not correspond and never has corresponded whith
          how with how TRILL determines distribution tree roots or
          multi-path multi-destination frames.}}



D. Eastlake, R. Perlman, & D. Dutt                              [Page 9]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


      2.c Distribution Tree Roots (subTLV Type #<tbd3.2.1c>).  The value
          is a variable length array of the nicknames of the RBridges
          from which the originating RBridge must pick the root of the
          distribution tree for multi-destination traffic for which it
          is the ingress RBridge. If the list is empty or this subTLV is
          not provided, the originating RBridge can only select the
          highest priority tree root (see [RBRIDGE] Section 4.3).

      2.d VLANs and Bridge Roots (subTLV Type #<tbd3.2.1d>). The value
          of this subTLV consists of a VLAN range, flags, and a variable
          length list of spanning tree root bridge IDs. This subTLV may
          appear zero, one, or many times. The union of the VLAN ranges
          in all occurrences MUST be precisely the set of VLANs for
          which the originating RBridge is appointed forwarder on at
          least one port and the VLAN ranges in multiple VLANs subTLVs
          for an RBridge MUST NOT overlap.  That is, the intersection of
          the VLAN ranges for any pair of these subTLVs originated by an
          RBridge must be null. The value length is 4 + 6*n where n is
          the number of root bridge IDs.  The initial 4 octets of value
          are as follows:

             0    1    2    3     4 - 15      16 - 19     20 - 31
          +----+----+----+----+------------+----------+------------+--
          | M4 | M6 | OM |  R | VLAN start | Reserved |  VLAN end  |
          +----+----+----+----+------------+----------+------------+--

          The M4 bit indicates that there is an IPv4 multicast router on
          a link for which the originating RBridge is appointed
          forwarder for every VLAN in the indicated range. The M6 bit
          indicates the same for an IPv6 multicast router. The OM bit
          indicates that this RBridge requests that all non-IP derived
          multicast traffic in the indicated VLAN range be sent to it.
          The R and Reserved bits MUST be sent as zero and are ignored
          on receipt.

          The VLAN start and end IDs are inclusive. A range of one VLAN
          ID is indicated by setting them both to that VLAN ID value.

          The list of zero or more spanning tree root bridge IDs is the
          set of root bridge IDs seen for all ports for which the
          RBridge is appointed forwarder for the VLANs in the range.
          This information is learned from BPDUs heard by the RBridge.
          If MSTP is in use on a link, the root bridge referred to is
          the CIST (common and internal spanning tree) root bridge.
          (While, of course, only one spanning tree root should be seen
          on any particular port, there may be multiple ports in the
          same VLAN connected to differed bridged LANs with different
          spanning tree roots.) If no spanning tree roots can be seen on
          any of the links in any of the VLANs in the range indicated
          for which the RBridge is appointed forwarder (for example all


D. Eastlake, R. Perlman, & D. Dutt                             [Page 10]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


          such links are point-to-point links to other RBridges or to
          end stations so no BPDUs are received) then the listed set of
          spanning tree root IDs will be null.

          If there are any two VLANs in the range indicated for which
          the value of the M4, M6, or OM bits are different, the subTLV
          is incorrect and must be split into multiple subTLVs each
          indicating only VLANs with the same M4, M6, and OM values. If
          there are any two VLANs in the range indicated for which the
          set of root bridge IDs see on all links for which the RBridge
          is appointed forwarder for the VLAN are not the same, the
          subTLV is incorrect and must be split into multiple subTLVs
          each indicating only VLANs with the same set of DRB seen root
          bridge IDs. It is always safe to use subTLVs with a "range" of
          one VLAN ID but this may be too verbose.

      2.e ESADI Participation (subTLV Type #<tbd3.2.1e>). The value of
          this optional subTLV is 6*N octets where N is the number of
          VLAN ranges given. The presence of this subTLV in the LSP for
          an RBridge constitutes the ESADI participation flag for the
          VLANs in the range or ranges given. An RBridge which does not
          implement the ESADI feature may ignore this subTLV. Each 6
          octets of value is structured as follows:

           0    1-7  | 8-11|   12-23    |24-27|  28-39   |   40-47    |
          +-+--------+-----+------------+-----+----------+------------+
          |R|Priority| Res | VLAN start | Res | VLAN end |Holding Time|
          +-+--------+-----+------------+-----+----------+------------+

          The R bit and the two "Res" fields are reserved and MUST be
          sent as zero and ignored on receipt.  The Priority field gives
          the RBridge's priority for being DRB on the TRILL EASDI
          virtual links for the VLAN or VLANs indicated while the
          Holding Time field gives its holding time if it is DRB. The
          VLAN start and end values give the inclusive range of VLAN IDs
          for which the RBridge wishes to participate in a TRILL ESADI.
          A range of one VLAN is specified by making the start and end
          IDs equal.

      2.f VLAN Groups (subTLV Type #<tbd3.2.1f>). The value of this
          optional subTLV consists of two or more 16-bit fields each of
          which has a VLAN ID in the low order 12 bits. The top 4 bits
          MUST be sent as zero and ignored on receipt. The first such
          VLAN ID is the primary, or may be zero if there is no primary.
          Address learning is shared between the listed VLANs at the
          originating RBridges as described in Section 4.6.3 of
          [RBRIDGE].  This subTLV may appear zero, one, or many times.

      2.g VLAN Mapping (subTLV Type #<tbd3.2.1g>). The value of this
          optional subTLV consists of 6*N octets where N is the number


D. Eastlake, R. Perlman, & D. Dutt                             [Page 11]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


          of VLAN mappings occuring at the cut set RBridge originating
          the LSP [VLANmapping]. Each 6 octet subpart of the value is
          structured as follows:

              0-7      |8-11|  12-23   |   24-31    |32-35|  36-47   |
          +-+----------+----+----------+------------+-----+----------+
          | 1st Domain |Res | 1st VLAN | 2nd Domain | Res | 2nd VLAN |
          +-+----------+----+----------+------------+-----+----------+

          The numbering of the parts of the IETF compus (Domains)
          between which VLAN mapping is occuring must be done
          consistently by the administrator. The value indicates that
          the 1st VLAN's ID in the 1st domain is being mapped to the 2nd
          VLAN's ID in the 2nd domain. Since these mappings must be
          symmetric, this implies that the 2nd VLAN's ID in the 2nd
          domain is also being mapped to the 1st VLAN's ID in the 1st
          domain. In other words, if makes no difference if the first 3
          and last 3 octets in each 6-octet substring of the value are
          swapped. This subTLV may appear zero, one, or many times.

   Note: See Section 3.4 below for multicast groups.



3.2.2 TRILL ESADI LSP

   The information in TRILL ESADI LSP PDUs consists of one or more MAC
   Reachability (MAC-RI) TLVs [ISIS-L2] (Type #139). These TLVs contain
   one or more unicast MAC addresses of end stations that are both on a
   port and in a VLAN for which the originating RBridge is appointed
   forwarder, along with the one octet unsigned Confidence in this
   information with a value in the range 0-254.

   In order to support VLAN mapping, the TRILL EASDI LSP and any TLVs in
   it, including theh MAC-RI TLV MUST NOT containg the VLAN ID. The VLAN
   to which the TRILL ESADI LSP applies is indicated only by the VLAN
   tag in the encapsulated TRILL ESADI IS-IS frame.

   {{There is no place in the current MAC-Reachability TLV for the
   confidence level. It could go where the VLAN ID currently is as the
   VLAN ID is not needed for the TRILL use and, in fact, can't be used
   if you want VLAN mapping to be practical. Alternatively, some option
   bits and the confidence could be inserted before or after the VLAN ID
   and the VLAN ID always set to zero.}}








D. Eastlake, R. Perlman, & D. Dutt                             [Page 12]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


3.3 CSNP/PSNP and MGROUP CSNP/PSNP PDUs

   CSNP stands for Complete Sequence Number Packet and PSNP for Partial
   Sequence Number Packet. These relate to the IS-IS link state flooding
   algorithm and link state sequence numbers.  There is no change from
   typical Layer-3 sequence number IS-IS PDUs except for the addition of
   MGROUP CSNP and PSNP PDUs. TRILL IS-IS uses only Level 1 sequence
   number packets.



3.4 MGROUP PDUs

   MGROUP PDUs [ISIS-L2] are only sent as part of the core TRILL IS-IS
   instance. They contain one or more Group Address (GADDR) TLVs each of
   which, in turn, contains one or more Group MAC Address (GMAC-ADDR)
   sub-TLVs. Those GMAC-ADDR sub-TLVs specify the VLAN involved and list
   the IP-derived multicast addresses for which there are listeners on
   links for which the originating RBridge is appointed forwarder.

   (MGROUP PDUs must be in the core TRILL IS-IS, even if an optional
   TRILL ESADI is in use for the relevant VLAN, so that transit RBridges
   can properly prune the distribution of multicast frames.)

   All TRILL MGROUP PDUs contain the TRILL Area Address TLV (see Section
   4.2).


























D. Eastlake, R. Perlman, & D. Dutt                             [Page 13]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


4. TRILL IS-IS TLVs

   This section describes particular TLVs included or not included in
   TRILL IS-IS PDUs.



4.1 Port Capability TLV

   The Port Capability TLV is used in TRILL IS-IS Hellos to announce a
   variety of information specific to the port on which the Hello is
   sent. It is TLV Type #tbd4.1. It's content is structured as subTLVs
   in the same manner as in [RFC5305].

   The Port Capability TLV appears only in IS-IS Hello PDUs



4.2 Area Address

   The TRILL zero Area Address TLV is encoded as follows:

          +--------------------------+--------------------------+
          | 0x01 (Area Address Type  | 0x02 (Length of Value)   |
          +--------------------------+--------------------------+
          | 0x01 (Length of Address) | 0x00 (zero Area Address) |
          +--------------------------+--------------------------+



4.3 Protocols Supported

   Since no NLPID (Network Layer Protocol Identifier) has been allocated
   by the ISO/IEC TR 9577 Registry for the Ethernet protocol or MAC-48
   address type or TRILL, there is no way to indicate support of IS-IS
   routing for these in a Protocols Supported TLV (TLV #129).
















D. Eastlake, R. Perlman, & D. Dutt                             [Page 14]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


5. Bridged LAN Link Costs

   RBridges use IS-IS to support TRILL and may be interconnected by
   direct links such as 802.3, or by bridged LANs.  If there an
   intervening bridge or bridges, the link is really multiple bridged
   physical links. RBridges can automatically detect this condition
   under some circumstances.

   For loop avoidance purposes RBridges listen for BPDUs and keep track
   of the most recent announced root bridge on a link [RBRIDGE], if any.
   This bridge, or the fact that no BPDUs have been received, is
   reported in the link state database as described in Section 3.2.1
   above.  It is still possible for RBridges to be connected by a
   bridged LAN where the bridge ports to which they are connected have
   been configured not to emit BPDUs. On the other hand, if any RBridge
   connected to a link is seeing BPDUs, it is likely that there are one
   or more intervening bridges between it and any RBridge on the link to
   which it appears to be adjacent.

   When a link is a bridged LAN, transit traffic will experience at
   least two bridged physical links and possibly many more. To account
   for this, RBridges SHOULD assume, for IS-IS routing purpose, that the
   default metric for traversing such a link is 2*C + 1, where C is the
   Layer-3 IS-IS default metric (usually auto-configured from port
   speed).

   More precise link cost can be asserted by management configuration.

























D. Eastlake, R. Perlman, & D. Dutt                             [Page 15]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


6. IANA Considerations

   IANA will allocate a TLV number for the new Port Capability TLV and
   create a registry for subTLVs under the Port Capabilities TLV.

   The Port Capabilities TLV is generally described in Section 4.1. Its
   TLV number is <tbd4.1>(suggest 243). IANA Considerations for the
   allocation of additional subTLVs under the Port Capability TLV are
   Expert Approval except that subTLV Types 0 and 0xFF are Reserved and
   require an IETF Standards Action for allocation.

   In addition, seven new subTLVs will be allocated under the Router
   Capabilities TLV as listed in Section 3.2.1 and listed below.

       Port Capaiblities
       subTLV Name             Value
       -----------             -----
      Special VLANs and Flags  10
      Enabled VLANs            11
      Appointed Forwarders     12

       Router Capaiblities
       subTLV Name             Value
       -----------             -----
      TRILL Flags              <tbd3.2.1a>(suggest 21)
      Nickname and Tree Root   <tbd3.2.1b>(suggest 22)
      Distribution Tree Roots  <tbd3.2.1c>(suggest 23)
      VLANs                    <tbd3.2.1d>(suggest 24)
      ESADI Participation      <tbd3.2.1e>(suggest 25)
      VLAN Groups              <tbd3.2.1f>(suggest 26)
      VLAN Mapping             <tbd3.2.1g>(suggest 27)



7. Security Considerations

   This document raises no new security issues for IS-IS. IS-IS security
   may be used to secure the IS-IS messages discussed here.  See
   [RFC5304]. See [RBRIDGE] for TRILL Security Considerations.













D. Eastlake, R. Perlman, & D. Dutt                             [Page 16]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


8. Normative References

   [ISIS] "Intermediate system to Intermediate system routeing
      information exchange protocol for use in conjunction with the
      Protocol for providing the Connectionless-mode Network Service
      (ISO 8473)", ISO, ISO/IEC 10589:1992.

   [ISIS-L2] D. Ward et. al, "Carrying Attached Addresses in IS-IS",
      draft-ward-l2isis-03.txt, work in progress, May 2008.

   [RBRIDGE] R. Perlman et. al., "Rbridges: Base Protocol
      Specification", draft-ietf-trill-rbridge-protocol-10.txt, work in
      progress, July 2008.

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

   [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
      "Intermediate System to Intermediate System (IS-IS) Extensions for
      Advertising Router Information", RFC 4971, July 2007.

   [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
      Engineering", RFC 5305, October 2008.

   [VLANmapping] R. Perlman e.t al., "RBridge VLAN Mapping", draft-
      perlman-trill-rbridge-vlan-mapping-00.txt, work in progress,
      October 2008.



9. Informative References

   [ISIS-MI] S. Previd et. al., "IS-IS Multi-instance", draft-ietf-isis-
      mi-01.txt, work in progress, February 2008.

   [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
      Authentication", RFC 5304, October 2008..















D. Eastlake, R. Perlman, & D. Dutt                             [Page 17]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


Disclaimer

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Additional IPR Provisions

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

   Copyright (C) The IETF Trust 2008.  This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.













D. Eastlake, R. Perlman, & D. Dutt                             [Page 18]


INTERNET-DRAFT                                    RBridges: Use of IS-IS


Author's Address

   Donald E. Eastlake 3rd
   Eastlake Enterprises
   155 Beaver Street
   Milford, MA 01757 USA

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


   Radia Perlman
   Sun Microsystems
   16 Network Circle
   Menlo Park, CA 94025

   Phone: +1-650-960-1300
   Email: Radia.Perlman@sun.com


   Dinesh G. Dutt
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134-1706 USA

   Phone: +1-408-527-0955
   email: ddutt@cisco.com



Expiration and File Name

   This draft expires in May 2009.

   Its file name is <draft-eastlake-trill-rbridge-isis-02.txt>.

















D. Eastlake, R. Perlman, & D. Dutt                             [Page 19]