[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-eastlake-trill-ia-appsubtlv) 00 01 02

INTERNET-DRAFT                                           Donald Eastlake
Intended status: Proposed Standard                             Yizhou Li
                                                                  Huawei
                                                           Radia Perlman
                                                                     EMC
Expires: May 23, 2014                                  November 24, 2014


                 TRILL: Interface Addresses APPsub-TLV
                 <draft-ietf-trill-ia-appsubtlv-02.txt>



Abstract
   This document specifies a TRILL (Transparent Interconnection of Lots
   of Links) IS-IS application sub-TLV that enables the reporting by a
   TRILL switch of sets of addresses such that all of the addresses in
   each set designate the same interface (port) and the reporting for
   such a set of the TRILL switch by which it is reachable. For example,
   a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6
   address can be reported as all corresponding to the same interface
   reachable by a particular TRILL switch. Such information could be
   used in some cases to synthesize responses to or by-pass the need for
   the Address Resolution Protocol (ARP), the IPv6 Neighbor Discovery
   (ND) protocol, or the flooding of unknown MAC addresses.



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: IA APPsub-TLV


Table of Contents

      1. Introduction............................................3
      1.1 Conventions Used in This Document......................3

      2. Format of the Interface Addresses APPsub-TLV............5

      3. IA APPsub-TLV sub-sub-TLVs.............................10
      3.1 AFN Size sub-sub-TLV..................................10
      3.2 Fixed Address sub-sub-TLV.............................11
      3.3 Data Label sub-sub-TLV................................12
      3.4 Topology sub-sub-TLV..................................12

      4. Security Considerations................................14

      5. IANA Considerations....................................15
      5.1 AFN Number Allocation.................................15
      5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry................16
      5.3 IA APPsub-TLV Number..................................16

      Acknowledgments...........................................17

      Appendix A: Examples......................................18
      A.1 Simple Example........................................18
      A.2 Complex Example.......................................18

      Appendix Z: Change History................................21

      Normative References......................................22
      Informational References..................................23
      Authors' Addresses........................................24





















D. Eastlake, et al                                              [Page 2]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


1. Introduction

   This document specifies a TRILL (Transparent Interconnection of Lots
   of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV [RFC6823])
   that enables the convenient representation of sets of addresses such
   that all of the addresses in each set designate the same interface
   (port). For example, a 48-bit MAC (Media Access Control [RFC7042])
   address, IPv4 address, and IPv6 address can be reported as all three
   designating the same interface.  In addition, a Data Label (VLAN or
   Fine Grained Label (FGL [RFC7172])) is specified for the interface
   along with the TRILL switch, and optionally the TRILL switch port,
   from which the interface is reachable.  Such information could be
   used in some cases to synthesize responses to or by-pass the need for
   the Address Resolution Protocol (ARP [RFC826]), the IPv6 Neighbor
   Discovery (ND [RFC4861]) protocol, the Reverse Address Resolution
   Protocol (RARP [RFC903]), or the flooding of unknown destination MAC
   addresses [RFC7042].  If the information report is complete, it can
   also be used to detect and discard packets with forged source
   addresses.

   This APPsub-TLV appears inside the TRILL GENINFO TLV specified in
   ESADI [RFC7357] but may also occur in other application contexts.
   Directory Assisted TRILL Edge services [DirectoryScheme] are expected
   to make use of this APPsub-TLV.

   Although, in some IETF protocols, address field types are represented
   by Ethertype [RFC7042] or Hardware Type [RFC5494], only Address
   Family Number (AFN) is used in this APPsub-TLV to represent address
   field type.



1.1 Conventions Used in This Document

   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]. Capitalized
   IANA Considertions terms such as "Expert Review" are to be
   interpreted as described in [RFC5226].

   The terminology and acronyms of [RFC6325] are used herein along with
   the following additional acronyms and terms:

   AFN:   Address Family Number

   APPsub-TLV: Application sub-TLV [RFC6823]

   Data Label: VLAN or FGL

   FGL:   Fine Grained Label [RFC7172]


D. Eastlake, et al                                              [Page 3]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


   IA:    Interface Addresses

   RBridge: An alternative name for a TRILL switch

   TRILL switch: A device that implements the TRILL protocol















































D. Eastlake, et al                                              [Page 4]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


