tech-invite   World Map     

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

RFC 7780

Proposed STD
Pages: 57
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TRILL

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

Part 1 of 3, p. 1 to 18
None       Next RFC Part

Obsoletes:    7180
Updates:    6325    7177    7179


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 7780                                      M. Zhang
Obsoletes: 7180                                                   Huawei
Updates: 6325, 7177, 7179                                     R. Perlman
Category: Standards Track                                            EMC
ISSN: 2070-1721                                              A. Banerjee
                                                                   Cisco
                                                             A. Ghanwani
                                                                    Dell
                                                                S. Gupta
                                                             IP Infusion
                                                           February 2016


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

Abstract

   Since the publication of the TRILL (Transparent Interconnection of
   Lots of Links) base protocol in 2011, active development and
   deployment of TRILL have revealed errata in RFC 6325 and areas that
   could use clarifications or updates.  RFC 7177, RFC 7357, and an
   intended replacement of RFC 6439 provide clarifications and updates
   with respect to adjacency, the TRILL ESADI (End Station Address
   Distribution Information) protocol, and Appointed Forwarders,
   respectively.  This document provides other known clarifications,
   corrections, and updates.  It obsoletes RFC 7180 (the previous "TRILL
   clarifications, corrections, and updates" RFC), and it updates RFCs
   6325, 7177, and 7179.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7780.

Page 2 
Copyright Notice

   Copyright (c) 2016 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.

Top       Page 3 
Table of Contents

   1. Introduction (Changed) ..........................................5
      1.1. Precedence (Changed) .......................................5
      1.2. Changes That Are Not Backward Compatible (Unchanged) .......6
      1.3. Terminology and Acronyms (Changed) .........................6
   2. Overloaded and/or Unreachable RBridges (Unchanged) ..............7
      2.1. Reachability ...............................................8
      2.2. Distribution Trees .........................................8
      2.3. Overloaded Receipt of TRILL Data Packets ...................9
           2.3.1. Known Unicast Receipt ...............................9
           2.3.2. Multi-Destination Receipt ...........................9
      2.4. Overloaded Origination of TRILL Data Packets ...............9
           2.4.1. Known Unicast Origination ..........................10
           2.4.2. Multi-Destination Origination ......................10
                  2.4.2.1. An Example Network ........................10
                  2.4.2.2. Indicating OOMF Support ...................11
                  2.4.2.3. Using OOMF Service ........................11
   3. Distribution Trees and RPF Check (Changed) .....................12
      3.1. Number of Distribution Trees (Unchanged) ..................12
      3.2. Distribution Tree Update Clarification (Unchanged) ........12
      3.3. Multicast Pruning Based on IP Address (Unchanged) .........13
      3.4. Numbering of Distribution Trees (Unchanged) ...............13
      3.5. Link Cost Directionality (Unchanged) ......................13
      3.6. Alternative RPF Check (New) ...............................14
           3.6.1. Example of the Potential Problem ...................14
           3.6.2. Solution and Discussion ............................15
   4. Nickname Selection (Unchanged) .................................17
   5. MTU (Maximum Transmission Unit) (Unchanged) ....................18
      5.1. MTU-Related Errata in RFC 6325 ............................19
           5.1.1. MTU PDU Addressing .................................19
           5.1.2. MTU PDU Processing .................................20
           5.1.3. MTU Testing ........................................20
      5.2. Ethernet MTU Values .......................................20
   6. TRILL Port Modes (Unchanged) ...................................21
   7. The CFI/DEI Bit (Unchanged) ....................................22
   8. Other IS-IS Considerations (Changed) ...........................23
      8.1. E-L1FS Support (New) ......................................24
           8.1.1. Backward Compatibility .............................24
           8.1.2. E-L1FS Use for Existing (Sub-)TLVs .................25
      8.2. Control Packet Priorities (New) ...........................26
      8.3. Unknown PDUs (New) ........................................27
      8.4. Nickname Flags APPsub-TLV (New) ...........................27
      8.5. Graceful Restart (Unchanged) ..............................29
      8.6. Purge Originator Identification (New) .....................29
   9. Updates to RFC 7177 (Adjacency) (Changed) ......................30

Top      ToC       Page 4 
   10. TRILL Header Update (New) .....................................31
      10.1. Color Bit ................................................32
      10.2. Flags Word Changes (Update to RFC 7179) ..................32
           10.2.1. Extended Hop Count ................................32
                  10.2.1.1. Advertising Support ......................33
                  10.2.1.2. Ingress Behavior .........................33
                  10.2.1.3. Transit Behavior .........................33
                  10.2.1.4. Egress Behavior ..........................34
           10.2.2. Extended Color Field ..............................34
      10.3. Updated Flags Word Summary ...............................35
   11. Appointed Forwarder Status Lost Counter (New) .................35
   12. IANA Considerations (Changed) .................................37
      12.1. Previously Completed IANA Actions (Unchanged) ............37
      12.2. New IANA Actions (New) ...................................37
           12.2.1. Reference Updated .................................37
           12.2.2. The "E" Capability Bit ............................37
           12.2.3. NickFlags APPsub-TLV Number and Registry ..........38
           12.2.4. Updated TRILL Extended Header Flags ...............38
           12.2.5. TRILL-VER Sub-TLV Capability Flags ................39
           12.2.6. Example Nicknames .................................39
   13. Security Considerations (Changed) .............................39
   14. References ....................................................40
      14.1. Normative References .....................................40
      14.2. Informative References ...................................42
   Appendix A. Life Cycle of a TRILL Switch Port (New) ...............45
   Appendix B. Example TRILL PDUs (New) ..............................48
      B.1. LAN Hello over Ethernet ...................................48
      B.2. LSP over PPP ..............................................50
      B.3. TRILL Data over Ethernet ..................................51
      B.4. TRILL Data over PPP .......................................52
   Appendix C. Changes to Previous RFCs (New) ........................53
      C.1. Changes to Obsoleted RFC 7180 .............................53
         C.1.1. Changes ..............................................53
         C.1.2. Additions ............................................53
         C.1.3. Deletions ............................................54
      C.2. Changes to RFC 6325 .......................................55
      C.3. Changes to RFC 7177 .......................................55
      C.4. Changes to RFC 7179 .......................................55
   Acknowledgments ...................................................56
   Authors' Addresses ................................................56

Top      ToC       Page 5 
1.  Introduction (Changed)

   Since the TRILL base protocol [RFC6325] was published in 2011, active
   development and deployment of TRILL have revealed errors in the
   specification [RFC6325] and several areas that could use
   clarifications or updates.

   [RFC7177], [RFC7357], and [RFC6439bis] provide clarifications and
   updates with respect to adjacency, the TRILL ESADI (End Station
   Address Distribution Information) protocol, and Appointed Forwarders,
   respectively.  This document provides other known clarifications,
   corrections, and updates to [RFC6325], [RFC7177], and [RFC7179].
   This document obsoletes [RFC7180] (the previous TRILL
   "clarifications, corrections, and updates" document), updates
   [RFC6325], updates [RFC7177] as described in Section 9, and updates
   [RFC7179] as described in Sections 10.2 and 10.3.  The changes to
   these RFCs are summarized in Appendix C.

   Sections of this document are annotated as to whether they are "New"
   technical material, material that has been technically "Changed", or
   material that is technically "Unchanged", by the appearance of one of
   these three words in parentheses at the end of the section header.  A
   section with only editorial changes is annotated as "(Unchanged)".
   If no such notation appears, then the first notation encountered on
   going to successively higher-level section headers (those with
   shorter section numbers) applies.  Appendix C describes changes,
   summarizes material added, and lists material deleted.

1.1.  Precedence (Changed)

   In the event of any conflicts between this document and [RFC6325],
   [RFC7177], or [RFC7179], this document takes precedence.

   In addition, Section 1.2 of [RFC6325] ("Normative Content and
   Precedence") is updated to provide a more complete precedence
   ordering of the sections of [RFC6325], as shown below, where sections
   to the left take precedence over sections to their right.  There are
   no known conflicts between these sections; however, Sections 1 and 2
   are less detailed and do not mention every corner case, while
   subsequent sections of [RFC6325] are more detailed.  This precedence
   is specified as a fallback in case some conflict is found in the
   future.

                       4 > 3 > 7 > 5 > 2 > 6 > 1

Top      ToC       Page 6 
1.2.  Changes That Are Not Backward Compatible (Unchanged)

   The change made by Section 3.4 below (unchanged from Section 3.4 of
   [RFC7180]) is not backward compatible with [RFC6325] but has
   nevertheless been adopted to reduce distribution tree changes
   resulting from topology changes.

   Several other changes herein that are fixes to errata for [RFC6325]
   -- [Err3002], [Err3003], [Err3004], [Err3052], [Err3053], and
   [Err3508] -- may not be backward compatible with previous
   implementations that conformed to errors in the specification.

1.3.  Terminology and Acronyms (Changed)

   This document uses the acronyms defined in [RFC6325], some of which
   are repeated below for convenience, along with some additional
   acronyms and terms, as follows:

   BFD - Bidirectional Forwarding Detection.

   Campus - A TRILL network consisting of TRILL switches, links, and
      possibly bridges bounded by end stations and IP routers.  For
      TRILL, there is no "academic" implication in the name "campus".

   CFI - Canonical Format Indicator [802].

   CSNP - Complete Sequence Number PDU.

   DEI - Drop Eligibility Indicator [802.1Q-2014].

   FGL - Fine-Grained Labeling [RFC7172].

   FS-LSP - Flooding Scope LSP.

   OOMF - Overload Originated Multi-destination Frame.

   P2P - Point-to-point.

   PDU - Protocol Data Unit.

   PSNP - Partial Sequence Number PDU.

   RBridge - Routing Bridge, an alternative name for a TRILL switch.

   RPFC - Reverse Path Forwarding Check.

   SNPA - Subnetwork Point of Attachment (for example, Media Access
      Control (MAC) address).

Top      ToC       Page 7 
   ToS - Type of Service.

   TRILL - Transparent Interconnection of Lots of Links or Tunneled
      Routing in the Link Layer.

   TRILL switch - A device implementing the TRILL protocol.  An
      alternative name for an RBridge.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   In this document, a "packet" usually refers to a TRILL Data packet or
   TRILL IS-IS packet received from or sent to a TRILL switch, while a
   "frame" usually refers to a native frame being received from or sent
   to an end station.  (The word "frame" also occurs in other contexts,
   such as the "Frame Check Sequence" that is at the end of Ethernet
   transmissions.)

2.  Overloaded and/or Unreachable RBridges (Unchanged)

   In this section, the term "neighbor" refers only to actual RBridges
   and ignores pseudonodes.

   RBridges may be in overload, as indicated by the [IS-IS] overload
   flag in their LSPs (Link State PDUs).  This means that either (1)
   they are incapable of holding the entire link-state database and thus
   do not have a view of the entire topology or (2) they have been
   configured to have the overload bit set.  Although networks should be
   engineered to avoid actual link-state overload, it might occur under
   various circumstances -- for example, if a very large campus included
   one or more low-end TRILL switches.

   It is a common operational practice to set the overload bit in an
   [IS-IS] router (such as a TRILL switch) when performing maintenance
   on that router that might affect its ability to correctly forward
   packets; this will usually leave the router reachable for maintenance
   traffic, but transit traffic will not be routed through it.  (Also,
   in some cases, TRILL provides for setting the overload bit in the
   pseudonode of a link to stop TRILL Data traffic on an access link
   (see Section 4.9.1 of [RFC6325]).)

   [IS-IS] and TRILL make a reasonable effort to do what they can, even
   if some TRILL switches/routers are in overload.  They can do
   reasonably well if a few scattered nodes are in overload.  However,
   actual least-cost paths are no longer assured if any TRILL switches
   are in overload.

Top      ToC       Page 8 
   For the effect of overload on the appointment of forwarders, see
   [RFC6439bis].

2.1.  Reachability

   Packets are not least-cost routed through an overloaded TRILL switch,
   although they may originate or terminate at an overloaded TRILL
   switch.  In addition, packets will not be least-cost routed over
   links with cost 2**24 - 1 [RFC5305]; such links are reserved for
   traffic-engineered packets, the handling of which is beyond the scope
   of this document.

   As a result, a portion of the campus may be unreachable for
   least-cost routed TRILL Data because all paths to it would be either
   through a link with cost 2**24 - 1 or through an overloaded RBridge.
   For example, an RBridge (TRILL switch) RB1 is not reachable by TRILL
   Data if all of its neighbors are connected to RB1 by links with cost
   2**24 - 1.  Such RBridges are called "data unreachable".

   The link-state database at an RBridge -- for example, RB1 -- can also
   contain information on TRILL switches that are unreachable by IS-IS
   link-state flooding due to link or RBridge failures.  When such
   failures partition the campus, the TRILL switches adjacent to the
   failure and on the same side of the failure as RB1 will update their
   LSPs to show the lack of connectivity, and RB1 will receive those
   updates.  As a result, RB1 will be aware of the partition.  Nodes on
   the far side of the partition are both IS-IS unreachable and data
   unreachable from RB1.  However, LSPs held by RB1 for TRILL switches
   on the far side of the failure will not be updated and may stay
   around until they time out, which could be tens of minutes or longer.
   (The default in [IS-IS] is twenty minutes.)

2.2.  Distribution Trees

   An RBridge in overload cannot be trusted to correctly calculate
   distribution trees or correctly perform the RPFC (Reverse Path
   Forwarding Check).  Therefore, it cannot be trusted to forward
   multi-destination TRILL Data packets.  It can only appear as a leaf
   node in a TRILL multi-destination distribution tree.  Furthermore, if
   all the immediate neighbors of an RBridge are overloaded, then it is
   omitted from all trees in the campus and is unreachable by
   multi-destination packets.

   When an RBridge determines what nicknames to use as the roots of the
   distribution trees it calculates, it MUST ignore all nicknames held
   by TRILL switches that are in overload or are data unreachable.  When
   calculating RPFCs for multi-destination packets, an RBridge such as
   RB1 MAY, to avoid calculating unnecessary RPFC state information,

Top      ToC       Page 9 
   ignore any trees that cannot reach RB1, even if other RBridges list
   those trees as trees that other TRILL switches might use.  (However,
   see Section 3.)

2.3.  Overloaded Receipt of TRILL Data Packets

   The receipt of TRILL Data packets by overloaded RBridge RB2 is
   discussed in the subsections below.  In all cases, the normal
   Hop Count decrement is performed, and the TRILL Data packets are
   discarded if the result is less than one or if the Egress Nickname is
   illegal.

2.3.1.  Known Unicast Receipt

   RB2 will not usually receive unicast TRILL Data packets unless it is
   the egress, in which case it egresses and delivers the data normally.
   If RB2 receives a unicast TRILL Data packet for which it is not the
   egress, perhaps because a neighbor does not yet know it is in
   overload, RB2 MUST NOT discard the packet because the egress is an
   unknown nickname, as it might not know about all nicknames due to its
   overloaded condition.  If any neighbor other than the neighbor from
   which it received the packet is not overloaded, it MUST attempt to
   forward the packet to one of those neighbors selected at random
   [RFC4086].  If there is no such neighbor, the packet is discarded.

2.3.2.  Multi-Destination Receipt

   If RB2 in overload receives a multi-destination TRILL Data packet,
   RB2 MUST NOT apply an RPFC because, due to overload, it might not do
   so correctly.  RB2 egresses and delivers the frame locally where it
   is Appointed Forwarder for the frame's VLAN (or, if the packet is
   FGL, for the VLAN that FGL maps to at the port), subject to any
   multicast pruning.  But because, as stated above, RB2 can only be the
   leaf of a distribution tree, it MUST NOT forward a multi-destination
   TRILL Data packet (except as an egressed native frame where RB2 is
   Appointed Forwarder).

2.4.  Overloaded Origination of TRILL Data Packets

   Overloaded origination of unicast TRILL Data packets with known
   egress and of multi-destination packets is discussed in the
   subsections below.

Top      ToC       Page 10 
2.4.1.  Known Unicast Origination

   When RB2, an overloaded RBridge, ingresses or creates a known
   destination unicast data packet, it delivers it locally if the
   destination is local.  Otherwise, RB2 unicasts it to any neighbor
   TRILL switch that is not overloaded.  It MAY use what routing
   information it has to help select the neighbor.

2.4.2.  Multi-Destination Origination

   Overloaded RBridge RB2 ingressing or creating a multi-destination
   data packet presents a more complex scenario than that of the known
   unicast case, as discussed below.

2.4.2.1.  An Example Network

   For example, consider the network diagram below in which, for
   simplicity, end stations and any bridges are not shown.  There is one
   distribution tree of which RB4 is the root, as represented by double
   lines.  Only RBridge RB2 is overloaded.

            +-----+    +-----+     +-----+     +-----+
            | RB7 +====+ RB5 +=====+ RB3 +=====+ RB1 |
            +-----+    +--+--+     +-++--+     +--+--+
                          |          ||           |
                      +---+---+      ||           |
               +------+RB2(ov)|======++           |
               |      +-------+      ||           |
               |                     ||           |
            +--+--+    +-----+   ++==++=++     +--+--+
            | RB8 +====+ RB6 +===++ RB4 ++=====+ RB9 |
            +-----+    +-----+   ++=====++     +-----+

   Since RB2 is overloaded, it does not know what the distribution tree
   or trees are for the network.  Thus, there is no way it can provide
   normal TRILL Data service for multi-destination native frames.  So,
   RB2 tunnels the frame in a TRILL Data packet to a neighbor that is
   not overloaded if it has such a neighbor that has signaled that it is
   willing to offer this service.  RBridges indicate this in their
   Hellos as described below.  This service is called the OOMF (Overload
   Originated Multi-destination Frame) service.

   - The multi-destination frame MUST NOT be locally distributed in
     native form at RB2, because this would cause the frame to be
     delivered twice.  Instead, it is tunneling to a neighbor as
     described in this section.  For example, if RB2 locally distributed
     a multicast native frame and then tunneled it to RB5, RB2 would get
     a copy of the frame when RB3 transmitted it as a TRILL Data packet

Top      ToC       Page 11 
     on the multi-access RB2-RB3-RB4 link.  Since RB2 would, in general,
     not be able to tell that this was a frame it had tunneled for
     distribution, RB2 would decapsulate it and locally distribute it a
     second time.

   - On the other hand, if there is no neighbor of RB2 offering RB2 the
     OOMF service, RB2 cannot tunnel the frame to a neighbor.  In this
     case, RB2 MUST locally distribute the frame where it is Appointed
     Forwarder for the frame's VLAN and optionally subject to multicast
     pruning.

2.4.2.2.  Indicating OOMF Support

   An RBridge RB3 indicates its willingness to offer the OOMF service to
   RB2 in the TRILL Neighbor TLV in RB3's TRILL Hellos by setting a bit
   associated with the SNPA (Subnetwork Point of Attachment, also known
   as MAC address) of RB2 on the link (see the IANA Considerations
   section).  Overloaded RBridge RB2 can only distribute
   multi-destination TRILL Data packets to the campus if a neighbor of
   RB2 not in overload offers RB2 the OOMF service.  If RB2 does not
   have OOMF service available to it, RB2 can still receive
   multi-destination packets from non-overloaded neighbors, and if RB2
   should originate or ingress such a frame, it distributes it locally
   in native form.

2.4.2.3.  Using OOMF Service

   If RB2 sees this OOMF (Overload Originated Multi-destination Frame)
   service advertised for it by any of its neighbors on any link to
   which RB2 connects, it selects one such neighbor by a means that is
   beyond the scope of this document.  Assuming that RB2 selects RB3 to
   handle multi-destination packets it originates, RB2 MUST advertise in
   its LSP that it might use any of the distribution trees that RB3
   advertises so that the RPFC will work in the rest of the campus.
   Thus, notwithstanding its overloaded state, RB2 MUST retain this
   information from RB3 LSPs, which it will receive, as it is directly
   connected to RB3.

   RB2 then encapsulates such frames as TRILL Data packets to RB3 as
   follows: "M" bit = 0; Hop Count = 2; Ingress Nickname = a nickname
   held by RB2; and, since RB2 cannot tell what distribution tree RB3
   will use, Egress Nickname = a special nickname indicating an OOMF
   packet (see the IANA Considerations section).  RB2 then unicasts this
   TRILL Data packet to RB3.  (Implementation of Item 4 in Section 4
   below provides reasonable assurance that, notwithstanding its
   overloaded state, the ingress nickname used by RB2 will be unique
   within at least the portion of the campus that is IS-IS reachable
   from RB2.)

Top      ToC       Page 12 
   On receipt of such a packet, RB3 does the following:

   - changes the Egress Nickname field to designate a distribution tree
     that RB3 normally uses,

   - sets the "M" bit to one,

   - changes the Hop Count to the value it would normally use if it were
     the ingress, and

   - forwards the TRILL Data packet on that tree.

   RB3 MAY rate-limit the number of packets for which it is providing
   this service by discarding some such packets from RB2.  The provision
   of even limited bandwidth for OOMFs by RB3, perhaps via the slow
   path, may be important to the bootstrapping of services at RB2 or at
   end stations connected to RB2, such as supporting DHCP and ARP/ND
   (Address Resolution Protocol / Neighbor Discovery).  (Everyone
   sometimes needs a little OOMF (pronounced "oomph") to get off the
   ground.)

3.  Distribution Trees and RPF Check (Changed)

   Two corrections, a clarification, and two updates related to
   distribution trees appear in the subsections below, along with an
   alternative, stronger RPF (Reverse Path Forwarding) check.  See also
   Section 2.2.

3.1.  Number of Distribution Trees (Unchanged)

   In [RFC6325], Section 4.5.2, page 56, point 2, fourth paragraph, the
   parenthetical "(up to the maximum of {j,k})" is incorrect [Err3052].
   It should read "(up to k if j is zero or the minimum of (j, k) if j
   is non-zero)".

