tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7780

 
 
 

Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates

Part 3 of 3, p. 37 to 57
Prev RFC Part

 


prevText      Top      ToC       Page 37 
12.  IANA Considerations (Changed)

   This section lists IANA actions previously completed and new IANA
   actions.

12.1.  Previously Completed IANA Actions (Unchanged)

   The following IANA actions were completed as part of [RFC7180] and
   are included here for completeness, since this document obsoletes
   [RFC7180].

   1. The nickname 0xFFC1, which was reserved by [RFC6325], is allocated
      for use in the TRILL Header Egress Nickname field to indicate an
      OOMF (Overload Originated Multi-destination Frame).

   2. Bit 1 from the seven previously reserved (RESV) bits in the
      per-neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC7176]
      is allocated to indicate that the RBridge sending the TRILL Hello
      volunteers to provide the OOMF forwarding service described in
      Section 2.4.2 to such frames originated by the TRILL switch whose
      SNPA (MAC address) appears in that Neighbor RECORD.  The
      description of this bit is "Offering OOMF service".

   3. Bit 0 is allocated from the capability bits in the PORT-TRILL-VER
      sub-TLV [RFC7176] to indicate support of the VLANs Appointed
      sub-TLV [RFC7176] and the VLAN inhibition setting mechanisms
      specified in [RFC6439bis].  The description of this bit is "Hello
      reduction support".

12.2.  New IANA Actions (New)

   The following are new IANA actions for this document.

12.2.1.  Reference Updated

   All references to [RFC7180] in the "Transparent Interconnection of
   Lots of Links (TRILL) Parameters" registry have been replaced with
   references to this document, except that the Reference for bit 0 in
   the PORT-TRILL-VER Sub-TLV Capability Flags has been changed to
   [RFC6439bis].

12.2.2.  The "E" Capability Bit

   There is an existing TRILL version sub-TLV, sub-TLV #13, under both
   TLV #242 and TLV #144 [RFC7176].  This TRILL version sub-TLV contains
   a capability bits field for which assignments are documented in the
   "TRILL-VER Sub-TLV Capability Flags" registry on the TRILL Parameters
   IANA web page.  IANA has allocated 4 from the previously reserved

Top      Up      ToC       Page 38 
   bits in this "TRILL-VER Sub-TLV Capability Flags" registry to
   indicate support of the E-L1FS flooding scope as specified in
   Section 8.1.  This capability bit is referred to as the "E" bit.  The
   following is the addition to the "TRILL-VER Sub-TLV Capability Flags"
   registry:

       Bit     Description             References
       ----   ---------------------   ---------------
       4      E-L1FS FS-LSP support   [RFC7356], RFC 7780

12.2.3.  NickFlags APPsub-TLV Number and Registry

   IANA has assigned an APPsub-TLV number, as follows, under the TRILL
   GENINFO TLV from the range less than 255.

        Type      Name           References
        ----    ---------       -----------
        6       NICKFLAGS       RFC 7780

   In addition, IANA has created a registry on its TRILL Parameters web
   page for NickFlags bit assignments, as follows:

        Name: NickFlags Bits
        Registration Procedure: IETF Review [RFC5226]
        Reference: RFC 7780

         Bit   Mnemonic  Description      Reference
        -----  --------  -----------      ---------
         0       IN      Used as ingress  RFC 7780
        1-15      -      Unassigned       RFC 7780

12.2.4.  Updated TRILL Extended Header Flags

   The "TRILL Extended Header Flags" registry has been updated as
   follows:

   Bits     Purpose                                  Reference
   -----   ----------------------------------------  ------------

   14-16   Extended Hop Count                        RFC 7780

   27-28   Extended Color                            RFC 7780

   29-31   Available non-critical ingress-to-egress  [RFC7179], RFC 7780
           flags