2. Format of the Interface Addresses APPsub-TLV

   The Interface Addresses (IA) APPsub-TLV is used to advertise that a
   set of addresses indicate the same interface (port) within a Data
   Label (VLAN or FGL) and to associate that interface with the TRILL
   switch, and optionally the TRILL switch port, by which the interface
   is reachable.  These addresses can be in different address families.
   For example, it can be used to declare that a particular interface
   with specified IPv4, IPv6, and 48-bit MAC addresses in some
   particular Data Label is reachable from a particular TRILL switch.

   The Template field in a particular Interface Addresses APPsub-TLV
   indicates the format of each Address Set it carries. Certain well-
   known sets of addresses are represented by special values. Other sets
   of addresses are specified by a list of AFNs. The Template format
   that uses a list of AFNs provides an explicit pattern for the type
   and order of addresses in each Address Set in the IA APPsub-TLV that
   includes that Template.

   A device or application making use of IA APPsub-TLV data is not
   required to make use of all IA data. For example, a device or
   application that was only interested in MAC and IPv6 addresses could
   ignore any IPv4 or other types of address information that was
   present.

   The figure below shows an IA APPsub-TLV as it would appear inside an
   IS-IS FS-LSP using an extended flooding scope [RFC7356] TLV, for
   example in ESADI [RFC7357].  Within an IS-IS PDU using traditional
   [ISO-10589] TLVs, the Type and Length would be one byte unsigned
   integers equal to or less than 255.






















D. Eastlake, et al                                              [Page 5]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type = TBD1                    |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Length                        |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Addr Sets End                 |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Nickname                      |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Flags         |                  (1 byte)
      +-+-+-+-+-+-+-+-+
      | Confidence    |                  (1 byte)
      +-+-+-+-+-+-+-+-+-+-
      | Template ...                     (variable)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
      | Address Set 1    (size determined by Template)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
      | Address Set 2    (size determined by Template)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
      |   ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
      | Address Set N    (size determined by Template)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
      | optional sub-sub-TLVs ...
      +-+-+-+-+-+-+-+-+-+-+-+-...

                 Figure 1. The Interface Addresses APPsub-TLV

   o  Type: Interface Addresses TRILL APPsub-TLV type, set to TBD1 (IA-
      SUBTLV).

   o  Length: Variable, minimum 7. If length is 6 or less or if the
      APPsub-TLV extends beyond the size of an encompassing TRILL
      GENINFO TLV or other context, the APPsub-TLV MUST be ignored.

   o  Addr Sets End: The unsigned integer offset of the byte, within the
      IA APPsub-TLV value part, of the last byte of the last Address
      Set. This will be the byte just before the first sub-sub-TLV if
      any sub-sub-TLVs are present (see Section 3). If this is equal to
      Length, there are no sub-sub-TLVs. If this is greater than Length
      or points to before the end of the Template, the IA APPsub-TLV is
      corrupt and MUST be discarded. This field is always two bytes in
      size.

   o  Nickname: The nickname of the TRILL switch by which the address
      sets are reachable. If zero, the address sets are reachable from
      the TRILL switch originating the message containing the APPsub-TLV
      (for example, an ESADI [RFC7357] message).

   o  Flags: A byte of flags as follows:


