Network Working Group                                    Donald Eastlake
INTERNET-DRAFT                                                    Huawei
Intended status: Proposed Standard                         Ayan Banerjee
Obsoletes: 6326                                                    Cisco
                                                          Anoop Ghanwani
                                                                    Dell
                                                           Radia Perlman
                                                                   Intel
                                                             Dinesh Dutt
Expires: September 9, 2012                                March 10, 2012



   Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
                <draft-eastlake-isis-rfc6326bis-07.txt>


Abstract

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol provides optimal pair-wise data frame forwarding without
   configuration in multi-hop networks with arbitrary topology, and
   support for multipathing of both unicast and multicast traffic. This
   document specifies the data formats and code points for the IS-IS
   extensions to support TRILL. These data formats and code points may
   also be used by technologies other than TRILL. This document
   obsoletes RFC 6326.


Status of This Memo

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

   Distribution of this document is unlimited. Comments should be sent
   to the TRILL working group mailing list.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html



D. Eastlake, et al.                                             [Page 1]


INTERNET-DRAFT                                        TRILL Use of IS-IS


Table of Contents

      1. Introduction............................................3
        1.1 Conventions Used in This Document....................3
      2.  TLV and Sub-TLV Extensions to IS-IS for TRILL..........5
        2.1 Group Address TLV....................................5
        2.1.1 Group MAC Address Sub-TLV..........................5
        2.1.2 Group IPv4 Address Sub-TLV.........................7
        2.1.3 Group IPv6 Address Sub-TLV.........................8
        2.1.4 Group Labeled MAC Address Sub-TLV..................8
        2.1.5 Group Labeled IPv4 Address Sub-TLV................10
        2.1.6 Group Labeled IPv6 Address Sub-TLV................11
        2.2 Multi-Topology-Aware Port Capability Sub-TLVs.......11
        2.2.1 Special VLANs and Flags Sub-TLV...................12
        2.2.2 Enabled-VLANs Sub-TLV.............................13
        2.2.3 Appointed Forwarders Sub-TLV......................14
        2.2.4 Port TRILL Version Sub-TLV........................15
        2.2.5 VLANs Appointed Sub-TLV...........................16
        2.3 Sub-TLVs for the Router Capability TLV..............17
        2.3.1 TRILL Version Sub-TLV.............................17
        2.3.2 Nickname Sub-TLV..................................18
        2.3.3 Trees Sub-TLV.....................................19
        2.3.4 Tree Identifiers Sub-TLV..........................20
        2.3.5 Trees Used Identifiers Sub-TLV....................21
        2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV..21
        2.3.7 VLAN Group Sub-TLV................................23
        2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV.24
        2.3.9 RBridge Channel Protocols Sub-TLV.................26
        2.3.10 Affinity Sub-TLV.................................27
        2.3.11 Label Group Sub-TLV..............................29
        2.3.12 Nickname Flags Sub-TLV...........................30
        2.4 MTU Sub-TLV of the Extended Reachability TLV........31
        2.5 TRILL Neighbor TLV..................................31
      3. MTU PDUs...............................................34
      4. Use of Existing PDUs and TLVs..........................35
        4.1 TRILL IIH PDUs......................................35
        4.2 Area Address........................................35
        4.3 Protocols Supported.................................35
        4.4 Link State PDUs (LSPs)..............................36
        4.5 Originating LSP Buffer Size.........................36
      5. IANA Considerations....................................37
        5.1 TLVs................................................37
        5.2 sub-TLVs............................................37
        5.3 PDUs................................................38
        5.4 Reserved and Capability Bits........................39
        5.5 TRILL Neighbor Record Flags.........................39
      6. Security Considerations................................40
      7. Change from RFC 6326...................................41
      8. Normative References...................................43
      9. Informative References.................................44
      Acknowledgements..........................................45

D. Eastlake, et al.                                             [Page 2]


INTERNET-DRAFT                                        TRILL Use of IS-IS


1. Introduction

   The IETF TRILL (Transparent Interconnection of Lots of Links)
   protocol [RFC6325] [RFC6327] provides transparent forwarding in
   multi-hop networks with arbitrary topology using encapsulation with a
   hop count and link state routing.  TRILL provides optimal pair-wise
   forwarding without configuration, safe forwarding even during periods
   of temporary loops, and support for multipathing of both unicast and
   multicast traffic.  Intermediate Systems (ISs) implementing TRILL are
   called RBridges (Routing Bridges) or TRILL Switches.

   This document, in conjunction with [RFC6165], specifies the data
   formats and code points for the IS-IS [ISO-10589] [RFC1195]
   extensions to support TRILL. These data formats and code points may
   also be used by technologies other than TRILL.

   This document obsoletes [RFC6326]. [RFC6326] generally corresponds to
   the base TRILL protocol as it was passed up to the IESG in 2009.
   There has been substantial development of TRILL since them. The main
   changes from [RFC6326] are summarized below and a full list is given
   in Section 7.

   1. Fix the reported errata in [RFC6326].

   2. Addition of multicast group announcements by IPv4 and IPv6
      address.

   3. Addition of control plane support for 24-bit TRILL Data frame
      labels.

   4. Addition of facilities for announcing capabilities supported.

   5. Addition of a tree affinity sub-TLV whereby ISs can request
      distribution tree association.

   Changes herein to TLVs and sub-TLVs specified in [RFC6326] are
   backwards compatible.



1.1 Conventions Used in This Document

   The terminology and acronyms defined in [RFC6325] are used herein
   with the same meaning.

   Additional acronyms and phrases used in this document are:

   BVL - Bit Vector Length

   BVO - Bit Vector Offset


D. Eastlake, et al.                                             [Page 3]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   IIH - IS-IS Hello

   IS - Intermediate System. For this document, all relevant
        intermediate systems are RBridges [RFC6325].

   NLPID - Network Layer Protocol Identifier

   SNPA - SubNetwork Point of Attachment (MAC Address)

   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 [RFC2119].








































D. Eastlake, et al.                                             [Page 4]


INTERNET-DRAFT                                        TRILL Use of IS-IS


2.  TLV and Sub-TLV Extensions to IS-IS for TRILL

   This section, in conjunction with [RFC6165], specifies the data
   formats and code points for the TLVs and sub-TLVs for IS-IS to
   support the IETF TRILL protocol. Information as to the number of
   occurrences allowed, such as for a TLV in a PDU or set of PDUs or for
   a sub-TLV in a TLV, is summarized in Section 5.




2.1 Group Address TLV

   The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an
   LSP PDU and carries sub-TLVs that in turn advertise multicast group
   listeners.  The sub-TLVs that advertises listeners are specified
   below. The sub-TLVs under GADDR constitute a new series of sub-TLV
   types (see Section 5.2).

   GADDR has the following format:

      +-+-+-+-+-+-+-+-+
      |Type=GADDR-TLV |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
      |      sub-TLVs...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-...

   o  Type: TLV Type, set to GADDR-TLV 142.

   o  Length: variable depending on the sub-TLVs carried.

   o  sub-TLVs: The Group Address TLV value consists of sub-TLVs
      formatted as described in [RFC5305].



2.1.1 Group MAC Address Sub-TLV

   The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1
   within the GADDR TLV.  In TRILL, it is used to advertise multicast
   listeners by MAC address as specified in Section 4.5.5 of [RFC6325].
   It has the following format:








D. Eastlake, et al.                                             [Page 5]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      +-+-+-+-+-+-+-+-+
      |Type=GMAC-ADDR |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  RESV |     Topology-ID       |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  RESV |     VLAN ID           |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Num Group Recs |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   GROUP RECORDS (1)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   GROUP RECORDS (2)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   .................                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   GROUP RECORDS (N)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the following form with k=6:

      +-+-+-+-+-+-+-+-+
      | Num of Sources|                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Group Address         (k bytes)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source 1 Address      (k bytes)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source 2 Address      (k bytes)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    .....                                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source M Address      (k bytes)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).

   o  Length: 5 + m + k*n = 5 + m + 6*n where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  RESV: Reserved.  4-bit fields that MUST be sent as zero and
      ignored on receipt.

   o  Topology-ID: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  VLAN ID: This carries the 12-bit VLAN identifier for all
      subsequent MAC addresses in this sub-TLV, or the value zero if no


D. Eastlake, et al.                                             [Page 6]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      VLAN is specified.

   o  Number of Group Records: A 1-byte unsigned integer that is the
      number of group records in this sub-TLV.

   o  Group Record: Each group record carries the number of sources. If
      this field is zero, it indicates a listener for (*,G), that is, a
      listener not restricted by source. It then has a 6-byte (48-bit)
      multicast address followed by 6-byte source MAC addresses.  If the
      sources do not fit in a single sub-TLV, the same group address may
      be repeated with different source addresses in another sub-TLV of
      another instance of the Group Address TLV.

   The GMAC-ADDR sub-TLV is carried only within a GADDR TLV.



2.1.2 Group IPv4 Address Sub-TLV

   The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type TBD
   [2 suggested] within the GADDR TLV. It has the same format as the
   Group MAC Address sub-TLV described in Section 2.1.1 except that k=4.
   The fields are as follows:

   o  Type: sub-TLV Type, set to TBD [2 suggested] (GIP-ADDR).

   o  Length: 5 + m + k*n = 5 + m + 4*n where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-Id: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
      all subsequent addresses in this sub-TLV, or the value zero if no
      VLAN is specified.

   o  Number of Group Records: This is of length 1 byte and lists the
      number of group records in this sub-TLV.

   o  Group Record: Each group record carries the number of sources. If
      this field is zero, it indicates a listener for (*,G), that is, a
      listener not restricted by source. It then has a 4-byte (32-bit)
      IPv4 Group Address followed by 4-byte source IPv4 addresses.  If
      the number of sources do not fit in a single sub-TLV, it is
      permitted to have the same group address repeated with different
      source addresses in another sub-TLV of another instance of the


D. Eastlake, et al.                                             [Page 7]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      Group Address TLV.

   The GIP-ADDR sub-TLV is carried only within a GADDR TLV.



2.1.3 Group IPv6 Address Sub-TLV

   The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type TBD
   [3 suggested] within the GADDR TLV. It has the same format as the
   Group MAC Address sub-TLV described in Section 2.1.1 except that
   k=16.  The fields are as follows:

   o  Type: sub-TLV Type, set to TBD [3 suggested] (GIPV6-ADDR).

   o  Length: 5 + m + k*n = 5 + m + 16*n where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-Id: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
      all subsequent addresses in this sub-TLV, or the value zero if no
      VLAN is specified.

   o  Number of Group Records: This is of length 1 byte and lists the
      number of group records in this sub-TLV.

   o  Group Record: Each group record carries the number of sources. If
      this field is zero, it indicates a listener for (*,G), that is, a
      listener not restricted by source. It then has a 16-byte (128-bit)
      IPv6 Group Address followed by 16-byte source IPv6 addresses.  If
      the number of sources do not fit in a single sub-TLV, it is
      permitted to have the same group address repeated with different
      source addresses in another sub-TLV of another instance of the
      Group Address TLV.

   The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV.



2.1.4 Group Labeled MAC Address Sub-TLV

   The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in
   Section 2.1.1 provides for a 12-bit VLAN-ID. The Group Labeled MAC
   Address sub-TLV, below, extends this to a 24-bit fine-grained label.


D. Eastlake, et al.                                             [Page 8]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   +-+-+-+-+-+-+-+-+
   |Type=GLMAC-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |     Topology-ID       |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          24-Bit Label                         | (3 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (2)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the following form with k=6:

   +-+-+-+-+-+-+-+-+
   | Num of Sources|                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address         (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    .....                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: GADDR sub-TLV Type, set to TBD [4 suggested] (GLMAC-ADDR).

   o  Length: 6 + m + k*n = 6 + m + 6*n where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  RESV: Reserved. 4-bit field that MUST be sent as zero and ignored
      on receipt.

   o  Topology-ID: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  Label: This carries the 24-bit fine-grained label identifier for
      all subsequent MAC addresses in this sub-TLV, or the value zero if


D. Eastlake, et al.                                             [Page 9]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      no label is specified.

   o  Number of Group Records: A 1-byte unsigned integer that is the
      number of group records in this sub-TLV.

   o  Group Record: Each group record carries the number of sources. If
      this field is zero, it indicates a listener for (*,G), that is, a
      listener not restricted by source. It then has a 6-byte (48-bit)
      multicast address followed by 6-byte source MAC addresses.  If the
      sources do not fit in a single sub-TLV, the same group address may
      be repeated with different source addresses in another sub-TLV of
      another instance of the Group Address TLV.

   The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV.



2.1.5 Group Labeled IPv4 Address Sub-TLV

   The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV
   type TBD [5 suggested] within the GADDR TLV. It has the same format
   as the Group Labeled MAC Address sub-TLV described in Section 2.1.4
   except that k=4. The fields are as follows:

   o  Type: sub-TLV Type, set to TBD [5 suggested] (GLIP-ADDR).

   o  Length: 6 + m + k*n = 6 + m + 4*n where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-Id: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  Label: This carries the 24-bit fine-grained label identifier for
      all subsequent IPv4 addresses in this sub-TLV, or the value zero
      if no label is specified.

   o  Number of Group Records: This is of length 1 byte and lists the
      number of group records in this sub-TLV.

   o  Group Record: Each group record carries the number of sources. If
      this field is zero, it indicates a listener for (*,G), that is, a
      listener not restricted by source. It then has a 4-byte (32-bit)
      IPv4 Group Address followed by 4-byte source IPv4 addresses.  If
      the number of sources do not fit in a single sub-TLV, it is
      permitted to have the same group address repeated with different
      source addresses in another sub-TLV of another instance of the


D. Eastlake, et al.                                            [Page 10]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      Group Address TLV.

   The GLIP-ADDR sub-TLV is carried only within a GADDR TLV.



2.1.6 Group Labeled IPv6 Address Sub-TLV

   The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV
   type TBD [6 suggested] within the GADDR TLV. It has the same format
   as the Group Labeled MAC Address sub-TLV described in Section 2.1.4
   except that k=16. The fields are as follows:

   o  Type: sub-TLV Type, set to TBD [6 suggested] (GLIPV6-ADDR).

   o  Length: 6 + m + k*n = 6 + m + 16*n where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-Id: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  Label: This carries the 24-bit fine-grained label identifier for
      all subsequent IPv6 addresses in this sub-TLV, or the value zero
      if no label is specified.

   o  Number of Group Records: This of length 1 byte and lists the
      number of group records in this sub-TLV.

   o  Group Record: Each group record carries the number of sources. If
      this field is zero, it indicates a listener for (*,G), that is, a
      listener not restricted by source. It then has a 16-byte (128-bit)
      IPv6 Group Address followed by 16-byte source IPv6 addresses.  If
      the number of sources do not fit in a single sub-TLV, it is
      permitted to have the same group address repeated with different
      source addresses in another sub-TLV of another instance of the
      Group Address TLV.

   The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV.




2.2 Multi-Topology-Aware Port Capability Sub-TLVs

   TRILL makes use of the Multi-Topology-Aware Port Capability (MT-PORT-
   CAP) TLV as specified in [RFC6165].  The following subsections of


D. Eastlake, et al.                                            [Page 11]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   this Section 2.2 specify the sub-TLVs transported by the MT-PORT-CAP
   TLV for TRILL.



2.2.1 Special VLANs and Flags Sub-TLV

   In TRILL, a Special VLANs and Flags (VLAN-Flags) sub-TLV is carried
   in every IIH PDU.  It has the following format:

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

      o  Type: sub-TLV type, set to MT-PORT-CAP VLAN-FLAGs sub-TLV 1.

      o  Length: 8.

      o  Port ID: An ID for the port on which the enclosing TRILL IIH
         PDU is being sent as specified in [RFC6325], Section 4.4.2.

      o  Sender Nickname: If the sending IS is holding any nicknames as
         discussed in [RFC6325], Section 3.7, one MUST be included here.
         Otherwise, the field is set to zero. This field is to support
         intelligent end stations that determine the egress IS (RBridge)
         for unicast data through a directory service or the like and
         that need a nickname for their first hop to insert as the
         ingress nickname to correctly format a TRILL Data frame (see
         [RFC6325], Section 4.6.2, point 8). It is also referenced in
         connection with the VLANs Appointed Sub-TLV (see Section
         2.2.5).

      o  Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH
         frame containing this sub-TLV when that frame was sent, as
         specified in [RFC6325], Section 4.4.5.

      o  Desig.VLAN: The 12-bit ID of the Designated VLAN for the link,
         as specified in [RFC6325], Section 4.2.4.2.




D. Eastlake, et al.                                            [Page 12]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      o  AF, AC, VM, BY, and TR: These flag bits have the following
         meanings when set to one, as specified in the listed section of
         [RFC6325]:

              RFC 6325
         Bit  Section   Meaning if bit is one
         --------------------------------------

         AF   4.4.2     Originating IS believes it is appointed
                        forwarder for the VLAN and port on which the
                        containing IIH PDU was sent.

         AC   4.9.1     Originating port configured as an access port
                        (TRILL traffic disabled).

         VM   4.4.5     VLAN mapping detected on this link.

         BY   4.4.2     Bypass pseudonode.

         TR   4.9.1     Originating port configured as a trunk port
                        (end-station service disabled).

      o  R: Reserved bit. MUST be sent as zero and ignored on receipt.



2.2.2 Enabled-VLANs Sub-TLV

   The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the
   port of the originating IS on which the containing Hello was sent, as
   specified in [RFC6325], Section 4.4.2. It has the following format:

      +-+-+-+-+-+-+-+-+
      |     Type      |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RESV  |  Start VLAN ID        |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | VLAN bit-map....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV type, set to MT-PORT-CAP Enabled-VLANs sub-TLV 2.

   o  Length: Variable, minimum 3.

   o  RESV: 4 reserved bits that MUST be sent as zero and ignored on
      receipt.

   o  Start VLAN ID: The 12-bit VLAN ID that is represented by the high


D. Eastlake, et al.                                            [Page 13]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      order bit of the first byte of the VLAN bit-map.

   o  VLAN bit-map: 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.

   If this sub-TLV occurs more than once in a Hello, the set of enabled
   VLANs is the union of the sets of VLANs indicated by each of the
   Enabled-VLAN sub-TLVs in the Hello.



2.2.3 Appointed Forwarders Sub-TLV

   The DRB on a link uses the Appointed Forwarders sub-TLV to inform
   other ISs on the link that they are the designated VLAN-x forwarder
   for one or more ranges of VLAN IDs as specified in [RFC6439]. It has
   the following format:

      +-+-+-+-+-+-+-+-+
      |     Type      |                          (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                          (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Appointment Information (1)         |  (6 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Appointment Information (2)         |  (6 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   .................                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Appointment Information (N)         |  (6 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each appointment is of the form:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Appointee Nickname              |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RESV  |        Start.VLAN             |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RESV  |        End.VLAN               |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV type, set to MT-PORT-CAP AppointedFwrdrs sub-TLV 3.

   o  Length: 6*n bytes, where there are n appointments.

   o  Appointee Nickname: The nickname of the IS being appointed a
      forwarder.


D. Eastlake, et al.                                            [Page 14]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   o  RESV: 4 bits that MUST be sent as zero and ignored on receipt.

   o  Start.VLAN, End.VLAN: These fields are the VLAN IDs of the
      appointment range, inclusive. To specify a single VLAN, the VLAN's
      ID appears as both the start and end VLAN. As specified in
      [RFC6439], appointing an IS forwarder on a port for a VLAN not
      enabled on that port has no effect. If the range specified is or
      includes the value 0x000 or 0xFFF, such values are ignored as they
      are not valid VLAN numbers and a port cannot be enabled for them.

   An IS's nickname may occur as appointed forwarder for multiple VLAN
   ranges by occurrences of this sub-TLV within the same or different MT
   Port Capability TLVs within an IIH PDU. See [RFC6439].



2.2.4 Port TRILL Version Sub-TLV

   The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum
   version of the TRILL standard supported and the support of optional
   hop-by-hop capabilities.  By implication, lower versions are also
   supported. If this sub-TLV is missing from an IIH, it is assumed that
   the originating IS only supports the base version (version zero) of
   the protocol [RFC6325] and supports no optional capabilities
   indicated by this sub-TLV.

   +-+-+-+-+-+-+-+-+
   | Type          |              (1 byte)
   +-+-+-+-+-+-+-+-+
   | Length        |              (1 byte)
   +-+-+-+-+-+-+-+-+
   | Max-version   |              (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   | Capabilities and Header Flags Supported |  (4 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
                      1 1 1 1 1 1 1 1 1   3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7   0 1

   o  Type: MT-PORT-CAP sub-TLV type, set to TBD (PORT-TRILL-VER).

   o  Length: 5.

   o  Max-version: A one byte unsigned integer set to maximum version
      supported.

   o  Capabilities and Header Flags Supported: A bit vector of 32 bits
      numbered 0 through 31 in network order. Bits 3 through 13 indicate
      that the corresponding TRILL Header hop-by-hop extended flags
      [ExtendHeader] are supported. Bits 0 through 2 and 14 to 31 are
      reserved to indicate support of optional capabilities. A one bit


D. Eastlake, et al.                                            [Page 15]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      indicates that the flag or capability is supported by the sending
      IS. Bits in this field MUST be set to zero except as permitted for
      a capability being advertised or if a hop-by-hop extended header
      flag is supported.

   This sub-TLV, if present, MUST occur in an MT-PORT-CAP TLV in a TRILL
   IIH. If there is more than one occurrence, the minimum of the
   supported versions is assumed to be correct and a capability or
   header flag is assumed to be supported only if indicated by all
   occurrences. The flags and capabilities for which support can be
   indicated in this sub-TLV are disjoint from those in the TRILL-VER
   sub-TLV (Section 2.3.1) so they cannot conflict. The flags and
   capabilities indicated in this sub-TLV relate to hop-by-hop
   processing that can differ between the ports of an IS (RBridge), and
   thus must be advertised in IIHs. For example, a capability requiring
   cryptographic hardware assist might be supported on some ports and
   not others. However, the TRILL version is the same as that in the
   PORT-TRILL-VER sub-TLV and an IS, if it is adjacent to the sending IS
   of TRILL-VER sub-TLV(s) uses the TRILL version it received in PORT-
   TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-
   TLV(s).



2.2.5 VLANs Appointed Sub-TLV

   The optional VLANs sub-TLV specifies the VLANs for which a port of
   the originating IS on which the containing Hello was sent is
   appointed forwarder. It has the following format:

      +-+-+-+-+-+-+-+-+
      |     Type      |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RESV  |  Start VLAN ID        |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | VLAN bit-map....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV type, set to MT-PORT-CAP VLANS-Appointed sub-TLV
      TBD.

   o  Length: Variable, minimum 3.

   o  RESV: 4 reserved bits that MUST be sent as zero and ignored on
      receipt.

   o  Start VLAN ID: The 12-bit VLAN ID that is represented by the high
      order bit of the first byte of the VLAN bit-map.


D. Eastlake, et al.                                            [Page 16]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   o  VLAN bit-map: 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.

   If this sub-TLV occurs more than once in a Hello, the originating IS
   is declaring it believes itself to be appointed forwarder on the port
   on which the enclosing IIH was sent for the union of the sets of
   VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello.




2.3 Sub-TLVs for the Router Capability TLV

   The Router Capability TLV is specified in [RFC4971]. All of the sub-
   sections of this Section 2.3 below specify sub-TLVs that can be
   carried in the Router Capability TLV for TRILL which in turn is
   carried only by LSPs.



2.3.1 TRILL Version Sub-TLV

   The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version
   of the TRILL standard supported and the support of optional
   capabilities by the originating IS. By implication, lower versions
   are also supported. If this sub-TLV is missing, it is assumed that
   the originating IS only supports the base version (version zero) of
   the protocol [RFC6325] and no optional capabilities indicated by this
   sub-TLV are supported.

   +-+-+-+-+-+-+-+-+
   | Type          |              (1 byte)
   +-+-+-+-+-+-+-+-+
   | Length        |              (1 byte)
   +-+-+-+-+-+-+-+-+
   | Max-version   |              (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   | Capabilities and Header Flags Supported |  (4 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
                      1 1 1 1 1 1 1 1 1   3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7   0 1

   o  Type: Router Capability sub-TLV type, set to 13 (TRILL-VER).

   o  Length: 5.

   o  Max-version: A one byte unsigned integer set to maximum version
      supported.


D. Eastlake, et al.                                            [Page 17]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   o  Capabilities and Header Flags Supported: A bit vector of 32 bits
      numbered 0 through 31 in network order. Bits 14 through 31
      indicate that the corresponding TRILL Header extended flags
      [ExtendHeader] are supported. Bits 0 through 13 are reserved to
      indicate support of optional capabilities. A one bit indicates
      that the originating IS supports the flag or capability. For
      example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in
      this field MUST be set to zero except as permitted for a
      capability being advertised or an extended header flag supported.

   This sub-TLV, if present, MUST occur in a Router Capabilities TLV in
   the LSP number zero for the originating IS. If found in other
   fragments, it is ignored. If there is more than one occurrence in LSP
   number zero, the minimum of the supported versions is assumed to be
   correct and an extended header flag or capability is assumed to be
   supported only if indicated by all occurrences. The flags and
   capabilities supported bits in this sub-TLV are disjoint from those
   in the PORT-TRILL-VER sub-TLV (Section 2.2.4) so they cannot
   conflict. However, the TRILL version is the same as that in the PORT-
   TRILL-VER sub-TLV and an IS that is adjacent to the originating IS of
   TRILL-VER sub-TLV(s) uses the TRILL version it received in PORT-
   TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-
   TLV(s).



2.3.2 Nickname Sub-TLV

   The Nickname (NICKNAME) Router Capability sub-TLV carries information
   about the nicknames of the originating IS, along with information
   about its priority to hold those nicknames as specified in [RFC6325],
   Section 3.7.3. Multiple instances of this sub-TLV may be carried.

      +-+-+-+-+-+-+-+-+
      |Type = NICKNAME|                         (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                         (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                NICKNAME RECORDS (1)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                NICKNAME RECORDS (2)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   .................                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                NICKNAME RECORDS (N)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each nickname record is of the form:




D. Eastlake, et al.                                            [Page 18]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      +-+-+-+-+-+-+-+-+
      | Nickname.Pri  |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Tree Root Priority        |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Nickname            |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: Router Capability sub-TLV type, set to 6 (NICKNAME).

   o  Length: 5*n, where n is the number of nickname records present.

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

   o  Tree Root Priority: This is an unsigned 16-bit integer priority to
      be a tree root as specified in Section 4.5 of [RFC6325].

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



2.3.3 Trees Sub-TLV

   Each IS providing TRILL service uses the TREES sub-TLV to announce
   three numbers related to the computation of distribution trees as
   specified in Section 4.5 of [RFC6325]. Its format is as follows:

      +-+-+-+-+-+-+-+-+
      |Type =  TREES  |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |  Length       |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Number of trees to compute    |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Maximum trees able to compute |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Number of trees to use        |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: Router Capability sub-TLV type, set to 7 (TREES).

   o  Length: 6.

   o  Number of trees to compute: An unsigned 16-bit integer as
      specified in Section 4.5 of [RFC6325].

   o  Maximum trees able to compute: An unsigned 16-bit integer as
      specified in Section 4.5 of [RFC6325].


D. Eastlake, et al.                                            [Page 19]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   o  Number of trees to use: An unsigned 16-bit integer as specified in
      Section 4.5 of [RFC6325].



2.3.4 Tree Identifiers Sub-TLV

   The tree identifiers (TREE-RT-IDs) sub-TLV is an ordered list of
   nicknames. When originated by the IS that has the highest priority to
   be a tree root, it lists the distribution trees that the other ISs
   are required to compute as specified in Section 4.5 of [RFC6325]. If
   this information is spread across multiple sub-TLVs, the starting
   tree number is used to allow the ordered lists to be correctly
   concatenated. The sub-TLV format is as follows:

      +-+-+-+-+-+-+-+-+
      |Type=TREE-RT-IDs|               (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Starting Tree Number         |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Nickname (K-th root)      |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Nickname (K+1 - th root)  |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Nickname (...)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: Router Capability sub-TLV type, set to 8 (TREE-RT-IDs).

   o  Length: 2 + 2*n, where n is the number of nicknames listed.

   o  Starting Tree Number: This identifies the starting tree number of
      the nicknames that are trees for the domain. This is set to 1 for
      the sub-TLV containing the first list. Other Tree-Identifiers sub-
      TLVs will have the number of the starting list they contain.  In
      the event the same tree identifier can be computed from two such
      sub-TLVs and they are different, then it is assumed that this is a
      transient condition that will get cleared. During this transient
      time, such a tree SHOULD NOT be computed unless such computation
      is indicated by all relevant sub-TLVs present.

   o  Nickname: The nickname at which a distribution tree is rooted.








D. Eastlake, et al.                                            [Page 20]


INTERNET-DRAFT                                        TRILL Use of IS-IS


2.3.5 Trees Used Identifiers Sub-TLV

   This Router Capability sub-TLV has the same structure as the Tree
   Identifiers sub-TLV specified in Section 2.3.4. The only difference
   is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees
   listed are those that the originating IS wishes to use as specified
   in [RFC6325], Section 4.5.



2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV

   The value of this Router Capability sub-TLV consists of a VLAN range
   and information in common to all of the VLANs in the range for the
   originating IS. This information consists of flags, a variable length
   list of spanning tree root bridge IDs, and an appointed forwarder
   status lost counter, all as specified in the sections of [RFC6325]
   listed with the respective information items below.

   In the set of LSPs originated by an IS, the union of the VLAN ranges
   in all occurrences of this sub-TLV MUST be the set of VLANs for which
   the originating IS is appointed forwarder on at least one port, and
   the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap
   unless the information provided about a VLAN is the same in every
   instance. However, as a transient state these conditions may be
   violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS,
   that IS is assumed to be uninterested in receiving traffic for that
   VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS
   with different information in the different instances, the following
   apply:

   -  If those sub-TLVs provide different nicknames, it is unspecified
      which nickname takes precedence.
   -  The largest appointed forwarder status lost counter, using serial
      number arithmetic [RFC1982], is used.
   -  The originating IS is assumed to be attached to a multicast IPv4
      router for that VLAN if any of the INT-VLAN sub-TLVs assert that
      it is so connected and similarly for IPv6 multicast router
      attachment.
   -  The root bridge lists from all of the instances of the VLAN for
      the originating IS are merged.

   To minimize such occurrences, wherever possible, an implementation
   SHOULD advertise the update to an interested VLAN and Spanning Tree
   Roots sub-TLV in the same LSP fragment as the advertisement that it
   replaces. Where this is not possible, the two affected LSP fragments
   should be flooded as an atomic action. An IS that receives an update
   to an existing interested VLAN and Spanning Tree Roots sub-TLV can
   minimize the potential disruption associated with the update by
   employing a hold-down timer prior to processing the update so as to


D. Eastlake, et al.                                            [Page 21]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   allow for the receipt of multiple LSP fragments associated with the
   same update prior to beginning processing.

   The sub-TLV layout is as follows:

   +-+-+-+-+-+-+-+-+
   |Type = INT-VLAN|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Nickname                    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
   |   Interested VLANS                            |        (4 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
   |   Appointed Forwarder Status Lost Counter     |        (4 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+
   |         Root Bridges                                |  (6*n bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+

   o  Type: Router Capability sub-TLV type, set to 10 (INT-VLAN).

   o  Length: 10 + 6*n, where n is the number of root bridge IDs.

   o  Nickname: As specified in [RFC6325], Section 4.2.4.4, this field
      may be used to associate a nickname held by the originating IS
      with the VLAN range indicated. When not used in this way, it is
      set to zero.

   o  Interested VLANS: The Interested VLANs field is formatted as shown
      below.

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

      -  M4, M6: These bits indicate, respectively, that there is an
         IPv4 or IPv6 multicast router on a link for which the
         originating IS is appointed forwarder for every VLAN in the
         indicated range as specified in [RFC6325], Section 4.2.4.4,
         item 5.1.

      -  R, RESV: These reserved bits MUST be sent as zero and are
         ignored on receipt.

      -  VLAN.start and VLAN.end: This VLAN ID range is inclusive.
         Setting both VLAN.start and VLAN.end to the same value
         indicates a range of one VLAN ID. If VLAN.start is not equal to
         VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as
         if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end


D. Eastlake, et al.                                            [Page 22]


INTERNET-DRAFT                                        TRILL Use of IS-IS


         and VLAN.end is 0xFFF, the sub-TVL is interpreted as if
         VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the
         sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000
         or both are 0xFFF, the sub-TLV is ignored.

   o  Appointed Forwarder Status Lost Counter: This is a count of how
      many times a port that was appointed forwarder for the VLANs in
      the range given has lost the status of being an appointed
      forwarder for some port as discussed in Section 4.8.3 of
      [RFC6325]. It is initialized to zero at an IS when the zeroth LSP
      sequence number is initialized. No special action need be taken at
      rollover; the counter just wraps around.

   o  Root Bridges: 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
      IS is appointed forwarder for the VLANs in the specified range as
      discussed in [RFC6325], Section 4.9.3.2. While, of course, at most
      one spanning tree root could be seen on any particular port, there
      may be multiple ports in the same VLANs connected to different
      bridged LANs with different spanning tree roots.

   An INT-VLAN sub-TLV asserts that the information provided (multicast
   router attachment, appointed forwarder status lost counter, and root
   bridges) is the same for all VLANs in the range specified. If this is
   not the case, the range MUST be split into subranges meeting this
   criteria. It is always safe to use sub-TLVs with a "range" of one
   VLAN ID, but this may be too verbose.



2.3.7 VLAN Group Sub-TLV

   The VLAN Group Router Capability sub-TLV consists of two or more VLAN
   IDs as specified in [RFC6325], Section 4.8.4. This sub-TLV indicates
   that shared VLAN learning is occurring at the originating IS between
   the listed VLANs. It is structured as follows:

      +-+-+-+-+-+-+-+-+
      |Type=VLAN-GROUP|                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RESV  |  Primary VLAN ID      |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RESV  |  Secondary VLAN ID    |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  more Secondary VLAN IDs ...     (2 bytes each)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: Router Capability sub-TLV type, set to 14 (VLAN-GROUP).


D. Eastlake, et al.                                            [Page 23]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   o  Length: 4 + 2*n, where n is the number of secondary VLAN ID fields
      beyond the first. n MAY be zero.

   o  RESV: a 4-bit field that MUST be sent as zero and ignored on
      receipt.

   o  Primary VLAN ID: This identifies the primary VLAN ID.

   o  Secondary VLAN ID: This identifies a secondary VLAN in the VLAN
      Group.

   o  more Secondary VLAN IDs: zero or more byte pairs, each with the
      top 4 bits as a RESV field and the low 12 bits as a VLAN ID.



2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV

   An IS that can handle 24-bit fine-grained labeling announces its
   fine-grained label connectivity and related information in the
   "Interested Labels and Bridge Spanning Tree Roots sub-TLV" (INT-
   LABEL) which is a variation of the "Interested VLANs and Spanning
   Tree Roots sub-TLV" (INT-VLAN) structured as below.

   +-+-+-+-+-+-+-+-+
   |Type= INT-LABEL|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Nickname                    |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
   |   Interested Labels                                 |  (7 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
   |   Appointed Forwarder Status Lost Counter           |  (4 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
   |         Root Bridges                                |  (6*n bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+


   o  Type: Router Capability sub-TLV Type, set to TBD [15 suggested]
      (INT-LABEL).

   o  Length: 11 + 6*n where n is the number of root bridge IDs.

   o  Nickname: This field may be used to associate a nickname held by
      the originating IS with the Labels indicated. When not used in
      this way, it is set to zero.

   o  Interested Labels: The Interested Labels field is seven bytes long
      and formatted as shown below.


D. Eastlake, et al.                                            [Page 24]


INTERNET-DRAFT                                        TRILL Use of IS-IS


        0  1  2  3  4  5  6  7
      +--+--+--+--+--+--+--+--+
      |M4|M6|BM| R| R| R| R| R|               .               .
      +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Label.start - 24 bits                  |
      +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Label.end or Bit Map - 24 bits              |
      +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   1 1 1 1 1 1 1 1 1 1 2 2 2 2
        0  1  2  3  4  5  6  7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

      -  M4, M6: These bits indicate, respectively, that there is an
         IPv4 or IPv6 multicast router on a link to which the
         originating IS is appointed forwarder for the VLAN
         corresponding to every label in the indicated range.

      -  BM: If the BM (Bit Map) bit is zero, the last three bytes of
         the Interested Labels is a Label.end label number. If the BM
         bit is one, those bytes are a bit map as described below.

      -  R: These reserved bits MUST be sent as zero and are ignored on
         receipt.

      -  Label.start and Label.end: If the BM bit is zero: This fine-
         grained label ID range is inclusive. These fields are treated
         as unsigned integers. Setting them both to that same label ID
         value indicates a range of one label ID. If Label.end is less
         than Label.start, the sub-TLV is ignored.

      -  Label.start and Bit Map: If the BM bit is one: The fine-grained
         labels that the IS is interested in are indicated by a 24-bit
         bit map. The interested labels are the Label.start number plus
         the bit number of each one bit in the bit map. So, if bit zero
         of the bit map is a one, the IS in interested in the label with
         value Label.start and if bit 23 of the bit map is a one, the IS
         is interested in the label with value Label.start+23.

   o  Appointed Forwarder Status Lost Counter: This is a count of how
      many times a port that was appointed forwarder for a VLAN mapping
      to the fine-grained label in the range or bit map given has lost
      the status of being an appointed forwarder as discussed in Section
      4.8.3 of [RFC6325]. It is initialized to zero at an IS when the
      zeroth LSP sequence number is initialized. No special action need
      be taken at rollover; the counter just wraps around.

   o Root Bridges: 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
      IS is appointed forwarder for a VLAN mapping to the fine-grained
      label in the specified range or bit map. (See [RFC6325], Section
      4.9.3.2.)  While, of course, at most one spanning tree root could


D. Eastlake, et al.                                            [Page 25]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      be seen on any particular port, there may be multiple relevant
      ports connected to different bridged LANs with different spanning
      tree roots.

   An INT-LABEL sub-TLV asserts that the information provided (multicast
   router attachment, appointed forwarder status lost counter, and root
   bridges) is the same for all labels specified. If this is not the
   case, the sub-TLV MUST be split into subranges and/or separate bit
   maps meeting this criteria. It is always safe to use sub-TLVs with a
   "range" of one VLAN ID, but this may be too verbose.



2.3.9 RBridge Channel Protocols Sub-TLV

   An IS announces the RBridge Channel protocols [Channel] it supports
   through use of this sub-TLV.

      +-+-+-+-+-+-+-+-+
      |Type=RBCHANNELS|                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
      |   Zero or more bit vectors                            (variable)
      +-+-+-+-...

   o  Type: RBridge Channel Protocols, set to TBD [16 suggested]
      (RBCHANNELS).

   o  Length: variable.

   o  Bit Vectors: Zero or more byte-aligned bit vectors where a one bit
      indicates support of a particular RBridge Channel protocol. Each
      byte-aligned bit vector is formatted as follows:

          | 0  1  2  3  4  5  6  7| 8  9 10 11 12 13 14 15|
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |  Bit Vector Length |     Bit Vector Offset    |
          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          |  bits
          +--+--+--...

   The bit vector length (BVL) is a seven bit unsigned integer field
   giving the number of bytes of bit vector. The bit vector offset (BVO)
   is a nine bit unsigned integer field.

   The bits in each bit vector are numbered in network order, the high
   order bit of the first byte of bits being bit 0 + 8*BVO, the low
   order bit of that byte being 7 + 8*BVO, the high order bit of the
   second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge


D. Eastlake, et al.                                            [Page 26]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   Channel protocols-supported bit vector MUST NOT extend beyond the end
   of the value in the sub-TLV in which it occurs. If it does, it is
   ignored. If multiple byte-aligned bit vectors are present in one such
   sub-TLV, their representations are contiguous, the BVL field for the
   next starting immediately after the last byte of bits for the
   previous bit vector. The one or more bit vectors present MUST exactly
   fill the sub-TLV value. If there are one or two bytes of value left
   over, they are ignored; if more than two, an attempt is made to parse
   them as one or more bit vectors.

   If different bit vectors overlap in the protocol number space they
   refer to and they have inconsistent bit values for a channel
   protocol, support for the protocol is assumed if any of these bit
   vectors has a 1 for that protocol.

   The absence of any occurrences of this sub-TLV in the LSP for an IS
   implies that that IS does not support the RBridge Channel facility.

   To avoid wasted space, trailing bit vector zero bytes SHOULD be
   eliminated by reducing BVL, any null bit vectors (ones with BVL equal
   to zero) eliminated, and generally the most compact encoding used.
   For example, support for channel protocols 1 and 32 could be encoded
   as

            BVL = 5
            BVO = 0
             0b01000000
             0b00000000
             0b00000000
             0b00000000
             0b10000000

   or as

            BVL = 1
            BVO = 0
             0b01000000
            BLV = 1
            BVO = 4
             0b1000000

   The first takes 7 bytes while the second takes only 6 and thus the
   second would be preferred.



2.3.10 Affinity Sub-TLV

   Association of an IS to a multi-destination distribution tree through
   a specific path is accomplished by using the tree Affinity sub-TLV.


D. Eastlake, et al.                                            [Page 27]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   The announcement of an Affinity sub-TLV by RB1 with the nickname of
   RB2 as the first part of an Affinity Record in the sub-TLV value is a
   request by RB1 that all ISes in the campus connect RB2 as a child of
   RB1 when calculating any of the trees listed in that Affinity Record.

   AFFINITY is a sub-TLV of Router capability TLV (#242) [RFC4971] with
   the structure shown below.

      +-+-+-+-+-+-+-+-+
      | Type=AFFINITY |                (1 byte)
      +-+-+-+-+-+-+-+-+
      | Length        |                (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   AFFINITY RECORD 1                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   AFFINITY RECORD 2                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   ..........
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   AFFINITY RECORD N                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Where each AFFINITY RECORD is structured as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Nickname                    |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Affinity Flags |                (1 byte
      +-+-+-+-+-+-+-+-+
      |Number of trees|                (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tree-num of 1st root        |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tree-num of 2nd root        |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          ..........         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Tree-num of Nth root        |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: Router Capability sub-TLV type, set to TBD (AFFINITY).

   o  Length: 1 + size of all Affinity Records included, where an
      Affinity Record listing n tree roots is 3+2*n bytes long.

   o  Nickname: 16-bit nickname of the IS whose associations to the
      multi-destination trees listed in the Affinity Record are through
      the originating IS.

   o  Affinity Flags: 8 bits reserved for future needs to provide


D. Eastlake, et al.                                            [Page 28]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      additional information about the affinity being announced. MUST be
      sent as zero and ignored on receipt.

   o  Number of trees: A one byte unsigned integer giving the number of
      trees for which affinity is being announced by this Affinity
      Record.

   o  Tree-num of roots: The tree numbers of the distribution trees this
      Affinity Record is announcing.

   There is no need for a field giving the number of Affinity Records as
   this can be determined by processing those records.



2.3.11 Label Group Sub-TLV

   The Label Group Router Capability sub-TLV consists of two or more
   Label IDs. This sub-TLV indicates that shared Label MAC address
   learning is occurring at the announcing IS between the listed Labels.
   It is structured as follows:

      +-+-+-+-+-+-+-+-+
      |Typ=LABEL-GROUP|                                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Primary Label ID                             |  (3 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Secondary Label ID                           |  (3 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  more Secondary Label IDs ...                   (3 bytes each)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: Router Capability sub-TLV type, set to TBD (LABEL-GROUP).

   o  Length: 6 + 3*n, where n is the number of secondary VLAN ID fields
      beyond the first. n MAY be zero.

   o  Primary Label ID: This identifies the primary Label ID.

   o  Secondary Label ID: This identifies a secondary Label in the Label
      Group.

   o  more Secondary Label IDs: zero or more byte triples, each with a
      Label ID.






D. Eastlake, et al.                                            [Page 29]


INTERNET-DRAFT                                        TRILL Use of IS-IS


2.3.12 Nickname Flags Sub-TLV

   The Nickname Flags (NICK-FLAG) sub-TLV optionally enables flags to be
   associated with nicknames.

      +-+-+-+-+-+-+-+-+
      |Type= NICK-FLAG|                         (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                         (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Nickname Flags Record (1)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Nickname Flags Record (2)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                .................              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Nickname Flags Record (N)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each nickname flag record is of the form:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Nickname            |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|   RESV      |                  (1 byte)
      +-+-+-+-+-+-+-+-+

   o  Type: Router Capability sub-TLV type, set to TBD (NICK-FLAG).

   o  Length: 3*n, where n is the number of nickname flag records
      present.

   o  Nickname: The nickname to which the flags in the following byte
      apply.

   o  T: A flag bit that, if a one, indicates that the Nickname is to be
      used for traffic engineered routing to the originating IS if that
      IS owns the Nickname. The flag has no effect if the IS does not
      own the Nickname.

   o  RESV: Seven reserved bits that MUST be sent as zero and ignored on
      receipt. This are intended to be available for flags defined in
      the future.

   If more than one Nickname Flag Record in the same or different NICK-
   FLAG sub-TLVs appear with the same Nickname owned by the originating
   IS, a flag is considered to be on if it is on in any of the Nickname
   Flag Records.




D. Eastlake, et al.                                            [Page 30]


INTERNET-DRAFT                                        TRILL Use of IS-IS


2.4 MTU Sub-TLV of the Extended Reachability TLV

   The MTU sub-TLV is used to optionally announce the MTU of a link as
   specified in [RFC6325], Section 4.2.4.4. It occurs within the
   Extended Reachability TLV (type 22).

      +-+-+-+-+-+-+-+-+
      | Type = MTU    |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |F|  RESV       |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               MTU             |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: Extended Reachability sub-TLV type, set to MTU sub-TLV 28.

   o  Length: 3.

   o  F: Failed. This bit is a one if MTU testing failed on this link at
      the required campus-wide MTU.

   o  RESV: 7 bits that MUST be sent as zero and ignored on receipt.

   o  MTU: This field is set to the largest successfully tested MTU size
      for this link, or zero if it has not been tested, as specified in
      Section 4.3.2 of [RFC6325].




2.5 TRILL Neighbor TLV

   The TRILL Neighbor TLV is used in TRILL IIH PDUs (see Section 4.1
   below) in place of the IS Neighbor TLV, as specified in Section
   4.4.2.1 of [RFC6325] and in [RFC6327]. The structure of the TRILL
   Neighbor TLV is as follows:














D. Eastlake, et al.                                            [Page 31]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      +-+-+-+-+-+-+-+-+
      |     Type      |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |   Length      |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      |S|L|R|  SIZE   |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Neighbor RECORDS (1)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Neighbor RECORDS (2)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   .................                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Neighbor RECORDS (N)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The information present for each neighbor is as follows:

      +-+-+-+-+-+-+-+-+
      |F|O|  RESV     |                (1 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      MTU                    |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
      |      SNPA (MAC Address)                           | (SIZE bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+

   o  Type: TLV Type, set to TRILL Neighbor TLV 145.

   o  Length: 1 + (SIZE+3)*n, where n is the number of neighbor records,
      which may be zero.

   o  S: Smallest flag. If this bit is a one, then the list of neighbors
      includes the neighbor with the smallest MAC address considered as
      an unsigned integer.

   o  L: Largest flag. If this bit is a one, then the list of neighbors
      includes the neighbor with the largest MAC address considered as
      an unsigned integer.

   o  R, RESV: These bits are reserved and MUST be sent as zero and
      ignored on receipt.

   o  SIZE: The SNPA size as an unsigned integer in bytes except that 6
      is encoded as zero. An actual size of zero is meaningless and
      cannot be encoded. The meaning of the value 6 in this field is
      reserved and TRILL Neighbor TLVs received with a SIZE of 6 are
      ignored. The SIZE is inherent to the technology of a link and is
      fixed for all TRILL Neighbor TLVs on that link but may vary
      between different links in the campus if those links are different
      technologies. For example, 6 for EUI-48 SNPAs or 8 for EUI-64


D. Eastlake, et al.                                            [Page 32]


INTERNET-DRAFT                                        TRILL Use of IS-IS


      SNPAs [RFC5342]. (The SNPA size on the various links in a TRILL
      campus is independent of the System ID size.)

   o  F: failed. This bit is a one if MTU testing to this neighbor
      failed at the required campus-wide MTU (see [RFC6325], Section
      4.3.1).

   o  O: OOMF. This bit is a one if the IS sending the enclosing TRILL
      Neighbor TLV is willing to offer the Overload Originated Multi-
      destination Frame (OOMF) service [ClearCorrect] to the IS whose
      port has the SNPA in the enclosing Neighbor RECORD.

   o  MTU: This field is set to the largest successfully tested MTU size
      for this neighbor or to zero if it has not been tested.

   o  SNPA: Sub-Network Point of Attachment (MAC address) of the
      neighbor.

   As specified in [RFC6327] and Section 4.4.2.1 of [RFC6325], all MAC
   addresses may fit into one TLV, in which case both the S and L flags
   would be set to one in that TLV. If the MAC addresses don't fit into
   one TLV, the highest MAC address in a TRILL Neighbor TLV with the L
   flag zero MUST also appear as a MAC address in some other TRILL
   Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the
   lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST
   also appear in some other TRILL Neighbor TLV (possibly in a different
   TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send a
   TRILL Neighbor TLV with an empty list of neighbor RECORDS, which will
   have both the S and L bits on.























D. Eastlake, et al.                                            [Page 33]


INTERNET-DRAFT                                        TRILL Use of IS-IS


3. MTU PDUs

   The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine
   the MTU on a link between ISs as specified in Section 4.3.2 of
   [RFC6325] and in [RFC6327].

   The MTU PDUs have the IS-IS PDU common header (up through the Maximum
   Area Addresses byte) with PDU Type numbers as indicated in Section 5.
   They also have a common fixed MTU PDU header as shown below that is 8
   + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes
   System IDs.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    PDU Length                 |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
      |    Probe ID                      (6 bytes)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
      |    Probe Source ID               (ID Length bytes)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
      |    Ack Source ID                 (ID Length bytes)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+

   As with other IS-IS PDUs, the PDU length gives the length of the
   entire IS-IS packet starting with and including the IS-IS common
   header.

   The Probe ID field is an opaque 48-bit quantity set by the IS issuing
   an MTU-probe and copied by the responding IS into the corresponding
   MTU-ack. For example, an IS creating an MTU-probe could compose this
   quantity from a port identifier and probe sequence number relative to
   that port.

   The Probe Source ID is set by an IS issuing an MTU-probe to its
   System ID and copied by the responding IS into the corresponding MTU-
   ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored
   on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to
   its System ID. The System ID length is usually 6 bytes but could be a
   different value as indicated by the ID Length field in the IS-IS PDU
   Header.

   The TLV area follows the MTU PDU header area. This area MAY contain
   an Authentication TLV and MUST be padded to the exact size being
   tested with the Padding TLV. Since the minimum size of the Padding
   TLV is 2 bytes, it would be impossible to pad to exact size if the
   total length of the required information bearing fixed fields and
   TLVs added up to 1 byte less than the desired length. However, the
   length of the fixed fields and substantive TLVs for MTU PDUs is
   expected to be quite small compared with their minimum length
   (minimum 1470-byte MTU on an 802.3 link, for example), so this should
   not be a problem.


D. Eastlake, et al.                                            [Page 34]


INTERNET-DRAFT                                        TRILL Use of IS-IS


4. Use of Existing PDUs and TLVs

   The sub-sections below provide details of TRILL use of existing PDUs
   and TLVs.



4.1 TRILL IIH PDUs

   The TRILL IIH PDU is the variation of the LAN IIH PDU used by the
   TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] and
   [RFC6327] specify the contents of the TRILL IIH and how its use in
   TRILL differs from Layer 3 LAN IIH PDU use. The adjacency state
   machinery for TRILL neighbors is specified in detail in [RFC6327].

   In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header
   are the same as a Level 1 LAN IIH PDU. The Maximum Area Addresses
   octet in the common header MUST be set to 0x01.

   The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored
   if it appears there. Instead, TRILL IIH PDUs use the TRILL Neighbor
   TLV (see Section 2.5).



4.2 Area Address

   TRILL uses a fixed zero Area Address as specified in [RFC6325],
   Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1)
   as follows:

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



4.3 Protocols Supported

   NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL
   [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that
   value MUST appear in TRILL IIH PDUs and LSP number zero PDUs.




D. Eastlake, et al.                                            [Page 35]


INTERNET-DRAFT                                        TRILL Use of IS-IS


4.4 Link State PDUs (LSPs)

   A number zero LSP MUST NOT be originated larger than 1470 bytes but a
   larger number zero LSP successfully received MUST be processed and
   forwarded normally.



4.5 Originating LSP Buffer Size

   The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero;
   however, if found in other LSP fragments, it is processed normally.
   Should there be more than one originatingLSPBufferSize TLV for an IS,
   the minimum size, but not less than 1470, is used.






































D. Eastlake, et al.                                            [Page 36]


INTERNET-DRAFT                                        TRILL Use of IS-IS


5. IANA Considerations

   This section give IANA Considerations for the TLVs, sub-TLVs, and
   PDUs specified herein.



5.1 TLVs

   This document specifies two IS-IS TLV types -- namely, the Group
   Address TLV (GADDR-TLV, type 142) and the TRILL Neighbor TLV (type
   145). The PDUs in which these TLVs are permitted for TRILL are shown
   in the table below along with the section of this document where they
   are discussed. The final "NUMBER" column indicates the permitted
   number of occurrences of the TLV in their PDU, or set of PDUs in the
   case of LSP, which in these two cases is "*" indicating that the TLV
   MAY occur 0, 1, or more times.

   IANA has registered these two code points in the IANA IS-IS TLV
   registry (ignoring the "Section" and "NUMBER" columns, which are
   irrelevant to that registry).

                         Section TLV IIH LSP SNP Purge NUMBER
                         ======= === === === === ===== ======
      GADDR-TLV            2.1   142   -  X   -    -     *
      TRILL Neighbor TLV   2.5   145   X  -   -    -     *



5.2 sub-TLVs

   This document specifies a number of sub-TLVs including 12 new sub-
   TLVs. The TLVs in which these sub-TLVs occur are shown in the second
   table below along with the section of this document where they are
   discussed.  The TLVs within which these sub-TLVs can occur are
   determined by the presence of an "X" in the relevant column as shown
   in the first table below.

      Column Head    TLV    RFCref    TLV Name
      ===========   =====  ========  ==============
       Grp. Adr.     142    This doc  Group Address
       MT Port       143    6165      MT-PORT-CAP
       Rtr. Cap      242    4971      Router CAPABILITY
       Ext. Reach     22    5305      Extended IS Reachability

   The final "NUMBER" column below indicates the permitted number of
   occurrences of the sub-TLV cumulatively within all occurrences of
   their TLV in that TLV's carrying PDU (or set of PDUs in the case of
   LSP), as follows:



D. Eastlake, et al.                                            [Page 37]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   0-1 = MAY occur zero or one times.
    1  = MUST occur exactly once. If absent, the PDU is ignored. If it
         occurs more than once, results are unspecified.
    *  = MAY occur 0, 1, or more times.

   The values in the "Section" and "NUMBER" columns are irrelevant to
   the IANA sub-registries.


                               sub-   Grp.  MT    Rtr.  Ext.
     Name            Section   TLV#   Adr.  Port  Cap.  Reach  NUMBER
     ================================================================
     GMAC-ADDR        2.1.1      1     X     -     -     -      *
     GIP-ADDR         2.1.2    TBD[2]  X     -     -     -      *
     GIPV6-ADDR       2.1.3    TBD[3]  X     -     -     -      *
     GLMAC-ADDR       2.1.4    TBD[4]  X     -     -     -      *
     GLIP-ADDR        2.1.5    TBD[5]  X     -     -     -      *
     GLIPV6-ADDR      2.1.6    TBD[6]  X     -     -     -      *
     VLAN-FLAGS       2.2.1      1     -     X     -     -      1
     Enabled-VLANs    2.2.2      2     -     X     -     -      *
     AppointedFwrdrs  2.2.3      3     -     X     -     -      *
     PORT-TRILL-VER   2.2.4     TBD    -     X     -     -     0-1
     VLANs-Appointed  2.2.5     TBD    -     X     -     -      *
     NICKNAME         2.3.2      6     -     -     X     -      *
     TREES            2.3.3      7     -     -     X     -     0-1
     TREE-RT-IDs      2.3.4      8     -     -     X     -      *
     TREE-USE-IDs     2.3.5      9     -     -     X     -      *
     INT-VLAN         2.3.6     10     -     -     X     -      *
     TRILL-VER        2.3.1     13     -     -     X     -     0-1
     VLAN-GROUP       2.3.7     14     -     -     X     -      *
     INT-LABEL        2.3.8   TBD[15]  -     -     X     -      *
     RBCHANNELS       2.3.9   TBD[16]  -     -     X     -      *
     AFFINITY         2.3.10  TBD[17]  -     -     X     -      *
     LABEL-GROUP      2.3.11  TBD[18]  -     -     X     -      *
     NICK-FLAG        2.3.12  TBD[19]  -     -     X     -      *
     MTU              2.4       28     -     -     -     X     0-1
     ================================================================
     Name            Section   sub-   Grp.  MT    Rtr.  Ext.   NUMBER
                               TLV#   Adr.  Port  Cap.  Reach



5.3 PDUs

   The IS-IS PDUs registry remains as established in [RFC6326] except
   that the references to [RFC6326] are updated to reference this
   document.





D. Eastlake, et al.                                            [Page 38]


INTERNET-DRAFT                                        TRILL Use of IS-IS


5.4 Reserved and Capability Bits

   Any reserved bits (R) or bits in reserved fields (RESV) or the
   capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which
   are specified herein as "MUST be sent as zero and ignored on receipt"
   or the like, are allocated based on Standards Action [RFC5226] as
   modified by [RFC4020].

   Two sub-registries are created within the TRILL Parameters Registry
   as follows:

      Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags
      Registration Procedures: Standards Action modified by [RFC4020]
      Reference: (This document)

         Bit   Description                       Reference
        ===== =============                     ===========
          0    Affinity sub-TLV support.         [Affinity]
         1-13  Available
        14-31  Extended header flag support.     [ExtendHeader]


      Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags
      Registration Procedures: Standards Action modified by [RFC4020]
      Reference: (This document)

         Bit   Description                       Reference
        ===== =============                     ===========
          0    Hello reduction support.          [ClearCorrect]
         1-2   Available
         3-13  Hop-by-hop extended flag support. [ExtendHeader]
        14-31  Available



5.5 TRILL Neighbor Record Flags

   A sub-registry is created within the TRILL Parameters Registry as
   follows:

      Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags
      Registration Procedures: Standards Action
      Reference: (This document)

        Bit Short Name   Description            Reference
        ==============  =============          ===========
         0   Fail       Failed MTU test.        [RFC6325]
         1   OOMF       Offering OOMF service.  [ClearCorrect]
        2-7  -          Available.



D. Eastlake, et al.                                            [Page 39]


INTERNET-DRAFT                                        TRILL Use of IS-IS


6. Security Considerations

   For general TRILL protocol security considerations, see the TRILL
   base protocol standard [RFC6325].

   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] and [RFC5310]. Even when IS-IS authentication is used,
   replays of Hello packets can create denial-of-service conditions; see
   [RFC6039] for details. These issues are similar in scope to those
   discussed in Section 6.2 of [RFC6325], and the same mitigations may
   apply.








































D. Eastlake, et al.                                            [Page 40]


INTERNET-DRAFT                                        TRILL Use of IS-IS


7. Change from RFC 6326

   Non-editorial changes from [RFC6326] are summarized in the list
   below:

    1. Additional of five sub-TLVs under the Group Address (GADDR) TLV
       covering VLAN labeled IPv4 and IPv6 addresses and fine-grained
       labeled MAC, IPv4, and IPv6 addresses. (Sections 2.1.2, 2.1.3,
       2.1.4, 2.1.5, and 2.1.6).

    2. Addition of the PORT-TRILL-VER sub-TLV. (Section 2.2.4)

    3. Addition of the VLANs-Appointed sub-TLV. (Section 2.2.5)

    4. Change the TRILL-VER sub-TLV as listed below.

       4.a Addition of 4 bytes of TRILL Header extended flags and
           capabilities supported information.

       4.b Require that the TRILL-VER sub-TLV appear in LSP number zero.

       The above changes to TRILL-VER are backwards compatible because
       the [RFC6326] conformant implementations of TRILL thus far have
       only supported version zero and not supported any optional
       capabilities or extended flags, the level of support indicated by
       the absence of the TRILL-VER sub-TLV. Thus, if an [RFC6326]
       conformant implementation of TRILL rejects this sub-TLV due to
       the changes specified in this document, it will, at worst, decide
       that support of version zero and no extended flags or
       capabilities is indicated, which is the best an [RFC6326]
       conformant implementation of TRILL can do anyway. Similarly, a
       TRILL implementation that supports TRILL-VER as specified herein
       and rejects TRILL-VER sub-TLVs in an [RFC6326] conformant TRILL
       implementation because they are not in LSP number zero will
       decide that that implementation supports only version zero with
       no extended flag or capabilities support, which will be correct.
       (Section 2.3.1)

    5. Clarification of the use of invalid VLAN IDs in the Appointed
       Forwarders sub-TLV and the Interested VLANs and Spanning Tree
       Roots sub-TLV. (Sections 2.2.3 and 2.3.6)

    6. Addition of the Interested Labels and Spanning Tree Roots sub-TLV
       to indicate attachment of an IS to a 24-bit fine grained label
       analogous to the existing Interested VLANs and Spanning Tree
       Roots sub-TLV for 12-bit VLANs. (Section 2.3.8)

    7. Addition of the RBridge Channel Protocols sub-TLV so ISs can
       announce the RBridge Channel protocols they support. (Section
       2.3.9)


D. Eastlake, et al.                                            [Page 41]


INTERNET-DRAFT                                        TRILL Use of IS-IS


    8. Permit specification of the length of the link SNPA field in
       TRILL Neighbor TLVs. This change is backwards compatible because
       the size of 6 bytes is specially encoded as zero, the previous
       value of the bits in the new SIZE field. (Section 2.5)

    9. Make the size of the MTU PDU Header Probe Source ID and Ack
       Source ID fields be the ID Length from the IS-IS PDU Header
       rather than the fixed value 6. (Section 3)

   10. For robustness, require LSP number zero PDUs be originated as no
       larger than 1470 bytes but processed regardless of size. (Section
       4.4)

   11. Require that the originatingLSPBufferSize TLV, if present, appear
       in LSP number zero. (Section 4.5)

   12. Create sub-registries for and specify the IANA Considerations
       policy for reserved and capability bits in the TRILL version sub-
       TLVs. (Section 5.4)

   13. Addition of the distribution tree Affinity sub-TLV so ISs can
       request distribution tree attachments. (Section 2.3.10)

   14. Add LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV.
       (Section 2.3.11)

   15. Addition of a sub-registry for Neighbor TLV Neighbor RECORD flag
       bits. (Section 5.5)

   16. Explicitly state that if the number of sources in a GADDR-TLV
       sub-TLV is zero, it indicates a listener for (*,G), that is, a
       listener not restricted by source. (Section 2.1)

   17. Add the NICK-FLAG sub-TLV so that flags can be associated with
       nicknames such as a flag indicating an egress nickname for
       traffic engineered routing. (Section 2.3.12)
















D. Eastlake, et al.                                            [Page 42]


INTERNET-DRAFT                                        TRILL Use of IS-IS


8. Normative References

   [ISO-10589] - ISO/IEC 10589:2002, Second Edition, "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)", 2002.

   [RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
         Dual Environments", 1990.

   [RFC1982] - Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
         1982, August 1996.

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

   [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
         Standards Track Code Points", BCP 100, RFC 4020, February 2005.

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

   [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
         Topology (MT) Routing in Intermediate System to Intermediate
         Systems (IS-ISs)", RFC 5120, February 2008.

   [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
         IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
         2008.

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

   [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, "RBridges: Base Protocol Specification", RFC 6325,
         June 2011.

   [RFC6327] - Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V.
         Manral, "RBridges: Adjacency", RFC 6327, July 2011.

   [RFC6328] - Eastlake, D., "IANA Considerations for Network Layer
         Protocol Identifiers", RFC 6328, June 2011.

   [RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
         Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
         6439, November 2011.


D. Eastlake, et al.                                            [Page 43]


INTERNET-DRAFT                                        TRILL Use of IS-IS


   [Affinity] - draft-tissa-trill-cmt, work in progress.

   [Channel] - draft-ietf-trill-rbridge-channel, work in progress.

   [ClearCorrect] - draft-eastlake-trill-rbridge-clear-correct, work in
         progress.

   [ExtendHeader] - draft-ietf-trill-rbridge-extension, work in
         progress.




9. Informative References

   [802.1D-2004] - "IEEE Standard for Local and metropolitan area
         networks / Media Access Control (MAC) Bridges", 802.1D-2004, 9
         June 2004.

   [802.1Q-2011] - "IEEE Standard for Local and metropolitan area
         networks / Virtual Bridged Local Area Networks", 802.1Q-2011,
         31 August 2011.

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

   [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
         and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
         5310, February 2009.

   [RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol
         Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September
         2008.

   [RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White,
         "Issues with Existing Cryptographic Protection Methods for
         Routing Protocols", RFC 6039, October 2010.

   [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
         Ghanwani, "Transparent Interconnection of Lots of Links (TRILL)
         Use of IS-IS", RFC 6326, July 2011.

   [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in
         progress.








D. Eastlake, et al.                                            [Page 44]


INTERNET-DRAFT                                        TRILL Use of IS-IS


Acknowledgements

   The authors gratefully acknowledge the contributions and review by
   the following:

      Adrian Farrel, Tissa Senevirathne, Joe Touch.

   And by the following to [RFC6326]:

      Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam
      Hartman, Dan Romascanu, Dave Ward, and Russ White.  In particular,
      thanks to Mike Shand for the detailed and helpful comments.

   This document was produced with raw nroff. All macros used were
   defined in the source files.





































D. Eastlake, et al.                                            [Page 45]


INTERNET-DRAFT                                        TRILL Use of IS-IS


Authors' Addresses

   Donald Eastlake
   Huawei R&D USA
   155 Beaver Street
   Milford, MA 01757 USA

   Phone: +1-508-333-2270
   EMail: d3e3e3@gmail.com


   Ayan Banerjee
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA 95134 USA

   Phone: +1-408-527-0539
   EMail: ayabaner@cisco.com


   Dinesh Dutt

   EMail: ddutt.ietf@hobbesdutt.com


   Anoop Ghanwani
   Dell
   350 Holger Way
   San Jose, CA 95134 USA

   Phone: +1-408-571-3500
   EMail: anoop@alumni.duke.edu


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

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











D. Eastlake, et al.                                            [Page 46]


INTERNET-DRAFT                                        TRILL Use of IS-IS


Copyright, Disclaimer, and Additional IPR Provisions

   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
   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.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.





















D. Eastlake, et al.                                            [Page 47]