Top      Up      ToC       Page 39 
12.2.5.  TRILL-VER Sub-TLV Capability Flags

   The "TRILL-VER Sub-TLV Capability Flags" registry has been updated as
   follows:

   Bit     Description                   Reference
   -----  --------------------------     ----------------

      14  Extended Hop Count support     RFC 7780

   15-16  Unassigned                     RFC 7780

   27-28  Extended Color support         RFC 7780

   29-31  Extended header flag support   [RFC7179], RFC 7780

12.2.6.  Example Nicknames

   As shown in the table below, IANA has assigned a block of eight
   nicknames for use as examples in documentation.  Appendix B shows a
   use of some of these nicknames.  The "TRILL Nicknames" registry has
   been updated by changing the previous "0xFFC2-0xFFFE Unassigned" line
   to the following:

       Name        Description                        Reference
   -------------  --------------                     -----------
   0xFFC2-0xFFD7  Unassigned
   0xFFD8-0xFFDF  For use in documentation examples  RFC 7780
   0xFFE0-0xFFFE  Unassigned

13.  Security Considerations (Changed)

   See [RFC6325] for general TRILL security considerations.

   This memo improves the documentation of the TRILL protocol; corrects
   six errata in [RFC6325]; updates [RFC6325], [RFC7177], and [RFC7179];
   and obsoletes [RFC7180].  It does not change the security
   considerations of those RFCs, except as follows:

   o  E-L1FS FS-LSPs can be authenticated with IS-IS security [RFC5310],
      that is, through the inclusion of an IS-IS Authentication TLV in
      E-L1FS PDUs.

   o  As discussed in Section 3.6, when using an allowed weaker RPF
      check under very rare topologies and transient conditions,
      multi-destination TRILL Data packets can be duplicated; this could
      have security consequences for some protocols.

Top      Up      ToC       Page 40 
14.  References

14.1.  Normative References

   [802.1Q-2014]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks -- Bridges and Bridged Networks",
              DOI 10.1109/IEEESTD.2014.6991462, IEEE Std 802.1Q-2014.

   [IS-IS]    International Organization for Standardization,
              "Information technology -- Telecommunications and
              information exchange between systems -- Intermediate
              System to Intermediate System intra-domain routeing
              information exchange protocol for use in conjunction with
              the protocol for providing the connectionless-mode network
              service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
              November 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305,
              October 2008, <http://www.rfc-editor.org/info/rfc5305>.

   [RFC5306]  Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
              RFC 5306, DOI 10.17487/RFC5306, October 2008,
              <http://www.rfc-editor.org/info/rfc5306>.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, DOI 10.17487/RFC5310,
              February 2009, <http://www.rfc-editor.org/info/rfc5310>.

   [RFC6232]  Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
              Originator Identification TLV for IS-IS", RFC 6232,
              DOI 10.17487/RFC6232, May 2011,
              <http://www.rfc-editor.org/info/rfc6232>.

   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
              <http://www.rfc-editor.org/info/rfc6325>.

