GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8377

Internet Engineering Task Force (IETF) D. Eastlake 3rd Request for Comments: 8377 M. Zhang Updates: 6325, 7177 Huawei Category: Standards Track A. Banerjee ISSN: 2070-1721 Cisco

                                                             July 2018
       Transparent Interconnection of Lots of Links (TRILL):
                           Multi-Topology

Abstract

 This document specifies extensions to the IETF TRILL (Transparent
 Interconnection of Lots of Links) protocol to support multi-topology
 routing of unicast and multi-destination traffic based on IS-IS
 (Intermediate System to Intermediate System) multi-topology specified
 in RFC 5120.  This document updates RFCs 6325 and 7177.

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 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8377.

Copyright Notice

 Copyright (c) 2018 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
 (https://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.

Eastlake, et al. Standards Track [Page 1] RFC 8377 TRILL: Multi-Topology July 2018

Table of Contents

 1. Introduction ....................................................2
    1.1. Terminology ................................................4
 2. Topologies ......................................................5
    2.2. Links and Multi-Topology ...................................5
    2.3. TRILL Switches and Multi-Topology ..........................6
    2.4. TRILL Data Packets and Multi-Topology ......................6
         2.4.1. Explicit Topology Labeling Support ..................7
         2.4.2. The Explicit Topology Label .........................8
         2.4.3. TRILL Use of the MT Label ...........................8
 3. TRILL Multi-Topology Adjacency and Routing .....................10
    3.1. Adjacency .................................................10
    3.2. TRILL Switch Nicknames ....................................10
    3.3. TRILL Unicast Routing .....................................11
    3.4. TRILL Multi-Destination Routing ...........................11
         3.4.1. Distribution Trees .................................11
         3.4.2. Multi-Access Links .................................13
 4. Mixed Links ....................................................13
 5. Other Multi-Topology Considerations ............................14
    5.1. Address Learning ..........................................14
         5.1.1. Data Plane Learning ................................14
         5.1.2. Multi-Topology ESADI ...............................14
    5.2. Legacy Stubs ..............................................14
    5.3. RBridge Channel Messages ..................................14
    5.4. Implementations Considerations ............................15
 6. Allocation Considerations ......................................15
    6.1. IEEE Registration Authority Considerations ................15
    6.2. IANA Considerations .......................................15
 7. Security Considerations ........................................16
 8. References .....................................................17
    8.1. Normative References ......................................17
    8.2. Informative References ....................................18
 Appendix A. Differences from RFC 5120 .............................19
 Acknowledgements ..................................................19
 Authors' Addresses ................................................20

1. Introduction

 This document specifies extensions to the IETF TRILL (Transparent
 Interconnection of Lots of Links) protocol [RFC6325] [RFC7177]
 [RFC7780] to support multi-topology routing for both unicast and
 multi-destination traffic based on IS-IS (Intermediate System to
 Intermediate System) [IS-IS] multi-topology [RFC5120].
 Implementation and use of multi-topology are optional, and use
 requires configuration.  It is anticipated that not all TRILL
 campuses will need or use multi-topology.

Eastlake, et al. Standards Track [Page 2] RFC 8377 TRILL: Multi-Topology July 2018

 Multi-topology creates different topologies or subsets from a single
 physical TRILL campus topology.  This is different from Data Labels
 (VLANs and Fine-Grained Labels (FGLs) [RFC7172]).  Data Labels
 specify communities of end stations and can be viewed as creating
 virtual topologies of end station connectivity.  However, in a single
 topology TRILL campus, TRILL Data packets can use any part of the
 physical topology of TRILL switches and links between TRILL switches,
 regardless of the Data Label of that packet's payload.  In a multi-
 topology TRILL campus, TRILL data packets in a topology are
 restricted to the TRILL switches and links that are in their
 topology, regardless of the Data Label of their payload.
 The essence of multi-topology behavior is that a multi-topology
 router classifies packets as to the topology within which they should
 be routed and uses logically different routing tables for different
 topologies.  If routers in the network do not agree on the topology
 classification of packets or links, persistent routing loops can
 occur.  It is the responsibility of the network manager to
 consistently configure multi-topology to avoid such routing loops.
 The multi-topology TRILL extensions can be used for a wide variety of
 purposes, such as maintaining separate routing domains for isolated
 multicast or IPv6 islands, routing a class of traffic so that it
 avoids certain TRILL switches that lack some characteristic needed by
 that traffic, or making a class of traffic avoid certain links due to
 security, reliability, or other concerns.
 It is possible for a particular topology to not be fully connected,
 either intentionally or due to node or link failures or incorrect
 configuration.  This results in two or more islands of that topology
 that cannot communicate.  In such a case, end stations connected in
 that topology to different islands will be unable to communicate with
 each other.
 Multi-topology TRILL supports regions of topology-ignorant TRILL
 switches as part of a multi-topology campus; however, such regions
 can only ingress to, egress from, or transit TRILL Data packets in
 the special base topology zero.

Eastlake, et al. Standards Track [Page 3] RFC 8377 TRILL: Multi-Topology July 2018

1.1. Terminology

 The terminology and abbreviations of [RFC6325] are used in this
 document.  Some of these are paraphrased below for convenience.  Some
 additional terms are also listed.
    campus: The name for a TRILL network, like "bridged LAN" is a name
       for a bridged network.  It does not have any academic
       implication.
    DRB: Designated RBridge [RFC7177].
    FGL: Fine-Grained Labeling or Fine-Grained Labeled or Fine-Grained
       Label [RFC7172].  By implication, an "FGL TRILL switch" does
       not support Multi-Topology (MT).
    IS: Intermediate System [IS-IS].
    LSP: Link State PDU (Protocol Data Unit) [IS-IS].  For TRILL, this
       includes Level 1 LSPs and Extended Level 1 Flooding Scope LSPs
       [RFC7780].
    MT: Multi-Topology [RFC5120].
    MT TRILL Switch: A TRILL switch supporting the multi-topology
       feature specified in this document.  An MT TRILL switch MUST
       support FGL in the sense that it MUST be FGL safe [RFC7172].
    RBridge: Routing Bridge; an alternative name for a TRILL switch.
    TRILL: Transparent Interconnection of Lots of Links or Tunneled
       Routing in the Link Layer [RFC6325].
    TRILL Switch: A device implementing the TRILL protocol.  TRILL
       switches are Intermediate Systems (routers) [IS-IS].
    VL: VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172].  By
       implication, a "VL RBridge" or "VL TRILL switch" does not
       support FGL or MT.
 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
 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
 capitals, as shown here.