3.2.  Distribution Tree Update Clarification (Unchanged)

   When a link-state database change causes a change in the distribution
   tree(s), several possible types of change can occur.  If a tree root
   remains a tree root but the tree changes, then local forwarding and
   RPFC entries for that tree should be updated as soon as practical.
   Similarly, if a new nickname becomes a tree root, forwarding and RPFC
   entries for the new tree should be installed as soon as practical.
   However, if a nickname ceases to be a tree root and there is
   sufficient room in local tables, the forwarding and RPFC entries for
   the former tree MAY be retained so that any multi-destination TRILL
   Data packets already in flight on that tree have a higher probability
   of being delivered.

Top      ToC       Page 13 
3.3.  Multicast Pruning Based on IP Address (Unchanged)

   The TRILL base protocol specification [RFC6325] provides for, and
   recommends the pruning of, multi-destination packet distribution
   trees based on the location of IP multicast routers and listeners;
   however, multicast listening is identified by derived MAC addresses
   as communicated in the Group MAC Address sub-TLV [RFC7176].

   TRILL switches MAY communicate multicast listeners and prune
   distribution trees based on the actual IPv4 or IPv6 multicast
   addresses involved.  Additional Group Address sub-TLVs are provided
   in [RFC7176] to carry this information.  A TRILL switch that is only
   capable of pruning based on derived MAC addresses SHOULD calculate
   and use such derived MAC addresses from the multicast listener IPv4
   or IPv6 address information it receives.