D. Eastlake, et al                                              [Page 6]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


          0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+
         |D|L|N|  RESV   |
         +-+-+-+-+-+-+-+-+

         D: Directory flag: If D is one, the APPsub-TLV contains
            Directory information [RFC7067].

         L: Local flag: If L is one, the APPsub-TLV contains information
            learned locally by observing ingressed frames [RFC6325].
            (Both D and L can be one in the same IA APPsub-TLV if a
            TRILL switch that had learned an address locally and also
            advertised it as a directory.)

         N: Notify flag: When a TRILL switch receives a new IA APPsub-
            TLV (one in a ESADI-LSP fragment with a higher sequence
            number or a new message of some other type) and the N bit is
            one, the TRILL switch then checks the contents of the
            APPsub-TLV for address sets including both an IP address and
            a MAC address.  For each such address set it finds, a
            gratuitous ARP [RFC826] or spontaneous Neighbor
            Advertisement [RFC4861], depending on whether the IP address
            is IPv4 or IPv6 respectively, may be sent. In both cases,
            these are sent out all the ports of the TRILL switch
            offering end station service and are in the VLAN or FGL of
            the address set information, that is, are Appointed
            Forwarder for the VLAN or for the VLAN to which the FGL
            maps.

         RESV: Additional reserved flag bits that MUST be sent as zero
            and ignored on receipt.

   o  Confidence: This 8-bit unsigned quantity in the range 0 to 254
      indicates the confidence level in the addresses being transported
      [RFC6325]. A value of 255 is treated as if it was 254.

   o  Template: The initial byte of this field is the unsigned integer
      K. If K has a value from 1 to 31, it indicates that this initial
      byte is followed by a list of K AFNs (Address Family Numbers) that
      specify the exact structure and order of each Address Set
      occurring later in the APPsub-TLV. K can be 1, which is the
      minimum valid value. If K is zero, the IA APPsub-TLV is ignored.
      If K is 32 to 254, the length of the Template field is one byte
      and its value is intended to correspond to a particular ordered
      set of AFNs some of which are specified below. If K is 255, the
      length of the Template filed is three bytes and the values of the
      second and third byte, considered as an unsigned integer in
      network byte order, are reserved to correspond to future specified
      ordered sets of AFNs.



D. Eastlake, et al                                              [Page 7]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


      If the Template uses explicit AFNs, it looks like the following,
      with the number of AFNs up to 31 equal to K.

         +-+-+-+-+-+-+-+-+
         |  K            |                  (1 byte)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  AFN 1                        |  (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  AFN 2                        |  (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |   ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |  AFN K                        |  (2 bytes)
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      For K in the 32 to 102 range, values indicate combinations of a
      specific number of MAC addresses, IPv4 addresses, IPv6 addresses,
      and TRILL switch port IDs appearing in that order. The value of K
      is

         K = 31 + M + 3*v4 + 9*v6 + 36*P

      where M is 0, 1, or 2 (0 if no MAC address is present, 1 if a
      48-bit MAC is present, 2 if a MAC/24 (see Section 5.1) is
      present), v4 is the number of IPv4 addresses (limited to 0, 1, or
      2) and v6 is the number of IPv6 addresses (limited to 0 through 3
      inclusive), and P is the number of TRILL switch port IDs (limited
      to 0 or 1); however, the number of MAC, IPv4, and IPv6 addresses
      and TRILL switch ports cannot all be simultaneously zero.  That
      equation specifies values of K from 32 through 102, the value 31
      not being permitted but instead representing an explicit Template
      with 31 AFNs. Values from 103 through 254 of the byte value are
      available for assignment by Expert Review (see Section 5). K = 255
      indicates a three-byte Template field as specified above. All
      values (0 through 65,545) of this two-byte value are available for
      assignment by Expert Review.

      If an unknown Template K value in the range 103 to 254 is received
      or a K of 255 followed by an unknown two byte value, the IA
      APPsub-TLV MUST be ignored.

   o  AFN: A two-byte Address Family Number. The number of AFNs present
      is given by K except that there are no AFNs if K is greater than
      31. The AFN sequence specifies the structure of the Address Sets
      occurring later in the TLV. For example, if Template Size is 2 and
      the two AFNs present are the AFNs for a 48-bit MAC and an IPv4
      address, in that order, then each Address set present will consist
      of a 6-byte MAC address followed by a 4-byte IPv4 address. If any
      AFNs are present that are unknown to the receiving IS and the
      length of the corresponding address is not provided by a sub-sub-


D. Eastlake, et al                                              [Page 8]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


      TLV as specified below, the receiving IS will be unable to parse
      the Address Sets and MUST ignore the IA APPsub-TLV.

   o  Address Set: Each address set in the APPsub-TLV consists of
      exactly the same sequence of addresses of the types specified by
      the Template earlier in the APPsub-TLV. No alignment, other than
      to a byte boundary, is guaranteed. The addresses in each Address
      Set are contiguous with no unused bytes between them and the
      Address Sets are contiguous with no unused bytes between
      successive Address Sets. The Address Sets must fit within the TLV.

   o  sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do
      not completely fill the Length of the APPsub-TLV, the remaining
      bytes are parsed as sub-sub-TLVs [RFC5305]. Any such sub-sub-TLVs
      that are not known to the receiving TRILL switch are ignored.
      Should this parsing not be possible, for example there is only one
      remaining byte or an apparent sub-sub-TLV extends beyond the end
      of the TLV, the containing IA APPsub-TLV is considered corrupt and
      is ignored. (Several sub-sub-TLV types are specified in Section
      3.)

   Different IA APPsub-TLVs within the same or different LSPs or other
   data structures may have different Templates. The same AFN may occur
   more than once in a Template and the same address may occur in
   different address sets. For example, a 48-bit MAC address interface
   might have three different IPv6 addresses. This could be represented
   by an IA APPsub-TLV whose Template specifically provided for one
   EUI-48 address and three IPv6 addresses, which might be an efficient
   format if there were multiple interfaces with that pattern.
   Alternatively, a Template with one 48-bit MAC and one IPv6 address
   could be used in an IA APPsub-TLV with three address sets each having
   the same MAC address but different IPv6 addresses, which might be the
   most efficient format if only one interface had multiple IPv6
   addresses and other interfaces had only one IPv6 address.

   In order to be able to parse the Address Sets, a receiving TRILL
   switch must know at least the size of the address for each AFN or
   address type the Template specifies; however, the presence of the
   Addr Set End field means that the sub-sub-TLVs, if any, can always be
   located by a receiver.  A TRILL switch can be assumed to know the
   size of the AFNs mentioned in Section 5. Should a TRILL switch wish
   to include an AFN that some receiving TRILL switch in the campus may
   not know, it SHOULD include an AFN-Size sub-sub-TLV as described in
   Section 3.1. If an IA APPsub-TLV is received with one or more AFNs in
   its template for which the receiving TRILL switch does not know the
   length and for which an AFN-Size sub-sub-TLV is not present, that IA
   APPsub-TLV MUST be ignored.





D. Eastlake, et al                                              [Page 9]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


3. IA APPsub-TLV sub-sub-TLVs

   IA APPsub-TLVs can have trailing sub-sub-TLVs [RFC5305] as specified
   below.  These sub-sub-TLVs occur after the Address Sets and the
   amount of space available for sub-sub-TLVs is determined from the
   overall IA APPsub-TLV length and the value of the Addr Set End byte.

   There is no ordering restriction on sub-sub-TLVs. Unless otherwise
   specified each sub-sub-TLV type can occur zero, one, or many times in
   an IA APPsub-TLV. Any sub-sub-TLVs for which the Type is unknown are
   ignored.

   The sub-sub-TLVs data structures shown below, with two byte Types and
   Lengths, assume that the enclosing IA-APPsubTLV is in an extended LSP
   TLV [RFC7356] or some non-LSP context. If they were used in a IA-
   APPsubTLV in a traditional LSP [ISO-10589], the only one byte Types
   and Lengths could be used. As a result, any sub-sub-TLV types greater
   than 255 could not be used and Length would be limited to 255.



3.1 AFN Size sub-sub-TLV

   Using this sub-sub-TLV, the originating TRILL switch can specify the
   size of an address type. This is useful under two circumstances as
   follows:

   1. One or more AFNs that are unknown to the receiving TRILL switch
      appears in the template. If an AFN Size sub-sub-TLV is present for
      each such AFN, then at least the IA APPsub-TLV can be parsed and
      possibly other addresses in each address set can still be used.

   2. If an AFN occurs in the Template that represents a variable length
      address, this sub-sub-TLV gives its size for all occurrences in
      that IA APPsub-TLV.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type = AFNsz                  |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Length                        |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | AFN Size Record 1                             |  (3 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | AFN Size Record 2                             |  (3 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | AFN Size Record N                             |  (3 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



D. Eastlake, et al                                             [Page 10]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


   Where each AFN Size Record is structured as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AFN                          |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AdrSize      |                  (1 byte)
      +-+-+-+-+-+-+-+-+

   o  Type: AFN-Size sub-sub-TLV type, set to 1 (AFNsz).

   o  Length: 3*n where n is the number of AFN Size Records present. If
      Length is not a multiple of 3, the sub-sub-TLV MUST be ignored.

   o  AFN Size Record(s): Zero or more 3-byte records, each giving the
      size of an address type identified by an AFN,

   o  AFN: The AFN whose length is being specified by the AFN Size
      Record.

   o  AdrSize: The length in bytes of addresses specified by the AFN
      field as an unsigned integer.

   An AFN Size sub-sub-TLV for any AFN known to the receiving TRILL
   switch is compared with the size known to the TRILL switch. If they
   differ the IA APPsub-TLV is assumed to be corrupt and MUST be
   ignored.



3.2 Fixed Address sub-sub-TLV

   There may be cases where, in a particular Interface Addresses APP-
   subTLV, the same address would appear in every address set across the
   APP-subTLV.  To avoid wasted space, this sub-sub-TLV can be used to
   indicate such a fixed address. The address or addresses incorporated
   into the sets by this sub-sub-TLV are NOT mentioned in the IA APPsub-
   TLV Template.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type=FIXEDADR                 | (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Length                        | (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | AFN                           | (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Fixed Address                   (variable)
      +-+-+-+-+-+-+-+-+-+-+-+-+-...

   o  Type: Data Label sub-sub-TLV type, set to 2 (FIXEDADR).



D. Eastlake, et al                                             [Page 11]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


   o  Length: variable, minimum 2. If Length is 0 or 1 or less, the sub-
      sub-TLV MUST be ignored.

   o  AFN: Address Family Number of the Fixed Address.

   o  Fixed Address: The address of the type indicated by the preceding
      AFN field that is considered to be part of every Address Set in
      the IA APPsub-TLV.

   The Length field implies a size for the Fixed Address. If that size
   differs from the size of the address type for the given AFN as known
   by the receiving TRILL switch, the Fixed Address sub-sub-TLV is
   considered corrupt and MUST be ignored.



3.3 Data Label sub-sub-TLV

   This sub-sub-TLV indicates the Data Label within which the interfaces
   listed in the IA APPsub-TLV are reachable. It is useful if the IA
   APPsub-TLV occurs outside of the context of a message specifying the
   Data Label or if it is desired and permitted to override that
   specification.  Multiple occurrences of this sub-sub-TLV indicate
   that the interfaces are reachable in all of the Data Labels given.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Type=DATALEN                   | (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Length                        | (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Data Label                      (variable)
      +-+-+-+-+-+-+-+-+-+-+-+-+-...

      o  Type: Data Label sub-TLV type, set to 3 (LABEL).

      o  Length: 2 or 3. If Length is some other value, the sub-sub-TLV
         MUST be ignored.

      o  Data Label: If length is 2, the bottom 12 bits of the Data
         Label are a VLAN ID and the top 4 bits are reserved (MUST be
         sent as zero and ignored on receipt). If the length is 3, the
         three Data Label bytes contain an FGL [RFC7172].



3.4 Topology sub-sub-TLV

   The presence of this sub-sub-TLV indicates that the interfaces given
   in the IA APPsub-TLV are reachable in the topology give. It is useful
   if the IA APPsub-TLV occurs outside of the context of a message


D. Eastlake, et al                                             [Page 12]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


   indicating the topology or if it is desired and permitted to override
   that specification. If it occurs multiple times, then the Address
   Sets are in all of the topologies given.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Type=DATALEN                   |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Length                        |  (2 byte)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RESV  |        Topology       |  (2 bytes)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o  Type: Topology sub-TLV type, set to 4 (TOPOLOGY).

      o  Length: 2. If Length is some other values, the sub-sub-TLV MUST
         be ignored.

      RESV: Four reserved bits. MUST be sent as zero and ignored on
         receipt.

      o  Topology: The 12-bit topology number [RFC5120].































D. Eastlake, et al                                             [Page 13]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


4. Security Considerations

   The integrity of address mapping and reachability information and the
   correctness of Data Labels (VLANs or FGLs [RFC7172]) are very
   important.  Forged, altered, or incorrect address mapping or Data
   Labeling can lead to delivery of packets to the incorrect party,
   violating security policy. However, this document merely describes a
   data format and does not provide any explicit mechanisms for securing
   that information, other than a few trivial consistency checks that
   might detect some corrupted data. Security on the wire, or in
   storage, for this data is to be providing by the transport or storage
   used. For example, when transported with ESADI [RFC7357] or RBridge
   Channel [RFC7178], ESADI security or Channel Tunnel [ChannelTunnel]
   security mechanisms can be used, respectively.

   The address mapping and reachability information, if known to be
   complete and correct, can be used to detect some cases of forged
   packet source addresses [RFC7067]. In particular, if native traffic
   from an end station is received by a TRILL switch that would
   otherwise accept it but authoritative data indicates the source
   address should not be reachable from the receiving TRILL switch, that
   traffic should be discarded. The data format specified in this
   document may optionally include TRILL switch Port ID number so that
   this forged address filtering can be optionally applied with port
   granularity.

   See [RFC6325] for general TRILL Security Considerations.

























D. Eastlake, et al                                             [Page 14]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


5. IANA Considerations

   The following subsections specify IANA actions.



5.1 AFN Number Allocation

   IANA has allocated the following AFN values that may be particularly
   useful for IA APPsub-TLVs:

              Hex    Decimal   Description      References
             -----   -------   -----------      ----------

              0001        1    IPv4
              0002        2    IPv6
              4005    16389    48-bit MAC       [RFC7042]
              4006    16390    64-bit MAC       [RFC7042]
              4007    16391    OUI              This document.
              4008    16392    MAC/24           This document.
              4009    16393    MAC/40           This document.
              400A    16394    IPv6/64          This document.
              400B    16395    RBridge Port ID  This document.

   Other AFNs can be found at http://www.iana.org/assignments/address-
   family-numbers

   The OUI AFN is provided so that MAC addresses can be abbreviated if
   they have the same upper 24 bits.  A MAC/24 is a 24-bit suffix
   intended to be pre-fixed by an OUI to create a 48-bit MAC address
   [RFC7042]; in the absence of an OUI, a MAC/24 entry cannot be used.
   A MAC/40 is a suffix intended to be pre-fixed by an OUI to create a
   64-bit MAC address [RFC7042]; in the absence of an OUI, a MAC/40
   entry cannot be used.

   Typically, an OUI would be provided as a Fixed Address sub-sub-TLV
   (see Section 3.2).

   After Fixed Address sub-sub-TLV processing above, each address set is
   processed by combining each OUI in the address set with each MAC/24
   and each MAC/40 address in the address set. Depending on how many of
   each of these address types is present, zero or more 48-bit and/or
   64-bit MAC addresses may be produced that are considered to be part
   of the address set.  If there are no MAC/24 or MAC/40 addresses
   present, any OUI's are ignored. If there are no OUIs, any MAC/24
   and/or MAC/40s are ignored. If there are K1 OUIs, K2 MAC/24s, and K3
   MAC/40s, K1*K2 48-bit MACs are synthesized and K1*K3 64-bit MACs are
   synthesized.

   IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6


D. Eastlake, et al                                             [Page 15]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


   address. IPv6/64s are ignored unless, after the processing above in
   this sub-section, there are one or more 48-bit and/or 64-bit MAC
   addresses in the address set to provide the lower 64 bits of the IPv6
   address. For this purpose, an 48-bit MAC address is expanded to 64
   bits as described in [RFC7042]. If there are K4 IPv6/64s present and
   K5 48- and 64-bit MAC addresses present, K4*K5 128-bit IPv6 addresses
   are synthesized.



5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry

   IANA is requested to establish a new subregistry of the TRILL
   Parameter Registry for sub-sub-TLVs of the Interface Addresses
   APPsub-TLV with initial contents as shown below.

      Name:       Interface Addresses APPsub-TLV Sub-Sub-TLVs

      Procedure:  Expert Review

      Note:  Types greater than 255 are not usable in some contexts.

      Reference:  This document

          Type      Description       Reference
         ------     -----------       ---------
             0      Reserved
             1      AFN Size          This document
             2      Fixed Address     This document
             3      Data Label        This document
             4      Topology          This document
         5-254      Available
           255      Reserved
         256-65534  Available
         65535      Reserved



5.3 IA APPsub-TLV Number

   IANA has allocated TBD1 as the Type for the IA APPsub-TLV in the
   "TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
   registry from the range under 256. In the registry the Name is "IA"
   and the Reference is this document.








D. Eastlake, et al                                             [Page 16]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


Acknowledgments

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

         Linda Dunbar

   The document was prepared in raw nroff. All macros used were defined
   within the source file.











































D. Eastlake, et al                                             [Page 17]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


Appendix A: Examples

   Below are example IA APPsub-TLVs.



A.1 Simple Example

   Below is an annotated IA APPsub-TLV carrying two simple pairs of
   EUI-48 MAC addresses and IPv4 addresses from a Push Directory
   [RFC7042]. No sub-sub-TLVs are included.

      0x0002(TBD)   Type: Interface Addresses
      0x001B        Length: 27 (=0x1B)
      0x001B        Address Sets End: 27 (=0x1B)
      0x1234        RBridge Nickname from which reachable
      0b10000000    Flags: Push Directory data
      0xE3          Confidence = 227
      35            Template: 35 (0x23) = 31 + 1(MAC48) + 3*1(IPv4)

            Address Set One
      0x00005E0053A9   48-bitMAC address
      198.51.100.23    IPv4 address

            Address Set Two
      0x00005E00536B   48-bit MAC address
      203.0.113.201    IPv4 address

   Size includes 7 for the fixed fields though and including the one
   byte template, plus 2 times the Address Set size. Each Address Set is
   10 bytes, 6 for the 48-bit MAC address plus 4 for the IPv4 address.
   So total size is 7 + 2*10 = 27.

   See Section 2 for more information on Template.



A.2 Complex Example

   Below is an annotated IA APPsub-TLV carrying three sets of addresses,
   each consisting of an EUI-48 MAC address, an IPv4 addresses, an IPv6
   address, and an RBridge Port ID, all from a Push Directory [RFC7042].
   The IPv6 address for each address set is synthesized from the MAC
   address given in that set and the IPv6/64 64-bit prefix provided
   through a Fixed Address sub-sub-TLV. In addition, a sub-sub-TLV is
   included that provides an FGL which overrides whatever Data Label may
   be provided by the envelope (for example an ESADI-LSP [RFC7357])
   within which this IA APPsub-TLV occurs.




D. Eastlake, et al                                             [Page 18]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


      0x0002(TBD)   Type: Interface Addresses
      0x0036        Length: 54 (=0x36)
      0x0021        Address Sets End: 33 (=0x21)
      0x4321        RBridge Nickname from which reachable
      0b10000000    Flags: Push Directory data
      0xD3          Confidence = 211
      72            Template: 72(0x48)=31+1(MAC48)+3*1(IPv4)+36*1(P)

            Address Set One
      0x00005E0053DE   48-bitMAC address
      198.51.100.105   IPv4 address
      0x1DE3           RBridge Port ID

            Address Set Two
      0x00005E0053E3   48-bit MAC address
      203.0.113.89     IPv4 address
      0x1DEE           RBridge Port ID

            Address Set Three
      0x00005E0053D3   48-bit MAC address
      192.0.2.139      IPv4 address
      0x01DE           RBridge Port ID

            sub-sub-TLV One
      0x0003           Type: Data Label
      0x0003           Length: implies FGL
      0xD3E3E3         Fine Grained Label

            sub-sub-TLV Two
      0x0002           Type: Fixed Address
      0x000A           Size: 0x0A = 10
      0x400A           AFN: IPv6/64
      0x20010DB800000000   IPv6 Prefix: 2001:DB8::

   See Section 2 for more information on Template.

   The Fixed Address sub-sub-TLV causes the IPv6/64 value give to be
   treated as if it occurred as a 4th entry inside each of the three
   Address Sets. When there is an IPv6/64 entry and a 48-bit MAC entry,
   the MAC value is expanded by inserting 0xFFFE immediately after the
   OUI and the resulting 64-bit value is used as the lower 64 bits of
   the resulting IPv6 address [RFC7042]. As a result, a receiving TRILL
   switch would treat the three Address Sets shown as if they had an
   IPv6 address in them as follows:








D. Eastlake, et al                                             [Page 19]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


            Address Set One
      0x20010DB80000000000005EFFFE0053DE  IPv6 Address

            Address Set Two
      0x20010DB80000000000005EFFFE0053E3  IPv6 Address

            Address Set Three
      0x20010DB80000000000005EFFFE0053D3  IPv6 Address

   As an alternative to the compact "well know value" Template encoding
   used in this example above, the less compact explicit AFN encoding
   could have been used. In that case, the IA APPsub-TLV would have
   started as follows:

      0x0002(TBD)   Type: Interface Addresses
      0x003C        Length: 60 (=0x3C)
      0x0027        Address Sets End: 39 (=0x27)
      0x4321        RBridge Nickname from which reachable
      0b10000000    Flags: Push Directory data
      0xD3          Confidence = 211
      0x3           Template: 3 AFNs
      0x4005        AFN: 48-bit MAC
      0x0001        AFN: IPv4
      0x400B        AFN: RBridge Port ID

   As a final point, since the 48-bit MAC addresses in these three
   Address Sets all have the same OUI (the IANA OUI [RFC7042]), it would
   have been possible to just have a MAC/24 value giving the lower 24
   bits of the MAC in each Address Set. The OUI would them be supplied
   by a second Fixed Address sub-sub-TLV proving the OUI. With N Address
   Sets, this would have saved 3*N or 9 bytes in this case at the cost
   of 9 bytes (2 each for the type and length of the sub-sub-TLV, 2 for
   the OUI AFN number, and 3 for the OUI). So, with just three Address
   Sets, there would be no net saving; however, with a larger number of
   Address Sets, there would be a net savings.

















D. Eastlake, et al                                             [Page 20]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


Appendix Z: Change History

From -00 to -01

   1. Update references for RFC publications.

   2. Add this Change History Appendix.

From -01 to -02

   1. Fix off-by-one errors in body text and examples for well known
      Template values.

   2. Update for drafts published as RFCs and change in Author Address.

   3. Minor editorial improvements.




































D. Eastlake, et al                                             [Page 21]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


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.

   [RFC826] - Plummer, D., "An Ethernet Address Resolution Protocol",
         RFC 826, November 1982.

   [RFC903] - Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
         Reverse Address Resolution Protocol", STD 38, RFC 903, June
         1984.

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

   [RFC4861] - Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
         "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
         September 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", RFC 5305, October 2008.

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

   [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising
         Generic Information in IS-IS", RFC 6823, December 2012.

   [RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and
         IETF Protocol and Documentation Usage for IEEE 802 Parameters",
         BCP 141, RFC 7042, October 2013.

   [RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
         and D. Dutt, "Transparent Interconnection of Lots of Links
         (TRILL): Fine-Grained Labeling", RFC 7172, May 2014.

   [RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
         Scope Link State PDUs (LSPs)", RFC 7356, September 2014,
         <http://www.rfc-editor.org/info/rfc7356>.


D. Eastlake, et al                                             [Page 22]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


   [RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
         Stokes, "Transparent Interconnection of Lots of Links (TRILL):
         End Station Address Distribution Information (ESADI) Protocol",
         RFC 7357, September 2014, <http://www.rfc-
         editor.org/info/rfc7357>.



Informational References

   [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large
         Data Centers", draft-shah-armd-arp-reduction, work in progress.

   [ChannelTunnel] - D. Eastlake, Y. Li, "TRILL: RBridge Channel Tunnel
         Protocol", draft-eastlake-trill-channel-tunnel, work in
         progress.

   [DirectoryScheme] - Dunbar, L., D. Eastlake, R. Perlman, I.
         Gashinsky, Y. Li, "TRILL": Directory Assistance Mechanisms",
         draft-dunbar-trill-scheme-for-directory-assist, work in
         progress.

   [RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines
         for the Address Resolution Protocol (ARP)", RFC 5494, April
         2009.

   [RFC7067] - Dunbar, L., Eastlake 3rd, D., Perlman, R., and I.
         Gashinsky, "Directory Assistance Problem and High-Level Design
         Proposal", RFC 7067, November 2013.

   [RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
         Ward, "Transparent Interconnection of Lots of Links (TRILL):
         RBridge Channel Support", RFC 7178, May 2014.



















D. Eastlake, et al                                             [Page 23]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


Authors' Addresses

   Donald Eastlake
   Huawei Technologies
   155 Beaver Street
   Milford, MA 01757 USA

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


   Yizhou Li
   Huawei Technologies
   101 Software Avenue,
   Nanjing 210012 China

   Phone: +86-25-56622310
   Email: liyizhou@huawei.com


   Radia Perlman
   EMC
   2010 256th Avenue NE, #200
   Bellevue, WA 98007 USA

   Email: Radia@alum.mit.edu


























D. Eastlake, et al                                             [Page 24]

INTERNET-DRAFT                                      TRILL: IA APPsub-TLV


Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2014 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 25]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/