Eastlake, et al. Standards Track [Page 4] RFC 8377 TRILL: Multi-Topology July 2018

2. Topologies

 In TRILL multi-topology, a topology is a subset of the TRILL switches
 and of the links between TRILL switches in the TRILL campus.  TRILL
 Data packets are constrained to the subset of switches and links
 corresponding to the packet's topology.  TRILL multi-topology is
 based on IS-IS multi-topology [RFC5120].  See Appendix A for
 differences between TRILL multi-topology and [RFC5120].
 The zero topology is special, as described in Section 2.1.  Sections
 2.2, 2.3, and 2.4 discuss the topology of links, TRILL switches, and
 TRILL Data packets, respectively.

2.1. Special Topology Zero

 The zero topology is special as the default base topology.  All TRILL
 switches and links are considered to be in, and MUST support,
 topology zero.  Thus, for example, topology zero can be used for
 general TRILL switch access within a campus for management messages,
 Bidirectional Forwarding Detection (BFD) messages [RFC7175], RBridge
 Channel messages [RFC7178], and the like.

2.2. Links and Multi-Topology

 Multi-topology TRILL switches advertise the topologies for which they
 are willing to send and receive TRILL Data packets on a port by
 listing those topologies in one or more MT TLVs [RFC5120] appearing
 in every TRILL Hello [RFC7177] they send out that port, except that
 they MUST handle topology zero, which it is optional to list.
 A link is usable for TRILL Data packets in non-zero topology T only
 if:
 (1) all TRILL switch ports on the link advertise topology T support
     in their Hellos, and
 (2) if any TRILL switch port on the link requires explicit TRILL Data
     packet topology labeling (see Section 2.4) every other TRILL
     switch port on the link is capable of generating explicit packet
     topology labeling.