3.4.  Numbering of Distribution Trees (Unchanged)

   Section 4.5.1 of [RFC6325] specifies that, when building distribution
   tree number j, node (RBridge) N that has multiple possible parents in
   the tree is attached to possible parent number j mod p.  Trees are
   numbered starting with 1, but possible parents are numbered starting
   with 0.  As a result, if there are two trees and two possible
   parents, then in tree 1 parent 1 will be selected, and in tree 2
   parent 0 will be selected.

   This is changed so that the selected parent MUST be (j-1) mod p.  As
   a result, in the case above, tree 1 will select parent 0, and tree 2
   will select parent 1.  This change is not backward compatible with
   [RFC6325].  If all RBridges in a campus do not determine distribution
   trees in the same way, then for most topologies, the RPFC will drop
   many multi-destination packets before they have been properly
   delivered.

3.5.  Link Cost Directionality (Unchanged)

   Distribution tree construction, like other least-cost aspects of
   TRILL, works even if link costs are asymmetric, so the cost of the
   hop from RB1 to RB2 is different from the cost of the hop from RB2 to
   RB1.  However, it is essential that all RBridges calculate the same
   distribution trees, and thus all must use either the cost away from
   the tree root or the cost towards the tree root.  The text in
   Section 4.5.1 of [RFC6325] is incorrect, as documented in [Err3508].
   The text says:

      In other words, the set of potential parents for N, for the tree
      rooted at R, consists of those that give equally minimal cost
      paths from N to R and ...

Top      ToC       Page 14 
   but the text should say "from R to N":

      In other words, the set of potential parents for N, for the tree
      rooted at R, consists of those that give equally minimal cost
      paths from R to N and ...

3.6.  Alternative RPF Check (New)

   [RFC6325] mandates a Reverse Path Forwarding (RPF) check on
   multi-destination TRILL Data packets to avoid possible multiplication
   and/or looping of multi-destination traffic during TRILL campus
   topology transients.  This check is logically performed at each TRILL
   switch input port and determines whether it is arriving on the
   expected port based on where the packet started (the ingress
   nickname) and the tree on which it is being distributed.  If not, the
   packet is silently discarded.  This check is fine for point-to-point
   links; however, there are rare circumstances involving multi-access
   ("broadcast") links where a packet can be duplicated despite this
   RPF check and other checks performed by TRILL.

   Section 3.6.1 gives an example of the potential problem, and
   Section 3.6.2 specifies a solution.  This solution is an alternative,
   stronger RPF check that TRILL switches can implement in place of the
   RPF check discussed in [RFC6325].

3.6.1.  Example of the Potential Problem

   Consider this network:

            F--A--B--C--o--D
                        |
                        E

   All the links except the link between C, D, and E are point-to-point
   links.  C, D, and E are connected over a broadcast link represented
   by the pseudonode "o".  For example, they could be connected by a
   bridged LAN.  (Bridged LANs are transparent to TRILL.)

   Although the choice of root is unimportant here, assume that D or F
   is chosen as the root of a distribution tree so that it is obvious
   that the tree looks just like the diagram above.

Top      ToC       Page 15 
   Now assume that a link comes up from A to the same bridged LAN.  The
   network then looks like this:

               +--------+
               |        |
            F--A--B--C--o--D
                        |
                        E

   Let's say the resulting tree in steady state includes all links
   except the B-C link.  After the network has converged, a packet that
   starts from F will go F->A.  Then A will send one copy on the A-B
   link and another copy into the bridged LAN from which it will be
   received by C and D.

   Now consider a transition stage where A and D have acted on the new
   LSPs and programmed their forwarding plane, while B and C have not
   yet done so.  This means that B and C both consider the link between
   them to still be part of the tree.  In this case, a packet that
   starts out from F and reaches A will be copied by A into the A-B link
   and to the bridged LAN.  D's RPF check says to accept packets on this
   tree coming from F over its port on the bridged LAN, so it gets
   accepted.  D is also adjacent to A on the tree, so the tree adjacency
   check, a separate check mandated by [RFC6325], also passes.

   However, the packet that gets to B gets sent out by B to C.  C's RPF
   check still has the old state, and it thinks the packet is OK.  C
   sends the packet along the old tree, which sends the packet into the
   bridged LAN.  D receives one more packet, but the tree adjacency
   check passes at D because C is adjacent to D in the new tree as well.
   The RPF check also passes at D because D's port on the bridged LAN is
   OK for receiving packets from F.

   So, during this transient state, D gets duplicates of every
   multi-destination packet ingressed at F (unless the packet gets
   pruned) until B and C act on the new LSPs and program their
   forwarding tables.

3.6.2.  Solution and Discussion

   The problem stems from the RPF check described in [RFC6325] depending
   only on the port at which a TRILL Data packet is received, the
   ingress nickname, and the tree being used, that is, a check if
   {ingress nickname, tree, input port} is a valid combination according
   to the receiving TRILL switch's view of the campus topology.  A
   multi-access link actually has multiple adjacencies overlaid on one
   physical link, and to avoid the problem shown in Section 3.6.1, a
   stronger check is needed that includes the Layer 2 source address of

Top      ToC       Page 16 
   the TRILL Data packet being received.  (TRILL is a Layer 3 protocol,
   and TRILL switches are true routers that logically strip the Layer 2
   header from any arriving TRILL Data packets and add the appropriate
   new Layer 2 header to any outgoing TRILL Data packet to get it to the
   next TRILL switch, so the Layer 2 source address in a TRILL Data
   packet identifies the immediately previous TRILL switch that
   forwarded the packet.)

   What is needed, instead of checking the validity of the triplet
   {ingress nickname, tree, input port}, is to check that the quadruplet
   {ingress nickname, source SNPA, tree, input port} is valid (where
   "source SNPA" (Subnetwork Point of Attachment) is the Outer.MacSA for
   an Ethernet link).  Although it is true that [RFC6325] also requires
   a check to ensure that a multi-destination TRILL Data packet is from
   a TRILL switch that is adjacent in the distribution tree being used,
   this check is separate from the RPF check, and these two independent
   checks are not as powerful as the single unified check for a valid
   quadruplet.

                  _______
                 /       \
               RB1 ------ o ----- RB2
                 \_______/

   However, this stronger RPF check is not without cost.  In the simple
   case of a multi-access link where each TRILL switch has only one port
   on the link, it merely increases the size of validity entries by
   adding the source SNPA (Outer.MacSA).  However, assume that some
   TRILL switch RB1 has multiple ports attached to a multi-access link.
   In the figure above, RB1 is shown with three ports on the
   multi-access link.  RB1 is permitted to load split multi-destination
   traffic it is sending into the multi-access link across those ports
   (Section 4.4.4 of [RFC6325]).  Assume that RB2 is another TRILL
   switch on the link and RB2 is adjacent to RB1 in the distribution
   tree.  The number of validity quadruplets at RB2 for ingress
   nicknames whose multi-destination traffic would arrive through RB1 is
   multiplied by the number of ports RB1 has on the access link, because
   RB2 has to accept such traffic from any such ports.  Although such
   instances seem to be very rare in practice, the number of ports an
   RBridge has on a link could in principle be tens or even a hundred or
   more ports, vastly increasing the RPF check state at RB2 when this
   stronger RPF check is used.

   Another potential cost of the stronger RPF check is increased
   transient loss of multi-destination TRILL Data packets during a
   topology change.  For TRILL switch D, the new stronger RPF check is
   (tree->A, Outer.MacSA=A, ingress=A, arrival port=if1), while the old
   one was (tree->A, Outer.MacSA=C, ingress=A, arrival port=if1).

Top      ToC       Page 17 
   Suppose that both A and B have switched to the new tree for multicast
   forwarding but D has not updated its RPF check yet; the multicast
   packet will then be dropped at D's input port, because D still
   expects a packet from "Outer.MacSA=C".  But we do not have this
   packet loss issue if the weaker triplet check (tree->A, ingress=A,
   arrival port=if1) is used.  Thus, the stronger check can increase the
   RPF check discard of multi-destination packets during topology
   transients.

   Because of these potential costs, implementation of this stronger
   RPF check is optional.  The TRILL base protocol is updated to provide
   that TRILL switches MUST, for multi-destination packets, either
   implement the RPF and other checks as described in [RFC6325] or
   implement this stronger RPF check as a substitute for the [RFC6325]
   RPF and tree adjacency checks.  There is no problem with a campus
   having a mixture of TRILL switches, some of which implement one of
   these RPF checks and some of which implement the other.

4.  Nickname Selection (Unchanged)

   Nickname selection is covered by Section 3.7.3 of [RFC6325].
   However, the following should be noted:

   1. The second sentence in the second bullet item in Section 3.7.3 of
      [RFC6325] on page 25 is erroneous [Err3002] and is corrected as
      follows:

      o  The occurrence of "IS-IS ID (LAN ID)" is replaced with
         "priority".

      o  The occurrence of "IS-IS System ID" is replaced with "7-byte
         IS-IS ID (LAN ID)".

      The resulting corrected sentence in [RFC6325] reads as follows:

         If RB1 chooses nickname x, and RB1 discovers, through receipt
         of an LSP for RB2 at any later time, that RB2 has also chosen
         x, then the RBridge or pseudonode with the numerically higher
         priority keeps the nickname, or if there is a tie in priority,
         the RBridge with the numerically higher 7-byte IS-IS ID
         (LAN ID) keeps the nickname, and the other RBridge MUST select
         a new nickname.

   2. In examining the link-state database for nickname conflicts,
      nicknames held by IS-IS unreachable TRILL switches MUST be
      ignored, but nicknames held by IS-IS reachable TRILL switches
      MUST NOT be ignored even if they are data unreachable.

Top      ToC       Page 18 
   3. An RBridge may need to select a new nickname, either initially
      because it has none or because of a conflict.  When doing so, the
      RBridge MUST consider as available all nicknames that do not
      appear in its link-state database or that appear to be held by
      IS-IS unreachable TRILL switches; however, it SHOULD give
      preference to selecting new nicknames that do not appear to be
      held by any TRILL switch in the campus, reachable or unreachable,
      so as to minimize conflicts if IS-IS unreachable TRILL switches
      later become reachable.

   4. An RBridge, even after it has acquired a nickname for which there
      appears to be no conflicting claimant, MUST continue to monitor
      for conflicts with the nickname or nicknames it holds.  It does so
      by monitoring any received LSPs that should update its link-state
      database for any occurrence of any of its nicknames held with
      higher priority by some other TRILL switch that is IS-IS reachable
      from it.  If it finds such a conflict, it MUST select a new
      nickname, even when in overloaded state.  (It is possible to
      receive an LSP that should update the link-state database but does
      not do so due to overload.)

   5. In the very unlikely case that an RBridge is unable to obtain a
      nickname because all valid RBridge nicknames (0x0001 through
      0xFFBF inclusive) are in use with higher priority by IS-IS
      reachable TRILL switches, it will be unable to act as an ingress,
      egress, or tree root but will still be able to function as a
      transit TRILL switch.  Although it cannot be a tree root, such an
      RBridge is included in distribution trees computed for the campus
      unless all its neighbors are overloaded.  It would not be possible
      to send a unicast RBridge Channel message specifically to such a
      TRILL switch [RFC7178]; however, it will receive unicast RBridge
      Channel messages sent by a neighbor to the Any-RBridge egress
      nickname and will receive appropriate multi-destination RBridge
      Channel messages.



(page 18 continued on part 2)

Next RFC Part