Top      Up      ToC       Page 41 
   [RFC6361]  Carlson, J. and D. Eastlake 3rd, "PPP Transparent
              Interconnection of Lots of Links (TRILL) Protocol Control
              Protocol", RFC 6361, DOI 10.17487/RFC6361, August 2011,
              <http://www.rfc-editor.org/info/rfc6361>.

   [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,
              DOI 10.17487/RFC7172, May 2014,
              <http://www.rfc-editor.org/info/rfc7172>.

   [RFC7176]  Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
              D., and A. Banerjee, "Transparent Interconnection of Lots
              of Links (TRILL) Use of IS-IS", RFC 7176,
              DOI 10.17487/RFC7176, May 2014,
              <http://www.rfc-editor.org/info/rfc7176>.

   [RFC7177]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
              V. Manral, "Transparent Interconnection of Lots of Links
              (TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177,
              May 2014, <http://www.rfc-editor.org/info/rfc7177>.

   [RFC7179]  Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
              Bestler, "Transparent Interconnection of Lots of Links
              (TRILL): Header Extension", RFC 7179,
              DOI 10.17487/RFC7179, May 2014,
              <http://www.rfc-editor.org/info/rfc7179>.

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

   [RFC7455]  Senevirathne, T., Finn, N., Salam, S., Kumar, D., Eastlake
              3rd, D., Aldrin, S., and Y. Li, "Transparent
              Interconnection of Lots of Links (TRILL): Fault
              Management", RFC 7455, DOI 10.17487/RFC7455, March 2015,
              <http://www.rfc-editor.org/info/rfc7455>.

Top      Up      ToC       Page 42 
14.2.  Informative References

   [802]      IEEE 802, "IEEE Standard for Local and Metropolitan Area
              Networks: Overview and Architecture",
              DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802-2014.

   [Centralized-Replication]
              Hao, W., Li, Y., Durrani, M., Gupta, S., Qu, A., and T.
              Han, "Centralized Replication for BUM traffic in
              active-active edge connection", Work in Progress,
              draft-ietf-trill-centralized-replication-03,
              November 2015.

   [Err3002]  RFC Errata, Erratum ID 3002, RFC 6325.

   [Err3003]  RFC Errata, Erratum ID 3003, RFC 6325.

   [Err3004]  RFC Errata, Erratum ID 3004, RFC 6325.

   [Err3052]  RFC Errata, Erratum ID 3052, RFC 6325.

   [Err3053]  RFC Errata, Erratum ID 3053, RFC 6325.

   [Err3508]  RFC Errata, Erratum ID 3508, RFC 6325.

   [RFC792]   Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <http://www.rfc-editor.org/info/rfc792>.

   [RFC826]   Plummer, D., "Ethernet Address Resolution Protocol: Or
              Converting Network Protocol Addresses to 48.bit Ethernet
              Address for Transmission on Ethernet Hardware", STD 37,
              RFC 826, DOI 10.17487/RFC0826, November 1982,
              <http://www.rfc-editor.org/info/rfc826>.

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <http://www.rfc-editor.org/info/rfc4086>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

Top      Up      ToC       Page 43 
   [RFC6327]  Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., and
              V. Manral, "Routing Bridges (RBridges): Adjacency",
              RFC 6327, DOI 10.17487/RFC6327, July 2011,
              <http://www.rfc-editor.org/info/rfc6327>.

   [RFC6439]  Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
              Hu, "Routing Bridges (RBridges): Appointed Forwarders",
              RFC 6439, DOI 10.17487/RFC6439, November 2011,
              <http://www.rfc-editor.org/info/rfc6439>.

   [RFC6439bis]
              Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and H.
              Fangwei, "TRILL: Appointed Forwarders", Work in Progress,
              draft-ietf-trill-rfc6439bis-01, January 2016.

   [RFC7042]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
              IETF Protocol and Documentation Usage for IEEE 802
              Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042,
              October 2013, <http://www.rfc-editor.org/info/rfc7042>.

   [RFC7067]  Dunbar, L., Eastlake 3rd, D., Perlman, R., and I.
              Gashinsky, "Directory Assistance Problem and High-Level
              Design Proposal", RFC 7067, DOI 10.17487/RFC7067,
              November 2013, <http://www.rfc-editor.org/info/rfc7067>.

   [RFC7175]  Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
              "Transparent Interconnection of Lots of Links (TRILL):
              Bidirectional Forwarding Detection (BFD) Support",
              RFC 7175, DOI 10.17487/RFC7175, May 2014,
              <http://www.rfc-editor.org/info/rfc7175>.

   [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,
              DOI 10.17487/RFC7178, May 2014,
              <http://www.rfc-editor.org/info/rfc7178>.

   [RFC7180]  Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
              A. Banerjee, "Transparent Interconnection of Lots of Links
              (TRILL): Clarifications, Corrections, and Updates",
              RFC 7180, DOI 10.17487/RFC7180, May 2014,
              <http://www.rfc-editor.org/info/rfc7180>.

Top      Up      ToC       Page 44 
   [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, DOI 10.17487/RFC7357,
              September 2014, <http://www.rfc-editor.org/info/rfc7357>.

   [TRILL-L3-GW]
              Hao, W., Li, Y., Qu, A., Durrani, M., Sivamurugan, P., and
              L. Xia, "TRILL Distributed Layer 3 Gateway", Work in
              Progress, draft-ietf-trill-irb-10, January 2016.

Top      Up      ToC       Page 45 
Appendix A.  Life Cycle of a TRILL Switch Port (New)

   Text from <http://www.ietf.org/mail-archive/web/trill/
   current/msg06355.html> is paraphrased in this informational appendix.

   Question:
      Suppose we are developing a TRILL implementation to run on
      different machines.  Then what happens first?  Is LSP flooding or
      ESADI started first?  -> Link-state database creation ->
      Designated RBridge election (How to set priority?  Any fixed
      process that depends on user settings?) -> etc.

   Answer:
      The first thing that happens on a port/link is any link setup that
      is needed.  For example, on a PPP link [RFC6361], you need to
      negotiate that you will be using TRILL.  However, if you have
      Ethernet links [RFC6325], which are probably the most common type,
      there isn't any link setup needed.

      As soon as the port is set up, it can ingress or egress native
      frames if end-station service is being offered on that port.
      Offering end-station service is the default.  However, if the port
      trunk bit (end-station service disable) is set or the port is
      configured as an IS-IS point-to-point link port, then end-station
      service is not offered; therefore, native frames received are
      ignored, and native frames are not egressed.

      TRILL IS-IS Hellos then get sent out the port to be exchanged with
      any other TRILL switches on the link [RFC7177].  Only the Hellos
      are required; optionally, you might also exchange MTU-probe/ack
      PDUs [RFC7177], BFD PDUs [RFC7175], or other link test packets.

      TRILL doesn't send any TRILL Data or TRILL IS-IS packets out the
      port to the link, except for Hellos, until the link gets to the
      2-Way or Report state [RFC7177].

      If a link is configured as a point-to-point link, there is no
      Designated RBridge (DRB) election.  By default, an Ethernet link
      is considered a LAN link, and the DRB election occurs when the
      link is in any state other than Down.  You don't have to configure
      priorities for each TRILL switch (RBridge) to be the DRB.  Things
      will work fine with all the RBridges on a link using default
      priority.  But if the network manager wants to control this, there
      should be a way for them to configure the priority to be the DRB
      of the TRILL switch ports on the link.

Top      Up      ToC       Page 46 
      (To avoid complexity, this appendix generally describes the
      life cycle for a link that only has two TRILL switches on it.  But
      TRILL works fine as currently specified on a broadcast link with
      multiple TRILL switches on it -- actually, multiple TRILL switch
      ports -- since a TRILL switch can have multiple ports connected to
      the same link.  The most likely way to get such a multi-access
      link with current technology and the existing TRILL standards is
      to have more than two TRILL switch Ethernet ports connected to a
      bridged LAN.  The TRILL protocol operates above all bridging; in
      general, the bridged LAN looks like a transparent broadcast link
      to TRILL.)

      When a link gets to the 2-Way or Report state, LSPs, CSNPs, and
      PSNPs will start to flow on the link (as well as FS-LSPs,
      FS-CSNPs, and FS-PSNPs for E-L1FS (see Section 8.1)).

      When a link gets to the Report state, there is adjacency.  The
      existence of that adjacency is flooded (reported) to the campus in
      LSPs.  TRILL Data packets can then start to flow on the link as
      TRILL switches recalculate the least-cost paths and distribution
      trees to take the new adjacency into account.  Until it gets to
      the Report state, there is no adjacency, and no TRILL Data packets
      can flow over that link (with the minor corner case exception that
      an RBridge Channel message can, for its first hop only, be sent on
      a port where there is no adjacency (Section 2.4 of [RFC7178]).
      (Although this paragraph seems to be talking about link state, it
      is actually port state.  It is possible for different TRILL switch
      ports on the same link to temporarily be in different states.  The
      adjacency state machinery runs independently on each port.)

      ESADI [RFC7357] is built on top of the regular TRILL Data routing.
      Since ESADI PDUs look, to transit TRILL switches, like regular
      TRILL Data packets, no ESADI PDUs can flow until adjacencies are
      established and TRILL Data is flowing.  Of course, ESADI is
      optional and is not used unless configured.

Top      Up      ToC       Page 47 
   Question:
      Does it require TRILL Full Headers at the time TRILL LSPs start
      being broadcast on a link?  Because at that time it's not defined
      egress and ingress nicknames.

   Answer:
      TRILL Headers are only for TRILL Data packets.  TRILL IS-IS
      packets, such as TRILL LSPs, are sent in a different way that does
      not use a TRILL Header and does not depend on nicknames.

      Probably, in most implementations, a TRILL switch will start up
      using the same nickname it had when it shut down or last got
      disconnected from a campus.  If you want, you can implement TRILL
      to come up initially not reporting any nickname (by not including
      a Nickname sub-TLV in its LSPs) until you get the link-state
      database or most of the link-state database, and then choose a
      nickname no other TRILL switch in the campus is using.  Of course,
      if a TRILL switch does not have a nickname, then it cannot ingress
      data, cannot egress known unicast data, and cannot be a tree root.

      TRILL IS-IS PDUs such as LSPs, and the link-state database, all
      work based on the 7-byte IS-IS System ID (sometimes called the
      LAN ID [IS-IS]).  Since topology determination uses System IDs,
      which are always unique across the campus, it is not affected by
      the nickname assignment state.  The nickname system is built on
      top of that.

Top      Up      ToC       Page 48 
Appendix B.  Example TRILL PDUs (New)

   This appendix shows example TRILL IS-IS PDUs.  The primary purpose of
   these examples is to clarify issues related to bit ordering.

   The examples in this appendix concentrate on the format of the packet
   header and trailer.  There are frequently unspecified optional items
   or data in the packet that would affect header or trailer fields like
   the packet length or checksum.  Thus, an "Xed out" placeholder is
   used for such fields, where each X represents one hex nibble.

B.1.  LAN Hello over Ethernet

   A TRILL Hello sent from a TRILL switch (RBridge) with 7-byte
   System ID 0x30033003300300 holding nickname 0xFFDE over Ethernet from
   a port with MAC address 0x00005E0053DE on VLAN 1 at priority 7.
   There is one neighbor that is the DRB.  The neighbor's port MAC is
   0x00005E0053E3, and the neighbor's System ID is 0x44444444444400.

      Ethernet Header
        Outer.MacDA, Outer.MacSA
          0x0180C2000041   All-IS-IS-RBridges Destination MAC Address
          0x00005E0053DE   Source MAC Address
        Outer VLAN Tag (optional)
          0x8100           C-VLAN Ethertype [802.1Q-2014]
          0xE001           Priority 7, Outer.VLAN
        IS-IS
          0x22F4           L2-IS-IS Ethertype
      IS-IS Payload
        Common Header
          0x83             Intradomain Routeing Protocol Discriminator
          0x08             Header Length
          0x01             IS-IS Version Number
          0x06             ID Length of 6 Bytes
          0x0F             PDU Type (Level 1 LAN Hello)
          0x01             Version
          0x00             Reserved
          0x01             Maximum Area Addresses
        Hello PDU Specific Fields
          0x01             Circuit Type (Level 1)
          0x30033003300300 Source System ID
          0x0009           Holding Time
          0xXXXX           PDU Length
          0x40             Priority to be DRB
          0x44444444444400 LAN ID
        TLVs (the following order of TLVs or of sub-TLVs in a TLV
          is not significant)

Top      Up      ToC       Page 49 
        Area Addresses TLV
          0x01             Area Addresses Type
          0x02             Length of Value
          0x01             Length of Address
          0x00             The fixed TRILL Area Address
        MT Port Capabilities TLV
          0x8F             MT Port Capabilities Type
          0x0011           Length of Value
          0x0000           Topology
            Special VLANs and Flags Sub-TLV
              0x01            Sub-TLV Type
              0x08            Length
              0x0123          Port ID
              0xFFDE          Sender Nickname
              0x0001          Outer.VLAN
              0x0001          Designated VLAN
            Enabled VLANs Sub-TLV (optional)
              0x02            Sub-TLV Type
              0x03            Length
              0x0001          Start VLAN 1
              0x80            VLAN 1
        TRILL Neighbor TLV
          0x91            Neighbor Type
          0x0A            Length of Value
          0xC0            S Flag = 1, L Flag = 1, SIZE field 0
            NEIGHBOR RECORD
              0x00            Flags
              0x2328          MTU = 9 KB
              0x00005E0053E3  Neighbor MAC Address
        Scope Flooding Support TLV
        0xF3              Scope Flooding Support Type
        0x01              Length of Value
        0x40              E-L1FS Flooding Scope
        More TLVs (optional)
          ...
      Ethernet Trailer
        0xXXXXXXXX      Ethernet Frame Check Sequence (FCS)

Top      Up      ToC       Page 50 
B.2.  LSP over PPP

   Here is an example of a TRILL LSP sent over a PPP link by the same
   source TRILL switch as the example in Appendix B.1.

      PPP Header
        0x405D               PPP TRILL Link State Protocol
      IS-IS Payload
        Common Header
          0x83               Intradomain Routeing Protocol Discriminator
          0x08               Header Length
          0x01               IS-IS Version Number
          0x06               ID Length of 6 Bytes
          0x12               PDU Type (Level 1 LSP)
          0x01               Version
          0x00               Reserved
          0x01               Maximum Area Addresses
        LSP Specific Fields
          0xXXXX             PDU Length
          0x0123             Remaining Lifetime
          0x3003300330030009 LSP ID (fragment 9)
          0x00001234         Sequence Number
          0xXXXX             Checksum
          0x01               Flags = Level 1
        TLVs (the following order of TLVs or of sub-TLVs in a TLV
          is not significant)
        Router Capability TLV
          0xF2               Router Capability Type
          0x0F               Length of Value
          0x00               Flags
            Nickname Sub-TLV
              0x06           Sub-TLV Type
              0x05           Length of Value
              NICKNAME RECORD
                0x33         Nickname Priority
                0x1234       Tree Root Priority
                0xFFDE       Nickname
            TRILL Version Sub-TLV
              0x0D           Sub-TLV Type
              0x05
              0x00           Max Version
              0x40000000     Flags = FGL Support
        More TLVs (optional
          ...
      PPP Trailer
        0xXXXXXX        PPP Frame Check Sequence (FCS)

Top      Up      ToC       Page 51 
B.3.  TRILL Data over Ethernet

   Below is an IPv4 ICMP Echo [RFC792] sent in a TRILL Data packet from
   the TRILL switch that sent the Hello in Appendix B.1 to the neighbor
   TRILL switch on the link used in Appendix B.1.

      Ethernet Header
        Outer.MacDA, Outer.MacSA
          0x00005E0053E3  Destination MAC Address
          0x00005E0053DE  Source MAC Address
        Outer VLAN Tag (optional)
          0x8100          C-VLAN Ethertype [802.1Q-2014]
          0x0001          Priority 0, Outer.VLAN 1
        TRILL
          0x22F3          TRILL Ethertype
      TRILL Header
          0X000E          Flags, Hop Count 14
          0xFFDF          Egress Nickname
          0xFFDC          Ingress Nickname
      Inner Ethernet Header
        Inner.MacDA, Inner.MacSA
          0x00005E005322  Destination MAC Address
          0x00005E005344  Source MAC Address
        Inner VLAN Tag
          0x8100          C-VLAN Ethertype
          0x0022          Priority 0, Inner.VLAN 34
        Ethertype
          0x0800          IPv4 Ethertype
      IP Header
          0x4500          Version 4, Header Length 5, ToS 0
          0xXXXX          Total Length
          0x3579          Identification
          0x0000          Flags, Fragment Offset
          0x1101          TTL 17, ICMP = Protocol 1
          0xXXXX          Header Checksum
          0xC0000207      Source IP 192.0.2.7
          0xC000020D      Destination IP 192.0.2.13
          0x00000000      Options, Padding
      ICMP
          0x0800          ICMP Echo
          0xXXXX          Checksum
          0x87654321      Identifier, Sequence Number
          ...             Echo Data
      Ethernet Trailer
        0xXXXXXXXX      Ethernet Frame Check Sequence (FCS)

Top      Up      ToC       Page 52 
B.4.  TRILL Data over PPP

   Below is an ARP Request [RFC826] sent in a TRILL Data packet from the
   TRILL switch that sent the Hello in Appendix B.1 over a PPP link.

      PPP Header
        0x005D          PPP TRILL Network Protocol
      TRILL Header
          0X080D          Flags (M = 1), Hop Count 13
          0xFFDD          Distribution Tree Root Nickname
          0xFFDC          Ingress Nickname
      Inner Ethernet Header
        Inner.MacDA, Inner.MacSA
          0xFFFFFFFFFFFF  Destination MAC Address
          0x00005E005344  Source MAC Address
        Inner VLAN Tag
          0x8100          C-VLAN Ethertype
          0x0022          Priority 0, Inner.VLAN 34
        Ethertype
          0x0806          ARP Ethertype
      ARP
          0x0001          Hardware Address Space = Ethernet
          0x0001          Protocol Address Space = IPv4
          0x06            Size of Hardware Address
          0x04            Size of Protocol Address
          0x0001          OpCode = Request
          0x00005E005344  Sender Hardware Address
          0xC0000207      Sender Protocol Address 192.0.2.7
          0x000000000000  Target Hardware Address
          0xC000020D      Target Protocol Address 192.0.2.13
      PPP Trailer
        0xXXXXXX        PPP Frame Check Sequence (FCS)

Top      Up      ToC       Page 53 
Appendix C.  Changes to Previous RFCs (New)

C.1.  Changes to Obsoleted RFC 7180

   This section summarizes the changes, augmentations, and excisions
   this document specifies for [RFC7180], which it obsoletes and
   replaces.

C.1.1.  Changes

   For each section header in this document ending with "(Changed)",
   this section summarizes the changes that are made by this document:

   Section 1 ("Introduction"): Numerous changes to reflect the overall
   changes in contents.

   Section 1.1 ("Precedence"): Changed to add mention of [RFC7179].

   Section 1.3 ("Terminology and Acronyms"): Numerous terms added.

   Section 3 ("Distribution Trees and RPF Check"): Changed by the
   addition of the new material in Section 3.6.  See Appendix C.1.2,
   Item 1.

   Section 8 ("Other IS-IS Considerations"): Changed by the addition of
   Sections 8.1, 8.2, 8.3, and 8.4.  See Appendix C.1.2 -- Items 2, 3,
   4, and 5, respectively.

   Section 9 ("Updates to RFC 7177 (Adjacency)": Changes and additions
   to [RFC7177] to support E-L1FS.  See Appendix C.1.2, Item 2.

   Section 12 ("IANA Considerations"): Changed by the addition of
   material in Section 12.2.  See Appendix C.1.2, Item 7.

   Section 13 ("Security Considerations"): Minor changes in the RFCs
   listed.

C.1.2.  Additions

   This document contains the following material not present in
   [RFC7180]:

   1.  Support for an alternative Reverse Path Forwarding Check (RPFC),
       along with considerations for deciding between the original
       [RFC6325] RPFC and this alternative RPFC.  This alternative RPFC
       was originally discussed on the TRILL WG mailing list in
       <http://www.ietf.org/mail-archive/web/trill/current/
       msg01852.html> and subsequent messages (Section 3.6).

Top      Up      ToC       Page 54 
   2.  Mandatory E-L1FS [RFC7356] support (Sections 8.1 and 9).

   3.  Recommendations concerning control packet priorities
       (Section 8.2).

   4.  Implementation requirements concerning unknown IS-IS PDU types
       (Section 8.3).

   5.  Specification of an optional Nickname Flags APPsub-TLV and an
       ingress flag within that APPsub-TLV (Section 8.4).

   6.  Update to the TRILL Header to allocate a Color bit
       (Section 10.1), and update to the optional TRILL Header Extension
       flags word to allocate a 2-bit Extended Color field
       (Section 10.2).

   7.  Some new IANA Considerations in Section 12.2, including
       reservation of nicknames for use as examples in documentation.

   8.  A new "Appointed Forwarder Status Lost Counter" section
       (Section 11 of this document) that loosens the mandatory update
       requirements specified in [RFC6325].

   9.  Informative Appendix A on the life cycle of a TRILL port.

   10. A new Appendix B containing example TRILL PDUs.

   11. Recommendation to use the Purge Originator Identification TLV
       (Section 8.6).

C.1.3.  Deletions

   This document omits the following material that was present in
   [RFC7180]:

   1.  All updates to [RFC6327] that occurred in [RFC7180].  These have
       been rolled into [RFC7177], which obsoletes [RFC6327].  However,
       new updates to [RFC7177] are included (see Appendix C.3).

   2.  All updates to [RFC6439].  These have been rolled into
       [RFC6439bis], which is intended to obsolete [RFC6439].

Top      Up      ToC       Page 55 
C.2.  Changes to RFC 6325

   This document contains many normative updates to [RFC6325], some of
   which were also in [RFC7180], which this document replaces.  These
   changes include the following:

   1.  Changing nickname allocation to ignore conflicts with RBridges
       that are IS-IS unreachable.

   2.  Fixing errors: [Err3002], [Err3003], [Err3004], [Err3052],
       [Err3053], and [Err3508].

   3.  Changing the requirement to use the RPF check described in
       [RFC6325] for multi-destination TRILL Data packets by providing
       an alternative stronger RPF check.

   4.  Adoption of the change of the CFI bit, which was required to be
       zero in the inner frame, to the DEI bit, which is obtained from
       inner frame ingress or creation.

   5.  Requiring that all RBridges support E-L1FS FS-LSP flooding.

   6.  Reducing the variable-length TRILL Header extensions area to one
       optional flags word.  The Extension Length field (called
       "Op-Length" in [RFC6325]) is reduced to 1 bit that indicates
       whether the flags word is present.  The rest of that Length field
       is now reserved.

   7.  Changing the mandatory Appointed Forwarder Status Lost Counter
       increment provisions, as specified in Section 11.

C.3.  Changes to RFC 7177

   All of the updates to [RFC7177] herein are in Section 9.  Basically,
   this document requires that a Scope Flooding Support TLV [RFC7356]
   appear in all Hellos and that TRILL switches retain in their
   adjacency state the information received in that TLV.

C.4.  Changes to RFC 7179

   The updates to [RFC7179] herein are in Sections 10.2 and 10.3.

Top      Up      ToC       Page 56 
Acknowledgments

   The contributions of the following individuals to this document are
   gratefully acknowledged:

      Santosh Rajagopalan and Gayle Noble

   The contributions of the following (listed in alphabetical order) to
   the preceding version of this document, [RFC7180], are gratefully
   acknowledged:

      Somnath Chatterjee, Weiguo Hao, Rakesh Kumar, Yizhou Li, Radia
      Perlman, Varun Shah, Mike Shand, and Meral Shirazipour.

Authors' Addresses

   Donald Eastlake 3rd
   Huawei Technology
   155 Beaver Street
   Milford, MA  01757
   United States

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


   Mingui Zhang
   Huawei Technologies
   No. 156 Beiqing Rd., Haidian District
   Beijing  100095
   China

   Email: zhangmingui@huawei.com


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

   Email: radia@alum.mit.edu


   Ayan Banerjee
   Cisco

   Email: ayabaner@cisco.com

Top      Up      ToC       Page 57 
   Anoop Ghanwani
   Dell
   5450 Great America Parkway
   Santa Clara, CA  95054
   United States

   Email: anoop@alumni.duke.edu


   Sujay Gupta
   IP Infusion
   RMZ Centennial
   Mahadevapura Post
   Bangalore  560048
   India

   Email: sujay.gupta@ipinfusion.com