Eastlake, et al. Standards Track [Page 5] RFC 8377 TRILL: Multi-Topology July 2018

2.3. TRILL Switches and Multi-Topology

 A TRILL switch advertises the topologies that it supports by listing
 them in one or more MT TLVs [RFC5120] in its LSP, except that it MUST
 support topology zero, which is optional to list.  For robust and
 rapid flooding, MT TLV(s) SHOULD be advertised in core LSP fragment
 zero.
 There is no "MT capability bit".  A TRILL switch advertises that it
 is MT capable by advertising in its LSP support for any topology or
 topologies with the MT TLV, even if it just explicitly advertises
 support for topology zero.

2.4. TRILL Data Packets and Multi-Topology

 The topology of a TRILL Data packet is commonly determined from
 either (1) some field or fields present in the packet itself or (2)
 the port on which the packet was received; however, optional explicit
 topology labeling of TRILL Data packets is also proved.  This can be
 included in the data labeling area of TRILL Data packets as specified
 below.
 Examples of fields that might be used to determine topology are
 values or ranges of values of the payload VLAN or FGL [RFC7172],
 packet priority, IP version (IPv6 versus IPv4) or IP protocol,
 Ethertype, unicast versus multi-destination payload, IP
 Differentiated Services Code Point (DSCP) bits, or the like.
 Multi-topology does not apply to TRILL IS-IS packets or to link level
 control frames.  Those messages are link local and can be thought of
 as being above all topologies.  Multi-topology only applies to TRILL
 Data packets.

Eastlake, et al. Standards Track [Page 6] RFC 8377 TRILL: Multi-Topology July 2018

2.4.1. Explicit Topology Labeling Support

 Support of the topology label is optional.  Support could depend on
 port hardware and is indicated by a 2-bit capability field in the
 Port TRILL Version sub-TLV [RFC7176] appearing in the Port
 Capabilities TLV in Hellos.  If there is no Port TRILL Capabilities
 sub-TLV in a Hello, then it is assumed that explicit topology
 labeling is not supported on that port.  See the table below for the
 meaning of values of the Explicit Topology capability field:
    Value   Meaning
    -----   -------
     0       No support.  Cannot send TRILL Data packets with an
             explicit topology label and will likely treat as
             erroneous and discard any TRILL Data packet received with
             a topology label.  Such a port is assumed to have the
             ability and configuration to correctly classify TRILL
             Data packets into all topologies for which it is
             advertising support in its Hellos, either by examining
             those packets or because they are arriving at that port.
     1       Capable of inserting an explicit topology label in TRILL
             Data packets sent and tolerant of such labels in received
             TRILL Data packets.  Such a port is capable, for all of
             the topologies it supports, of determining TRILL Data
             packet topology without an explicit label.  Thus, it does
             not require such a label in received TRILL Data packets.
             On receiving a packet whose explicit topology label
             differs from the port's topology determination for that
             packet, the TRILL switch MUST discard the packet.
  2 & 3      Require an explicit topology label in received TRILL Data
             packets except for topology zero.  Any TRILL Data packets
             received without such a label are classified as being in
             topology zero.   Also capable of inserting an explicit
             topology label in TRILL Data packets sent.  (Values 2 and
             3 are treated the same, which is the same as saying that
             if the 2 bit is on, the 1 bit is ignored.)
 In a Hello on Port P, a TRILL switch advertising support for topology
 T but not advertising that it requires explicit topology labeling is
 assumed to have the ability and configuration to correctly classify
 TRILL Data packets into topology T by examination of those TRILL Data
 packets and/or by using the fact that they are arriving at port P.
 When a TRILL switch transmits a TRILL Data packet onto a link, if any
 other TRILL switch on that link requires explicit topology labeling,
 an explicit topology label MUST be included unless the TRILL Data

Eastlake, et al. Standards Track [Page 7] RFC 8377 TRILL: Multi-Topology July 2018

 packet is in topology zero, in which case, an explicit topology label
 MAY be included.  If a topology label is not so required, but all
 other TRILL switches on that link support explicit topology labeling,
 then such a label MAY be included.

2.4.2. The Explicit Topology Label

 This section specifies the explicit topology label.  Its use by TRILL
 is specified in Section 2.4.3.  This label may be used by other
 technologies besides TRILL.  The MT Label is structured as follows:
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     MT Ethertype 0x9A22       | V | R |         MT-ID         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          Figure 1: MT Label
 Where the fields are as follows:
 MT Ethertype: The MT Label Ethertype (see Section 6.1).
 V: The version number of the MT Label.  This document specifies
    version zero.
 R: A 2-bit reserved field that MUST be sent as zero and ignored on
    receipt.
 MT-ID: The 12-bit topology using the topology number space of the MT
    TLV [RFC5120].

2.4.3. TRILL Use of the MT Label

 With the addition of the version zero MT Label, the four standardized
 content varieties for the TRILL Data packet data labeling area (the
 area after the Inner.MacSA -- or Flag Word if the Flag Word is
 present [RFC7780] -- and before the payload) are as show below.
 TRILL Data packets received with any other data labeling are
 discarded.  {PRI, D} is a 3-bit priority and a drop eligibility
 indicator bit [RFC7780].
 All MT TRILL switches MUST support FGL, in the sense of being FGL
 safe [RFC7172]; thus, they MUST support all four data labeling area
 contents shown below.  (This requirement is imposed, rather than
 having FGL support and MT support be independent, to reduce the
 number of variations in RBridges and simplify testing.)

Eastlake, et al. Standards Track [Page 8] RFC 8377 TRILL: Multi-Topology July 2018

 1. C-VLAN [RFC6325]
                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  C-VLAN = 0x8100              | PRI |D|  VLAN ID              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 2. FGL [RFC7172]
                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  FGL = 0x893B                 | PRI |D|  FGL High Part        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  FGL = 0x893B                 | PRI |D|  FGL Low Part         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 3. MT C-VLAN [RFC8377]
                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MT Ethertype = 0x9A22        | 0 | R |  MT-ID                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  C-VLAN = 0x8100              | PRI |D|  VLAN ID              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4. MT FGL [RFC8377] [RFC7172]
                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  MT Ethertype = 0x9A22        | 0 | R |  MT-ID                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  FGL = 0x893B                 | PRI |D|  FGL High Part        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  FGL = 0x893B                 | PRI |D|  FGL Low Part         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Inclusion or use of S-VLAN or further stacked tags are beyond the
 scope of this document, but, as stated in [RFC6325], are obvious
 extensions.

Eastlake, et al. Standards Track [Page 9] RFC 8377 TRILL: Multi-Topology July 2018

3. TRILL Multi-Topology Adjacency and Routing

 Routing calculations in IS-IS are based on adjacency.  Section 3.1
 specifies multi-topology TRILL adjacency.  Section 3.2 describes the
 handling of nicknames.  Sections 3.3 and 3.4 specify how unicast and
 multi-destination TRILL multi-topology routing differ from the TRILL
 base protocol routing.

3.1. Adjacency

 There is no change in the determination or announcement of adjacency
 for topology zero, which is as specified in [RFC7177].  When a
 topology zero adjacency reaches the Report state, as specified in
 [RFC7177], the adjacency is announced in core LSPs using the Extended
 Intermediate System Reachability TLV (#22).  This will be compatible
 with any legacy topology-ignorant RBridges that might not support E-
 L1FS FS-LSPs [RFC7780].
 Adjacency is announced for non-zero topologies in LSPs using the MT
 Reachable Intermediate Systems TLV (#222) as specified in [RFC5120].
 A TRILL switch reports adjacency for non-zero topology T if and only
 if that adjacency is in the Report state [RFC7177] and the two
 conditions listed in Section 2.2 are true, namely:
 1. All the ports on the link are announcing support of topology T.
 2. If any port announces that it requires explicit topology labeling
    (Explicit Topology capability field value 2 or 3), all other ports
    advertise that they are capable of producing such labeling
    (Explicit Topology capability field value of 1, 2, or 3).

3.2. TRILL Switch Nicknames

 TRILL switches are usually identified within the TRILL protocol (for
 example, in the TRILL Header) by nicknames [RFC6325] [RFC7780].  Such
 nicknames can be viewed as simply 16-bit abbreviation for a TRILL
 switch's (or pseudo-node's) 7-byte IS-IS System ID.  A TRILL switch
 or pseudo-node can have more than one nickname, each of which
 identifies it.
 Nicknames are common across all topologies, just as IS-IS System IDs
 are.  Nicknames are determined as specified in [RFC6325] and
 [RFC7780] using only the Nickname sub-TLVs appearing in Router
 Capabilities TLVs (#242) advertised by TRILL switches.  In
 particular, the nickname allocation algorithm ignores Nickname sub-
 TLVs that appear in MT Router Capability TLVs (#144).  (However,

Eastlake, et al. Standards Track [Page 10] RFC 8377 TRILL: Multi-Topology July 2018

 Nickname sub-TLVs that appear in MT Router Capability TLVs with a
 non-zero topology do affect the choice of distribution tree roots as
 described in Section 3.4.1.)
 To minimize transient inconsistencies, all Nickname sub-TLVs
 advertised by a TRILL switch for a particular nickname, whether in
 Router Capability or MT Router Capability TLVs, SHOULD appear in the
 same LSP PDU.  If that is not the case, then all LSP PDUs in which
 they do occur SHOULD be flooded as an atomic action.

3.3. TRILL Unicast Routing

 TRILL Data packets being TRILL unicast (those with TRILL Header M bit
 = 0) are routed based on the egress nickname using logically separate
 forwarding tables per topology T, where each such table has been
 calculated based on least cost routing within T: that is, only using
 links and nodes that support T.  Thus, the next hop when forwarding
 TRILL Data packets is determined by a lookup logically based on
 {topology, egress nickname}.

3.4. TRILL Multi-Destination Routing

 TRILL sends multi-destination data packets (those packets with TRILL
 Header M bit = 1) over a distribution tree.  Trees are designated by
 nicknames that appear in the "egress nickname" field of multi-
 destination TRILL Data packet TRILL Headers.  To constrain multi-
 destination packets to a topology T and still distribute them
 properly requires the use of a distribution tree constrained to T.
 Handling such TRILL Data packets and distribution trees in TRILL MT
 is as described in the subsections below.

3.4.1. Distribution Trees

 General provisions for distribution trees and how those trees are
 determined are as specified in [RFC6325], [RFC7172], and [RFC7780].
 The distribution trees for topology zero are determined as specified
 in those references and are the same as they would be with topology-
 ignorant TRILL switches.
 The TRILL distribution tree construction and packet handling for some
 non-zero topology T are determined as specified in [RFC6325],
 [RFC7172], and [RFC7780] with the following changes:
    o  As specified in [RFC5120], only links usable with topology T
       TRILL Data packets are considered when building a distribution
       tree for topology T.  As a result, such trees are automatically
       limited to and separately span every internally connected

Eastlake, et al. Standards Track [Page 11] RFC 8377 TRILL: Multi-Topology July 2018

       island of topology T.  In other words, if non-zero topology T
       consists of disjoint islands, each distribution tree
       construction for topology T is local to one such island.
    o  Only the Nickname sub-TLV, Trees sub-TLV, Tree Identifiers sub-
       TLV, and Trees Used sub-TLV occurring in an MT Router
       Capabilities TLV (#144) specifying topology T are used in
       determining the tree root(s), if any, for a connected area of
       non-zero topology T.
       +  There may be non-zero topologies with no multi-destination
          traffic or, as described in [RFC5120], even topologies with
          no traffic at all.  For example, if only known destination
          unicast IPv6 TRILL Data packets were in topology T and all
          multi-destination IPv6 TRILL Data packets were in some other
          topology, there would be no need for a distribution tree for
          topology T.  For this reason, a Number of Trees to Compute
          field value of zero in the Trees sub-TLV for the TRILL
          switch holding the highest priority to be a tree root for a
          non-zero topology T is honored and causes no distribution
          trees to be calculated for non-zero topology T.  This is
          different from the base topology zero where, as specified in
          [RFC6325], a zero Number of Trees to Compute field value
          causes one tree to be computed.
    o  Nicknames are allocated as described in Section 3.2.  If a
       TRILL switch advertising that it provides topology T service
       holds nickname N, the priority of N to be a tree root is given
       by the tree root priority field of the Nickname sub-TLV that
       has N in its nickname field and occurs in a topology T MT
       Router Capabilities TLV advertised by that TRILL switch.  If no
       such Nickname sub-TLV can be found, the priority of N to be a
       tree root is the default for an FGL TRILL switch as specified
       in [RFC7172].
       +  There could be multiple topology T Nickname sub-TLVs for N
          being advertised for a particular RBridge or pseudo-node,
          due to transient conditions or errors.  In that case, any
          advertised in a core LSP PDU are preferred to those
          advertised in an E-L1FS FS-LSP PDU.  Within those
          categories, the one in the lowest numbered fragment is used
          and if there are multiple in that fragment, the one with the
          smallest offset from the beginning of the PDU is used.
    o  Tree pruning for topology T uses only the Interested VLANs sub-
       TLVs and Interested Labels sub-TLVs [RFC7176] advertised in MT
       Router Capabilities TLVs for topology T.

Eastlake, et al. Standards Track [Page 12] RFC 8377 TRILL: Multi-Topology July 2018

 An MT TRILL switch MUST have logically separate routing tables per
 topology for the forwarding of multi-destination traffic.

3.4.2. Multi-Access Links

 Multi-destination TRILL Data packets are forwarded on broadcast
 (multi-access) links in such a way as to be received by all other
 TRILL switch ports on the link.  For example, on Ethernet links they
 are sent with a multicast Outer.MacDA [RFC6325].  Care must be taken
 that a TRILL Data packet in a non-zero topology is only forwarded by
 an MT TRILL switch.
 For this reason, a non-zero topology TRILL Data packet MUST NOT be
 forwarded onto a link unless the link meets the requirements
 specified in Section 2.2 for use in that topology even if there are
 one or more MT TRILL switch ports on the link.

4. Mixed Links

 There might be any combination of MT, FGL, or even VL TRILL switches
 [RFC7172] on a link.  DRB (Designated RBridge) election and Forwarder
 appointment on the link work as previously specified in [RFC8139] and
 [RFC7177].  It is up to the network manager to configure and manage
 the TRILL switches on a link so that the desired switch is DRB and
 the desired switch is the Appointed Forwarder for the appropriate
 VLANs.
 Frames ingressed by MT TRILL switches can potentially be in any
 topology recognized by the switch and permitted on the ingress port.
 Frames ingressed by VL or FGL TRILL switches can only be in the base
 zero topology.  Because FGL and VL TRILL switches do not understand
 topologies, all occurrences of the following sub-TLVs MUST occur only
 in MT Port Capability TLVs with a zero MT-ID.  Any occurrence of
 these sub-TLVs in an MT Port Capability TLV with a nonzero MT-ID is
 ignored.
    Special VLANs and Flags Sub-TLV
    Enabled-VLANs Sub-TLV
    Appointed Forwarders Sub-TLV
    VLANs Appointed Sub-TLV
 Native frames cannot be explicitly labeled (see Section 2.4) as to
 their topology.

Eastlake, et al. Standards Track [Page 13] RFC 8377 TRILL: Multi-Topology July 2018

5. Other Multi-Topology Considerations

5.1. Address Learning

 The learning of end station Media Access Control (MAC) addresses is
 per topology as well as per label (VLAN or FGL).  The same MAC
 address can occur within a TRILL campus for different end stations
 that differ only in topology without confusion.

5.1.1. Data Plane Learning

 End station MAC addresses learned from ingressing native frames or
 egressing TRILL Data packets are, for MT TRILL switches, qualified by
 topology.  That is, either the topology into which that TRILL switch
 classified the ingressed native frame or the topology that the
 egressed TRILL Data frame was in.

5.1.2. Multi-Topology ESADI

 In an MT TRILL switch, End Station Address Distribution Information
 (ESADI) [RFC7357] operates per label (VLAN or FGL) per topology.
 Since ESADI messages appear, to transit TRILL switches, like normal
 multi-destination TRILL Data packets, ESADI link state databases and
 ESADI protocol operation are per topology as well as per label and
 local to each area of multi-destination TRILL data connectivity for
 that topology.

5.2. Legacy Stubs

 Areas of topology-ignorant TRILL switches can be connected to and
 become part of an MT TRILL campus but will only be able to ingress
 to, transit, or egress from topology zero TRILL Data packets.

5.3. RBridge Channel Messages

 RBridge Channel messages [RFC7178], such as BFD over TRILL [RFC7175]
 appear, to transit TRILL switches, like normal multi-destination
 TRILL Data packets.  Thus, they have a topology and, if that topology
 is non-zero, are constrained by topology like other TRILL Data
 packets.  Generally, when sent for network management purposes, they
 are sent in topology zero to avoid such constraint.

Eastlake, et al. Standards Track [Page 14] RFC 8377 TRILL: Multi-Topology July 2018

5.4. Implementations Considerations

 MT is an optional TRILL switch capability.
 Experience with the actual deployment of Layer 3 IS-IS MT [RFC5120]
 indicates that a single router handling more than eight topologies is
 rare.  There may be many more than eight distinct topologies in a
 routed area, such as a TRILL campus; in that case, many of these
 topologies will be handled by disjoint sets of routers and/or links.
 Based on this deployment experience, a TRILL switch capable of
 handling eight or more topologies can be considered a full
 implementation while a TRILL switch capable of handling four
 topologies can be considered a minimal implementation but still
 useful under some circumstances.

6. Allocation Considerations

 IEEE Registration Authority and IANA considerations are given below.

6.1. IEEE Registration Authority Considerations

 The IEEE Registration Authority has allocated Ethertype 0x9A22 for
 the MT Label (see Section 2.4).

6.2. IANA Considerations

 IANA has assigned a field of two adjacent bits (14-15) of the
 Capabilities bits of the Port TRILL Version Sub-TLV for the Explicit
 Topology capability field and updated the "PORT-TRILL-VER Sub-TLV
 Capability Flags" registry as follows.
     Bit     Description                 Reference
    -----   -------------------------    ---------------
    14-15   Topology labeling support.   [RFC8377]

Eastlake, et al. Standards Track [Page 15] RFC 8377 TRILL: Multi-Topology July 2018

 IANA has created the informational "TRILL Ethertypes" subregistry in
 the "Transparent Interconnection of Lots of Links (TRILL) Parameters"
 registry.
 Name: TRILL Ethertypes
 Registration Procedure(s): Ethertypes are assigned by the IEEE
    Registration Authority.  Updates to this registry are coordinated
    with the designated expert.
 Reference: [RFC8377]
 Note: This registry provides centralized documentation of
    Ethertypes that were assigned by the IEEE for initial use
    with TRILL.  In some cases, particularly L2-IS-IS and MT,
    they may be used with other protocols.
 Value    Mnemonic    Explanation           Reference
 ------   --------   ---------------------  ---------
 0x22F3    TRILL     TRILL data             [RFC6325]
 0x22F4    L2-IS-IS  IS-IS                  [RFC6325]
 0x893B    FGL       Fine Grained Labeling  [RFC7172]
 0x8946    -         TRILL RBridge Channel  [RFC7178]
 0x9A22    MT        Multi-Topology         [RFC8377]

7. Security Considerations

 Multiple topologies are sometimes used for the isolation or security
 of traffic.  For example, if some links were more likely than others
 to be subject to adversarial observation, it might be desirable to
 classify certain sensitive traffic in a topology that excluded those
 links.
 Delivery of data originating in one topology outside of that topology
 is generally a security policy violation to be avoided at all
 reasonable costs.  Using IS-IS security [RFC5310] on all IS-IS PDUs
 and link security appropriate to the link technology on all links
 involved, particularly those between RBridges, supports the avoidance
 of such violations.
 For general TRILL security considerations, see [RFC6325].

Eastlake, et al. Standards Track [Page 16] RFC 8377 TRILL: Multi-Topology July 2018

8. References

8.1. Normative References

 [IS-IS]    ISO/IEC 10589:2002, Second Edition, "Intermediate System
            to Intermediate System Intra-Domain Routeing Exchange
            Protocol for use in Conjunction with the Protocol for
            Providing the Connectionless-mode Network Service (ISO
            8473)", 2002.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <https://www.rfc-editor.org/info/rfc2119>.
 [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
            Topology (MT) Routing in Intermediate System to
            Intermediate Systems (IS-ISs)", RFC 5120,
            DOI 10.17487/RFC5120, February 2008,
            <https://www.rfc-editor.org/info/rfc5120>.
 [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, <https://www.rfc-editor.org/info/rfc5310>.
 [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,
            <https://www.rfc-editor.org/info/rfc6325>.
 [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,
            <https://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,
            <https://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, <https://www.rfc-editor.org/info/rfc7177>.

Eastlake, et al. Standards Track [Page 17] RFC 8377 TRILL: Multi-Topology July 2018

 [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,
            <https://www.rfc-editor.org/info/rfc7178>.
 [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, <https://www.rfc-editor.org/info/rfc7357>.
 [RFC7780]  Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
            Ghanwani, A., and S. Gupta, "Transparent Interconnection
            of Lots of Links (TRILL): Clarifications, Corrections, and
            Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
            <https://www.rfc-editor.org/info/rfc7780>.
 [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
            2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
            May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References

 [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, <https://www.rfc-
            editor.org/info/rfc7175>.
 [RFC8139]  Eastlake 3rd, D., Li, Y., Umair, M., Banerjee, A., and F.
            Hu, "Transparent Interconnection of Lots of Links (TRILL):
            Appointed Forwarders", RFC 8139, DOI 10.17487/RFC8139,
            June 2017, <https://www.rfc-editor.org/info/rfc8139>.

Eastlake, et al. Standards Track [Page 18] RFC 8377 TRILL: Multi-Topology July 2018

Appendix A. Differences from RFC 5120

 TRILL multi-topology, as specified in this document, differs from RFC
 5120 as follows:
 1. [RFC5120] provides for unicast multi-topology.  This document
    extends that to cover multi-destination TRILL data distribution
    (see Section 3.4).
 2. [RFC5120] assumes the topology of data packets is always
    determined implicitly, that is, based on the port over which the
    packets are received and/or preexisting fields within the packet.
    This document supports such implicit determination, but it extends
    this by providing for optional explicit topology labeling of data
    packets (see Section 2.4).
 3. [RFC5120] makes support of the default topology zero optional for
    MT routers and links.  For simplicity and ease in network
    management, this document requires all TRILL switches and links
    between TRILL switches to support topology zero (see Section 2.1).

Acknowledgements

 The comments and contributions of the following are gratefully
 acknowledged:
 Vishwas Manral and Martin Vigoureux

Eastlake, et al. Standards Track [Page 19] RFC 8377 TRILL: Multi-Topology July 2018

Authors' Addresses

 Donald Eastlake 3rd
 Huawei Technologies
 1424 Pro Shop Court
 Davenport, FL 33896
 United States of America
 Phone: +1-508-333-2270
 Email: d3e3e3@gmail.com
 Mingui Zhang
 Huawei Technologies Co., Ltd.
 HuaWei Building, No.3 Xinxi Rd., Shang-Di
 Information Industry Base, Hai-Dian District,
 Beijing, 100085
 China
 Email: zhangmingui@huawei.com
 Ayan Banerjee
 Cisco
 170 W. Tasman Drive
 San Jose, CA 95134
 United States of America
 Email: ayabaner@cisco.com

Eastlake, et al. Standards Track [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8377.txt · Last modified: 2018/07/31 22:55 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki