GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8384

Internet Engineering Task Force (IETF) R. Perlman Request for Comments: 8384 Dell EMC Category: Standards Track F. Hu ISSN: 2070-1721 ZTE Corporation

                                                       D. Eastlake 3rd
                                                               T. Liao
                                                   Huawei Technologies
                                                             July 2018
Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes

Abstract

 This document addresses the problem of the size and freshness of the
 endnode learning table in edge Routing Bridges (RBridges), by
 allowing endnodes to volunteer for endnode learning and
 encapsulation/decapsulation.  Such an endnode is known as a "Smart
 Endnode".  Only the attached edge RBridge can distinguish a "Smart
 Endnode" from a "normal endnode".  The Smart Endnode uses the
 nickname of the attached edge RBridge, so this solution does not
 consume extra nicknames.  The solution also enables endnodes that are
 Fine-Grained Label (FGL) aware.

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/rfc8384.

Perlman, et al. Standards Track [Page 1] RFC 8384 TRILL Smart Endnodes July 2018

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.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
 2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
   2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
 3.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   4
 4.  Smart-Hello Mechanism between Smart Endnode and RBridge . . .   6
   4.1.  Smart-Hello Encapsulation . . . . . . . . . . . . . . . .   6
   4.2.  Edge RBridge's Smart-Hello  . . . . . . . . . . . . . . .   8
   4.3.  Smart Endnode's Smart-Hello . . . . . . . . . . . . . . .   8
 5.  Processing Data Packets . . . . . . . . . . . . . . . . . . .  10
   5.1.  Data-Packet Processing for Smart Endnodes . . . . . . . .  10
   5.2.  Data-Packet Processing for Edge RBridge . . . . . . . . .  11
 6.  Multihoming Scenario  . . . . . . . . . . . . . . . . . . . .  12
 7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
 8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
 9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
   9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
   9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
 Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
 Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Perlman, et al. Standards Track [Page 2] RFC 8384 TRILL Smart Endnodes July 2018

1. Introduction

 The IETF TRILL (Transparent Interconnection of Lots of Links)
 protocol [RFC6325] [RFC7780] provides optimal pair-wise data frame
 forwarding without configuration, safe forwarding even during periods
 of temporary loops, and support for multipathing of both unicast and
 multicast traffic.  TRILL accomplishes this by using IS-IS [IS-IS]
 [RFC7176] link state routing and encapsulating traffic using a header
 that includes a hop count.  Devices that implement TRILL are called
 "RBridges" (Routing Bridges) or "TRILL Switches".
 An RBridge that attaches to endnodes is called an "edge RBridge" or
 "edge TRILL Switch", whereas one that exclusively forwards
 encapsulated frames is known as a "transit RBridge" or "transit TRILL
 Switch".  An edge RBridge traditionally is the one that encapsulates
 a native Ethernet frame with a TRILL header or that receives a TRILL-
 encapsulated packet and decapsulates the TRILL header.  To
 encapsulate efficiently, the edge RBridge must keep an "endnode
 table" consisting of (Media Access Control (MAC), Data Label, TRILL
 egress switch nickname) sets, for those remote MAC addresses in Data
 Labels currently communicating with endnodes to which the edge
 RBridge is attached.
 These table entries might be configured, received from End Station
 Address Distribution Information (ESADI) [RFC7357], looked up in a
 directory [RFC7067], or learned from decapsulating received traffic.
 If the edge RBridge has attached endnodes communicating with many
 remote endnodes, this table could become very large.  Also, if a MAC
 address / Data Label pair in the table have moved to a different
 remote TRILL switch, it might be difficult for the edge RBridge to
 notice this quickly; and because the edge RBridge is encapsulating to
 the incorrect egress RBridge, the traffic will get lost.

2. Conventions Used in This Document

2.1. Terminology

 BUM: Broadcast, Unknown unicast, and Multicast.
 Edge RBridge: An RBridge providing endnode service on at least one of
 its ports.  It is also called an edge TRILL Switch.
 Data Label: VLAN or FGL.
 DRB: Designated RBridge [RFC6325].
 ESADI: End Station Address Distribution Information [RFC7357].

Perlman, et al. Standards Track [Page 3] RFC 8384 TRILL Smart Endnodes July 2018

 FGL: Fine-Grained Label [RFC7172].
 IS-IS: Intermediate System to Intermediate System [IS-IS].
 LSP: Link State PDU.
 PDU: Protocol Data Unit.
 RBridge: Routing Bridge, an alternative name for a TRILL switch.
 Smart Endnode: An endnode that has the capability specified in this
 document including learning and maintaining (MAC, Data Label,
 nickname) entries and encapsulating/decapsulating TRILL frame.
 Transit RBridge: An RBridge that exclusively forwards encapsulated
 frames.  It is also called a transit TRILL Switch.
 TRILL: Transparent Interconnection of Lots of Links
 [RFC6325][RFC7780].
 TRILL ES-IS: TRILL End System to Intermediate System, is a variation
 of TRILL IS-IS designed to operate on a TRILL link among and between
 one or more TRILL switches and end stations on that link [RFC8171].
 TRILL Switch: a device that implements the TRILL protocol; an
 alternative term for an RBridge.

2.2. Requirements Language

 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.

3. Solution Overview

 The Smart Endnode solution defined in this document addresses the
 problem of the size and freshness of the endnode learning table in
 edge RBridges.  An endnode E, attached to an edge RBridge R, tells R
 that E would like to be a "Smart Endnode", which means that E will
 encapsulate and decapsulate the TRILL frame, using R's nickname.
 Because E uses R's nickname, this solution does not consume extra
 nicknames.

Perlman, et al. Standards Track [Page 4] RFC 8384 TRILL Smart Endnodes July 2018

 Take Figure 1 as the example Smart Endnode scenario: RB1, RB2, and
 RB3 are the RBridges in the TRILL domain and SE1 and SE2 are the
 Smart Endnodes that can encapsulate and decapsulate the TRILL
 packets.  RB1 is the edge RB to which SE1 and SE2 have attached.  RB1
 assigns one of its nicknames to be used by SE1 and SE2.
 Each Smart Endnode, SE1 and SE2, uses RB1's nickname when
 encapsulating and maintains an endnode table of (MAC, Data Label,
 TRILL egress switch nickname) for remote endnodes that it (SE1 or
 SE2) is corresponding with.  RB1 does not decapsulate packets
 destined for SE1 or SE2 and does not learn (MAC, Data Label, TRILL
 egress switch nickname) for endnodes corresponding with SE1 or SE2,
 but RB1 does decapsulate and does learn (MAC, Data Label, TRILL
 egress switch nickname) for any endnodes attached to RB1 that have
 not declared themselves to be Smart Endnodes.
 Just as an RBridge learns and times out (MAC, Data Label, TRILL
 egress switch nickname), Smart Endnodes SE1 and SE2 also learn and
 time out endnode entries.  However, SE1 and SE2 might also determine,
 through ICMP messages or other techniques that an endnode entry is
 not successfully reaching the destination endnode, and it can be
 deleted, even if the entry has not timed out.
 If SE1 wishes to correspond with destination MAC D, and no endnode
 entry exists, SE1 will encapsulate the packet as an unknown
 destination, or consult a directory [RFC7067] (just as an RBridge
 would do if there was no endnode entry).

+———-+ |SE1(Smart | |Endnode1) | \ +——————————+ +———-+ \ / \

               \  /+------+   +------+    +-----+    \   +-----------+
               /-+-| RB 1 |---|  RB2 |----| RB3 |-----+--|Endnode3   |
              /  | +------+   +------+    +-----+     |  |MAC=D      |

+———-+ / \ / +———–+ |SE2(Smart | \ / | Endnode2)| +——————————+ +———-+

                   Figure 1: Smart Endnode Scenario

Perlman, et al. Standards Track [Page 5] RFC 8384 TRILL Smart Endnodes July 2018

 The mechanism in this document is that the Smart Endnode SE1 issues a
 Smart-Hello, indicating SE1's desire to act as a Smart Endnode,
 together with the set of MAC addresses and Data Labels that SE1 owns.
 The Smart-Hello is used to announce the Smart Endnode capability and
 parameters (such as MAC address, Data Label, etc.).  The Smart-Hello
 is a type of TRILL ES-IS PDU, which is specified in Section 5 of
 [RFC8171].  The detailed content for a Smart Endnode's Smart-Hello is
 defined in Section 4.
 If RB1 supports having a Smart Endnode neighbor, it also sends Smart-
 Hellos.  The Smart Endnode learns from RB1's Smart-Hellos what RB1's
 nickname is and which trees RB1 can use when RB1 ingresses multi-
 destination frames.  Although Smart Endnode SE1 transmits Smart-
 Hellos, it does not transmit or receive Link State PDUs (LSPs) or
 Extended Level 1 Flooding Scope (E-L1FS) FS LSPs [RFC7780].
 Since a Smart Endnode can encapsulate TRILL Data packets, it can
 cause the Inner.Label to be a Fine-Grained Label [RFC7172]; thus,
 this method supports FGL-aware endnodes.  When and how a Smart
 Endnode decides to use the FGL instead of VLANs to encapsulate the
 TRILL Data packet is out of scope in this document.

4. Smart-Hello Mechanism between Smart Endnode and RBridge

 The subsections below describe Smart-Hello messages.

4.1. Smart-Hello Encapsulation

 Although a Smart Endnode is not an RBridge, does not send LSPs or
 maintain a copy of the link state database, and does not perform
 routing calculations, it is required to have a "Hello" mechanism (1)
 to announce to edge RBridges that it is a Smart Endnode and (2) to
 tell them what MAC addresses it is handling in what Data Labels.
 Similarly, an edge RBridge that supports Smart Endnodes needs a
 message (1) to announce that support, (2) to inform Smart Endnodes
 what nickname to use for ingress and what nickname(s) can be used as
 egress nickname in a multi-destination TRILL Data packet, and (3) the
 list of Smart Endnodes it knows about on that link.
 The messages sent by Smart Endnodes and by edge RBridges that support
 Smart Endnodes are called "Smart-Hellos".  The Smart-Hello is a type
 of TRILL ES-IS PDU, which is specified in [RFC8171].

Perlman, et al. Standards Track [Page 6] RFC 8384 TRILL Smart Endnodes July 2018

 The Smart-Hello Payload, both for Smart-Hellos sent by Smart Endnodes
 and for Smart-Hellos sent by edge RBridges, consists of TRILL IS-IS
 TLVs as described in the following two subsections.  The non-extended
 format is used so TLVs, sub-TLVs, and APPsub-TLVs have an 8-bit size
 and type field.  Both types of Smart-Hellos MUST include a Smart-
 Parameters APPsub-TLV as follows inside a TRILL GENINFO TLV:
               +-+-+-+-+-+-+-+-+-
               |Smart-Parameters|                 (1 byte)
               +-+-+-+-+-+-+-+-+-
               |    Length      |                 (1 byte)
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |        Holding Time           |  (2 bytes)
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |             Flags             |  (2 bytes)
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 2: Smart-Parameters APPsub-TLV
 o  Type: APPsub-TLV type Smart-Parameters, value is 22.
 o  Length: 4.
 o  Holding Time: A time in seconds as an unsigned integer.  It has
    the same meaning as the Holding Time field in IS-IS Hellos
    [IS-IS].  A Smart Endnode and an edge RBridge supporting Smart
    Endnodes MUST send a Smart-Hello at least three times during their
    Holding Time.  If no Smart-Hellos are received from a Smart
    Endnode or edge RBridge within the most recent Holding Time it
    sent, it is assumed that it is no longer available.
 o  Flags: At this time, all of the Flags are reserved and MUST be
    sent as zero and ignored on receipt.
 o  If more than one Smart-Parameters APPsub-TLV appears in a Smart-
    Hello, the first one is used and any following ones are ignored.
    If no Smart-Parameters APPsub-TLVs appear in a Smart-Hello, that
    Smart-Hello is ignored.

Perlman, et al. Standards Track [Page 7] RFC 8384 TRILL Smart Endnodes July 2018

4.2. Edge RBridge's Smart-Hello

 The edge RBridge's Smart-Hello contains the following information in
 addition to the Smart-Parameters APPsub-TLV:
 o  RBridge's nickname.  The nickname sub-TLV, specified in
    Section 2.3.2 in [RFC7176], is reused here carried inside a TLV
    242 (IS-IS router capability) in a Smart-Hello frame.  If more
    than one nickname appears in the Smart-Hello, the first one is
    used and the following ones are ignored.
 o  Trees that RB1 can use when ingressing multi-destination frames.
    The Tree Identifiers sub-TLV, specified in Section 2.3.4 in
    [RFC7176], is reused here.
 o  Smart Endnode neighbor list.  The TRILL Neighbor TLV, specified in
    section 2.5 in [RFC7176], is reused for this purpose.
 o  An Authentication TLV MAY also be included.

4.3. Smart Endnode's Smart-Hello

 A new APPsub-TLV (Smart-MAC TLV) for use by Smart Endnodes is as
 defined below.  In addition, there will be a Smart-Parameters APPsub-
 TLV and there MAY be an Authentication TLV in a Smart Endnode Smart-
 Hello.
 If there are several VLANs/FGL Data Labels for that Smart Endnode,
 the Smart-MAC APPsub-TLV is included several times in the Smart
 Endnode's Smart-Hello.  This APPsub-TLV appears inside a TRILL
 GENINFO TLV.

Perlman, et al. Standards Track [Page 8] RFC 8384 TRILL Smart Endnodes July 2018

  +-+-+-+-+-+-+-+-+
  |Type=Smart-MAC |                          (1 byte)
  +-+-+-+-+-+-+-+-+
  |   Length      |                          (1 byte)
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |F|M|   RSV     |  VLAN/FGL Data Label  |  (4 bytes)
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          MAC (1)       (6 bytes)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      .................                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          MAC (N)       (6 bytes)                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Figure 3: Smart-MAC APPsub-TLV
 o  Type: TRILL APPsub-TLV Type Smart-MAC, value is 23.
 o  Length: Total number of bytes contained in the value field of the
    TLV, that is, the sum of the length of the F/M/RSV/FGL Data Label
    fields and six times the number of MAC addresses present.  So, if
    there are n MAC addresses, this is 4+6*n.
 o  F: 1 bit.  If it is set to 1, it indicates that the endnode
    supports FGL Data Labels [RFC7172], and that this Smart-MAC
    APPsub-TLV has an FGL in the following VLAN/FGL field.  Otherwise,
    the VLAN/FGL Data Label field is a VLAN ID.  (See below for the
    format of the VLAN/FGL Data Label field).
 o  M: 1 bit.  If it is set to 1, it indicates multihoming (see
    Section 6).  If it is set to 0, it indicates that the Smart
    Endnodes are not using multihoming.
 o  RSV: 6 bits; reserved for the future use.
 o  VLAN/FGL Data Label: 24 bits.  If F is 1, this field is a 24-bit
    FGL Data Label for all subsequent MAC addresses in this APPsub-
    TLV.  Otherwise, if F is 0, the lower 12 bits are the VLAN of all
    subsequent MAC addresses in this APPsub-TLV, and the upper 12 bits
    are not used (sent as zero and ignored on receipt).  If there is
    no VLAN/FGL Data Label specified, the VLAN/FGL Data Label is zero.
 o  MAC(i): This is a 48-bit MAC address reachable in the Data Label
    sent by the Smart Endnode that is announcing this APPsub-TLV.

Perlman, et al. Standards Track [Page 9] RFC 8384 TRILL Smart Endnodes July 2018

5. Processing Data Packets

 The subsections below specify the processing of Smart Endnode data
 packets.  All TRILL Data packets sent to or from Smart Endnodes are
 sent in the Designated VLAN [RFC6325] of the local link but do not
 necessarily have to be VLAN tagged.

5.1. Data-Packet Processing for Smart Endnodes

 A Smart Endnode does not issue or receive LSPs or E-L1FS FS LSPs or
 calculate topology.  It does the following:
 o  A Smart Endnode maintains an endnode table of (the MAC address of
    remote endnode, Data Label, the nickname of the edge RBridge's
    attached) entries of end nodes with which the Smart Endnode is
    communicating.  Entries in this table are populated the same way
    that an edge RBridge populates the entries in its table:
  • learning from (source MAC address ingress nickname) on packets

it decapsulates.

  • by querying a directory [RFC7067].
  • by having some entries configured.
 o  When Smart Endnode SE1 wishes to send unicast frame to remote node
    D, if the (MAC address of remote endnode D, Data Label, nickname)
    entry is in SE1's endnode table, SE1 encapsulates the ingress
    nickname as the nickname of the RBridge (RB1), egress nickname as
    indicated in D's table entry.  If D is unknown, SE1 either queries
    a directory or encapsulates the packet as a multi-destination
    frame, using one of the trees that RB1 has specified in RB1's
    Smart-Hello.  The mechanism for querying a directory is given in
    [RFC8171].
 o  When SE1 wishes to send a Broadcast, Unknown Unicast, and
    Multicast (BUM) packet to the TRILL campus, SE1 encapsulates the
    packet using one of the trees that RB1 has specified.
 If the Smart Endnode SE1 sends a multi-destination TRILL Data packet,
 the destination MAC of the outer Ethernet is the All-RBridges
 multicast address.
 The Smart Endnode SE1 need not send Smart-Hellos as frequently as
 normal RBridges.  These Smart-Hellos could be periodically unicast to
 the Appointed Forwarder RB1.  In case RB1 crashes and restarts, or
 the DRB changes and SE1 receives the Smart-Hello without mentioning

Perlman, et al. Standards Track [Page 10] RFC 8384 TRILL Smart Endnodes July 2018

 SE1, SE1 SHOULD send a Smart-Hello immediately.  If RB1 is Appointed
 Forwarder for any of the VLANs that SE1 claims, RB1 MUST list SE1 in
 its Smart-Hellos as a Smart Endnode neighbor.

5.2. Data-Packet Processing for Edge RBridge

 The attached edge RBridge processes and forwards TRILL Data packets
 based on the endnode property rather than for encapsulation and
 forwarding the native frames the same way as the traditional
 RBridges.  There are several situations for the edge RBridges as
 follows:
 o  If receiving an encapsulated unicast TRILL Data packet from a port
    with a Smart Endnode, with RB1's nickname as ingress, the edge
    RBridge RB1 forwards the frame to the specified egress nickname,
    as with any encapsulated frame.  However, RB1 SHOULD filter the
    encapsulation frame based on the inner source MAC and Data Label
    as specified for the Smart Endnode.  If the MAC (or Data Label) is
    not among the expected entries of the Smart Endnode, the frame
    would be dropped by the edge RBridge.  If the edge RBridge does
    not perform this check, it makes it easier for a rogue end station
    to inject bogus TRILL Data packets into the TRILL campus.
 o  If receiving a unicast TRILL Data packet with RB1's nickname as
    egress from the TRILL campus, and the destination MAC address in
    the enclosed packet is a MAC address that has been listed by a
    Smart Endnode, RB1 leaves the packet encapsulated to that Smart
    Endnode.  The outer Ethernet destination MAC is the destination
    Smart Endnode's MAC address, the inner destination MAC address is
    either the Smart Endnode's MAC address or some other MAC address
    that the Smart Endnode advertised in its Smart Hello, and the
    outer Ethernet source MAC address is the RB1's port MAC address.
    The edge RBridge still decreases the Hop count value by 1, for
    there is one hop between the RB1 and Smart Endnode.
 o  If receiving a multi-destination TRILL Data packet from a port
    with a Smart Endnode, RBridge RB1 forwards the TRILL encapsulation
    to the TRILL campus based on the distribution tree indicated by
    the egress nickname.  If the egress nickname does not correspond
    to a distribution tree, the packet is discarded.  If there are any
    normal endnodes (i.e., endnodes that are not Smart Endnodes)
    attached to the edge RBridge RB1, RB1 decapsulates the frame and
    sends the native frame to these ports possibly pruned based on
    multicast listeners, in addition to forwarding the multi-
    destination TRILL frame to the rest of the campus.

Perlman, et al. Standards Track [Page 11] RFC 8384 TRILL Smart Endnodes July 2018

 o  If RB1 receives a native multi-destination data frame, which is
    sent by an endnode that is not a Smart Endnode, from a port,
    including hybrid endnodes (Smart Endnodes and endnodes that are
    not Smart Endnodes), RB1 will encapsulate it as multi-destination
    TRILL Data packet, and send the encapsulated multi-destination
    TRILL Data packet out that same port to the Smart Endnodes
    attached to the port, and also send the encapsulated multi-
    destination TRILL Data packet to the TRILL campus through other
    ports.
 o  If RB1 receives a multi-destination TRILL Data packet from a
    remote RBridge, and the exit port includes hybrid endnodes (Smart
    Endnodes and endnodes that are not Smart Endnodes), it sends two
    copies of multicast frames out the port, one as native and the
    other as a TRILL-encapsulated frame.  When a Smart Endnode
    receives a multi-destination TRILL Data packet, it learns the
    remote (MAC address, Data Label, nickname) entry.  A Smart Endnode
    ignores native data frames.  A normal (non-Smart) endnode receives
    the native frame and learns the remote MAC address and ignores the
    TRILL Data packet.  This transit solution may bring some
    complexity for the edge RBridge and waste network bandwidth
    resource, so avoiding the hybrid endnodes scenario by attaching
    the endnodes that are Smart and non-Smart to different ports is
    RECOMMENDED.

6. Multihoming Scenario

 Multihoming is a common scenario for the Smart Endnode.  The Smart
 Endnode is on a link attached to the TRILL domain in two places: edge
 RBridges RB1 and RB2.  Take Figure 4 as an example.  The Smart
 Endnode SE1 is attached to the TRILL domain by RB1 and RB2
 separately.  Both RB1 and RB2 could announce their nicknames to SE1.
                      . .....................
                      .  +------+           .
                      .  | RB1  |           .
                      . /+------+           .
         +----------+ ./            +-----+ .    +----------+
         |SE1(Smart |/.             | RB3 |......| Smart    |
         | Endnode1)| .\            +-----+ .    | Endnode2 |
         +----------+ . \                   .    +----------+
                      .  +-----+            .
                      .  | RB2 |   TRILL    .
                      .  +-----+   Domain   .
                      .......................
                    Figure 4: Multihoming Scenario

Perlman, et al. Standards Track [Page 12] RFC 8384 TRILL Smart Endnodes July 2018

 Smart Endnode SE1 can choose either the nickname of RB1 or RB2 when
 encapsulating and forwarding a TRILL Data packet.  If the active-
 active load balance is considered for the multihoming scenario, the
 Smart Endnode SE1 could use both the nickname of RB1 and RB2 to
 encapsulate and forward TRILL Data packet.  SE1 uses RB1's nickname
 when forwarding through RB1 and RB2's nickname when forwarding
 through RB2.  This will cause MAC flip-flopping (see [RFC7379]) of
 the endnode table entry in the remote RBridges (or Smart Endnodes).
 The solution for the MAC flip-flopping issue is to set a multihoming
 bit in the RSV field of the TRILL Data packet.  When remote RBridge
 RB3 or Smart Endnodes receive a data packet with the multihomed bit
 set, the endnode entries (SE1's MAC address, label, RB1's nickname)
 and (SE1's MAC address, label, RB2's nickname) will coexist as
 endnode entries in the remote RBridge.  (An alternative solution
 would be to use the ESADI protocol to distribute multiple attachments
 of a MAC address of a multihoming group.  The ESADI is deployed among
 the edge RBridges (see Section 5.3 of [RFC7357]).

7. Security Considerations

 Smart-Hellos can be secured by using Authentication TLVs based on
 [RFC5310].  If they are not secured, then it is easier for a rogue
 end station that does not posses the required keying material to be
 falsely recognized as a valid Smart Endnode.
 For general TRILL Security Considerations, see [RFC6325].  As stated
 there, since end stations are connected to edge RBridge ports by
 Ethernet, those ports MAY require end stations to authenticate
 themselves using [IEEE802.1X] and authenticate and encrypt traffic
 to/from the RBridge port with [IEEE802.1AE].
 If they misbehave, Smart Endnodes can forge arbitrary ingress and
 egress nicknames in the TRILL headers of the TRILL Data packets they
 construct.  Decapsulating at egress RBridges or remote Smart Endnodes
 that believe such a forged ingress nickname would send future traffic
 destined for the inner-source MAC address of the TRILL data frame to
 the wrong edge RBridge if data-plane learning is in use.  Because of
 this, an RBridge port should not be configured to support Smart
 Endnodes unless the end stations on that link are trusted or can be
 adequately authenticated.
 As with any end station, Smart Endnodes can forge the outer MAC
 addresses of packets they send (see Section 6 of [RFC6325].)  Because
 they encapsulate TRILL Data packets, they can also forge inner MAC
 addresses.  The encapsulation performed by Smart Endnodes also means
 they can send data in any Data Label, which means they must be
 trusted in order to enforce a security policy based on Data Labels.

Perlman, et al. Standards Track [Page 13] RFC 8384 TRILL Smart Endnodes July 2018

 The TRILL-Hello is a type of TRILL ES-IS and is defined in [RFC8171].
 Receiving and processing TRILL-Hello for RBridges and Smart Endnodes
 would not bring more security and vulnerability issues than the TRILL
 ES-IS security defined in [RFC8171].
 For added security against the compromise of data due to its
 misdelivery for any reason, including the above, end-to-end
 encryption and authentication should be considered; that is,
 encryption and authentication from source end station to destination
 end station.
 The mechanism described in this document requires Smart Endnodes to
 be aware of the MAC address(es) of the TRILL edge RBridge(s) to which
 they are attached and the egress RBridge nickname from which the
 destination of the packets is reachable.  With that information,
 Smart Endnodes can learn a substantial amount about the topology of
 the TRILL domain.  Therefore, there could be a potential security
 risk when the Smart Endnodes are not trusted or are compromised.

8. IANA Considerations

 IANA has allocated APPsub-TLV type numbers for the Smart-MAC and
 Smart-Parameters APPsub-TLVs.  The "TRILL APPsub-TLV Types under
 IS-IS TLV 251 Application Identifier 1" registry has been updated as
 follows.
            +-----------+-------------------+------------+
            |  Protocol |    Description    | Reference  |
            +-----------+-------------------+------------+
            |     22    |  Smart-Parameters |  RFC 8384  |
            |     23    |     Smart-MAC     |  RFC 8384  |
            +-----------+-------------------+------------+
                                Table 1

Perlman, et al. Standards Track [Page 14] RFC 8384 TRILL Smart Endnodes July 2018

9. References

9.1. Normative References

 [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,
            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>.
 [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>.
 [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>.

Perlman, et al. Standards Track [Page 15] RFC 8384 TRILL Smart Endnodes July 2018

 [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>.
 [RFC8171]  Eastlake 3rd, D., Dunbar, L., Perlman, R., and Y. Li,
            "Transparent Interconnection of Lots of Links (TRILL):
            Edge Directory Assistance Mechanisms", RFC 8171,
            DOI 10.17487/RFC8171, June 2017,
            <https://www.rfc-editor.org/info/rfc8171>.
 [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>.

9.2. Informative References

 [IEEE802.1AE]
            IEEE, "IEEE Standard for Local and metropolitan area
            networks -- Media Access Control (MAC) Security",
            IEEE 802.1AE.
 [IEEE802.1X]
            IEEE, "IEEE Standard for Local and metropolitan area
            networks -- Port-Based Network Access Control",
            IEEE 802.1X.
 [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, <https://www.rfc-editor.org/info/rfc7067>.
 [RFC7379]  Li, Y., Hao, W., Perlman, R., Hudson, J., and H. Zhai,
            "Problem Statement and Goals for Active-Active Connection
            at the Transparent Interconnection of Lots of Links
            (TRILL) Edge", RFC 7379, DOI 10.17487/RFC7379, October
            2014, <https://www.rfc-editor.org/info/rfc7379>.

Acknowledgements

 The contributions of the following persons are gratefully
 acknowledged: Mingui Zhang, Weiguo Hao, Linda Dunbar, Kesava Vijaya
 Krupakaran, and Andrew Qu.

Perlman, et al. Standards Track [Page 16] RFC 8384 TRILL Smart Endnodes July 2018

Authors' Addresses

 Radia Perlman
 Dell EMC
 176 South Street
 Hopkinton, MA  01748
 United States of America
 Phone: +1-206-291-367
 Email: radiaperlman@gmail.com
 Fangwei Hu
 ZTE Corporation
 No.889 Bibo Rd
 Shanghai  201203
 China
 Phone: +86 21 68896273
 Email: hu.fangwei@zte.com.cn
 Donald Eastlake
 Huawei Technologies
 1424 Pro Shop Court
 Davenport, FL 33896
 United States of America
 Phone: +1-508-333-2270
 Email: d3e3e3@gmail.com
 Ting Liao
 Huawei Technologies
 Nanjing, Jiangsu  210012
 China
 Email: liaoting1@huawei.com

Perlman, et al. Standards Track [Page 17]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8384.txt · Last modified: 2018/07/12 06:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki