Internet DRAFT - draft-eastlake-trill-multi-topology
draft-eastlake-trill-multi-topology
INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Mingui Zhang
Updates: 6325, 7177 Huawei
Ayan Banerjee
Cisco
Vishwas Manral
Ionos
Expires: December 31, 2015 July 1, 2015
TRILL: Multi-Topology
<draft-eastlake-trill-multi-topology-02.txt>
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. It updates RFC 6325 and RFC 7177.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
D. Eastlake, et al [Page 1]
INTERNET-DRAFT TRILL: Multi-Topology
Table of Contents
1. Introduction............................................3
1.1 Terminology............................................4
2. Topologies..............................................5
2.1 Special Topology Zero..................................5
2.2 Links and Multi-Topology...............................5
2.3 TRILL Switches and Multi-Topology......................5
2.4 TRILL Data Packets and Multi-Topology..................6
2.4.1 Explicit Topology Labeling Support...................6
2.4.2 Explicit Topology Labels.............................7
3. TRILL Multi-Topology Adjacency and Routing..............9
3.1 Adjacency (Updates to RFC 7177)........................9
3.2 TRILL Switch Nicknames.................................9
3.3 TRILL Unicast Routing.................................10
3.4 TRILL Multi-Destination Routing.......................10
3.4.1 Distribution Trees..................................10
3.4.2 Multi-Access Links..................................12
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..............................16
6.1 IEEE Registration Authority Considerations............16
6.2 IANA Considerations...................................16
7. Security Considerations................................17
Normative References......................................18
Informative References....................................19
Acknowledgements..........................................20
Appendix A: Differences from RFC 5120.....................21
Authors' Addresses........................................22
D. Eastlake, et al [Page 2]
INTERNET-DRAFT TRILL: Multi-Topology
1. Introduction
This document specifies extensions to the IETF TRILL (Transparent
Interconnection of Lots of Links) protocol [RFC6325] [RFC7176]
[RFC7177] 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.
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 [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 physical TRILL switches and links that are in their
topology but may still use any of the TRILL switches and links 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.
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
resulting in two or more islands of that topology. In that case, end
station 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 an multi-topology campus; however, such regions
can only ingress, egress, or transit TRILL Data frames in the special
base topology zero.
D. Eastlake, et al [Page 3]
INTERNET-DRAFT TRILL: Multi-Topology
1.1 Terminology
The terminology and acronyms of [RFC6325] are used in this document
along with the following:
campus - The name for a TRILL network, like "bridged LAN" is a
name for a bridged network. It does not have any academic
implication.
FGL - Fine-Grained Labeling or Fine-Grained Labeled or Fine-
Grained Label [RFC7176].
LSP - [IS-IS] Link State PDU (Protocol Data Unit). For TRILL this
include L1-LSPs and E-L1FS-LSPs [rfc7180bis].
MT - Multi-Topology, this document and [RFC5120].
MT TRILL Switch - A FGL TRILL switch supporting the multi-topology
feature specified in this document.
RBridge - "Routing Bridge", an alternative name for a TRILL
switch.
TRILL - Transparent Interconnecton of Lots of Links or Tunneled
Routing in the Link Layer [RFC6325].
TRILL Switch - A switch implementing the TRILL protocol.
VL - VLAN Labeling or VLAN Labeled or VLAN Label [RFC7172].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
D. Eastlake, et al [Page 4]
INTERNET-DRAFT TRILL: Multi-Topology
2. Topologies
In TRILL multi-topology, a topology is a subset of the TRILL switches
and of the links between TRILL switches in a 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 [RFC5120] IS-IS multi-topology. 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, 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 received 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 only usable for TRILL Data packets in non-zero topology T
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.
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.
There is no general "MT capability bit". A TRILL switch advertises
that it is MT capable by advertising in its LSP support for any
D. Eastlake, et al [Page 5]
INTERNET-DRAFT TRILL: Multi-Topology
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
Commonly, the topology of a TRILL Data packet is 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 may sometimes used to determine topology are
values or ranges of values of the payload VLAN or Fine Grained Label
[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 message are link local and can be thought
of as being outside all topologies. "Multi-topology" only applies to
TRILL Data packets.
2.4.1 Explicit Topology Labeling Support
Support of the explicit topology label is optional even for MT TRILL
switches. Support could depend on port hardware and is indicated by
a two-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 should treat as erroneous and discard any
data packet received with a topology label.
1 Capable of inserting an explicit topology label in data
packets sent and tolerant of such labels in received data
packets. Such a port is capable of determining TRILL Data
packet topology without an explicit lable for all of the
topologies it supports and thus does not require such a label
in received TRILL Data packets. On receiving a packet whose
explicit topology label differs from the ports topology
D. Eastlake, et al [Page 6]
INTERNET-DRAFT TRILL: Multi-Topology
determination for that packet, the TRILL switch MUST discard
the packet.
2/3 Requires an explicit topology label in received TRILL Data packets
except for topology zero. Any TRILL Data packets received
without such a label is 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.)
A TRILL switch advertising in a Hello on Port P support for topology
T but not advertising in those Hellos 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 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. If a 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 Explicit Topology Labels
The TRILL 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL-MT Ethertype TBD | RESV | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. TRILL MT Label
where RESV is a 4-bit reserved field that MUST be sent as zero and
ignored on receipt and MT-ID is the 12-bit topology of the TRILL Data
packet using the topology number space of the MT TLV [RFC5120]. With
the addition of the TRILL MT label, the four standardized content
varieties for the TRILL Data packet data labeling area (the area
after the Inner.MacSA and before the payload) are as show below.
{PRI, D} is a 3-bit priority and a drop eligibility indicator bit
[rfc7180bis]. All MT TRILL switches MUST support FGL and thus MUST
support all four data labeling area contents shown below.
D. Eastlake, et al [Page 7]
INTERNET-DRAFT TRILL: Multi-Topology
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. MT C-VLAN [this document]
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL-MT Ethertype TBD | RESV | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8100 | PRI |D| VLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. MT FGL [this document] [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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL-MT Ethertype TBD | RESV | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x893B | PRI |D| FGL High Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x893B | PRI |D| FGL Low Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inclusion of S-VLAN or other stacked tags is beyond the scope of this
document but, as stated in [RFC6325], is an obvious extension.
D. Eastlake, et al [Page 8]
INTERNET-DRAFT TRILL: Multi-Topology
3. TRILL Multi-Topology Adjacency and Routing
Routing calculations in IS-IS are based on adjacency. Section 3.1
specifies multi-topology updates to the TRILL adjacency
specification. 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.
3.1 Adjacency (Updates to RFC 7177)
There is no change in the determination or announement of adjacency
for topology zero as specified in [RFC7177]. When an adjacency
reaches the Report state as specified in [RFC7177], the adjacency is
announced for topology zero in LSPs using the Extended Intermediate
System Reachability TLV (#22).
Adjacency is announced for non-zero topologies in LSPs using the MT
Reachable Intermediate Systems TLV as specified in [RFC5120]. The
ports on a TRILL link are reported as adjacent 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] [rfc7180bis].
Such nicknames can be viewed as simply 16-bit abbreviation for a
TRILL switch's (or pseudo-node's) 7-byte IS-IS 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 IDs are.
Nicknames are determined as specified in [RFC6325] and [rfc7180bis]
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, 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
D. Eastlake, et al [Page 9]
INTERNET-DRAFT TRILL: Multi-Topology
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. If that is not the case, then all LSPs 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 where each such table has been
calculated based on least cost routing within the particular
topology. 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 packets. To constrain multi-destination
packets to a topology and still distribute them properly requires the
use of a distribution tree constrained to that topology. Handling
such TRILL Data packets and distribution trees in 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], [rfc7180bis], and
[RFC7172]. 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 determine as specified in [RFC6325],
[rfc7180bis], and [RFC7172] with the following changes:
o As specified in [RFC5120], only links usable with topology T
TRILL Data frames are considered when building a distribution
tree for topology T. As a result, such trees are automatically
D. Eastlake, et al [Page 10]
INTERNET-DRAFT TRILL: Multi-Topology
limited to and separately span every internally connected
island of topology T. In other words, if non-zero topology T
consists of disjoint islands, distribution tree construction
for topology T is local to each 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 topology T.
+ There may be non-zero topologies with no multi-destination
traffic. 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 reasons, a Number of Trees to Compute
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 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, the one
in the lowest numbered LSP fragment is used and if there are
multiple in that fragment, the one with the smallest offset
from the beginning of the LSP is used.
o Tree pruning for topology T uses only the Interested VLANs and
Interested Labels sub-TLVs [RFC7176] advertised in MT Router
Capabilities TLVs for topology T.
An MT TRILL switch MUST have logically separate routing tables per
topology for the forwarding of multi-destination traffic.
D. Eastlake, et al [Page 11]
INTERNET-DRAFT TRILL: Multi-Topology
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.
D. Eastlake, et al [Page 12]
INTERNET-DRAFT TRILL: Multi-Topology
4. Mixed Links
A link might have any combination of MT, FGL, or even VL TRILL
switches on it [RFC7172]. DRB (Designated RBridge) election and
Forwarder appointment on the link work as previously specified in
[RFC6439] 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-TVLs 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.
D. Eastlake, et al [Page 13]
INTERNET-DRAFT TRILL: Multi-Topology
5. Other Multi-Topology Considerations
5.1 Address Learning
The learning of end station MAC addresses is per topology as well as
per label (VLAN or FGL). The same MAC address can occur for different
end stations that differ only in topology.
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, 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 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,
transit, or egress 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 are constrained by
topology like other TRILL Data packets. In general, when sent for
network management purposes, they are sent in topology zero.
D. Eastlake, et al [Page 14]
INTERNET-DRAFT TRILL: Multi-Topology
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, but 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 8 or more topologies can be considered a full implementation
while a TRILL switch capable of handling 4 topologies can be
considered a minimal implementation but still useful under some
circumstances.
D. Eastlake, et al [Page 15]
INTERNET-DRAFT TRILL: Multi-Topology
6. Allocation Considerations
IEEE Registration Authority and IANA considerations are given below.
6.1 IEEE Registration Authority Considerations
The IEEE Registration Authority will be requested to allocate a new
Ethertype for TRILL-MT (see Section 2.4).
6.2 IANA Considerations
IANA will allocate a field of two adjacent bits TBD from bits 14
through 31 of the Capabilities bits of the Port TRILL Version Sub-TLV
for the Explicit Topology capability field.
D. Eastlake, et al [Page 16]
INTERNET-DRAFT TRILL: Multi-Topology
7. Security Considerations
Multiple topologies are sometimes used for the isolation or security
of traffic. For example, if some links was 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.
For general TRILL security considerations, see [RFC6325].
D. Eastlake, et al [Page 17]
INTERNET-DRAFT TRILL: Multi-Topology
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, March 1997.
[RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Intermediate
Systems (IS-ISs)", RFC 5120, February 2008.
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC7172] - Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R.,
and D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, May 2014.
[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, May 2014.
[RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H.,
and V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014.
[RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links (TRILL):
RBridge Channel Support", RFC 7178, May 2014.
[RFC7357] - Hhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
Stokes, "Transparent Interconnection of Lots of Links (TRILL):
End Station Address Distribution Information (ESADI) Protocol",
RFC 7357, DOI 10.17487/RFC7357, September 2014,
<http://www.rfc-editor.org/info/rfc7357>.
[rfc7180bis] - 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", draft-ietf-trill-rfc7180bis, work in progress.
D. Eastlake, et al [Page 18]
INTERNET-DRAFT TRILL: Multi-Topology
Informative References
[RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
6439, November 2011.
[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,
May 2014.
D. Eastlake, et al [Page 19]
INTERNET-DRAFT TRILL: Multi-Topology
Acknowledgements
The comments and suggestions of the following are gratefully
acknowledged:
TBD
The document was prepared in raw nroff. All macros used were defined
within the source file.
D. Eastlake, et al [Page 20]
INTERNET-DRAFT TRILL: Multi-Topology
Appendix A: Differences from RFC 5120
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 or pre-existing fields within the packet.
This document supports implicit determination but extends this for
TRILL by providing for optional explicit topology labeling of
TRILL 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).
D. Eastlake, et al [Page 21]
INTERNET-DRAFT TRILL: Multi-Topology
Authors' Addresses
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
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 P.R. China
Email: zhangmingui@huawei.com
Ayan Banerjee
Cisco
Email: ayabaner@cisco.com
Vishwas Manral
Ionos Corp.
4100 Moorpark Ave.
San Jose, CA 95117 USA
EMail: vishwas@ionosnetworks.com
D. Eastlake, et al [Page 22]
INTERNET-DRAFT TRILL: Multi-Topology
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
D. Eastlake, et al [Page 23]
