One document matched: draft-eastlake-trill-rfc6439bis-00.txt
TRILL Working Group Donald Eastlake
INTERNET-DRAFT Yizhou Li
Intended status: Proposed Standard Huawei
Obsoletes: 6439 Mohammad Umair
Updates: 6325 IPinfusion
Ayan Banerjee
Cisco
Hu Fangwei
ZTE
Expires: September 5, 2015 March 6, 2015
TRILL: Appointed Forwarders
<draft-eastlake-trill-rfc6439bis-00.txt>
Abstract
TRILL supports multi-access LAN (Local Area Network) links that can
have multiple end stations and TRILL switches attached. Where
multiple TRILL switches are attached to a link, native traffic to and
from end stations on that link is handled by a subset of those TRILL
switches called "Appointed Forwarders", with the intent that native
traffic in each VLAN be handled by at most one TRILL switch. This
document clarifies and updates the Appointed Forwarder mechanism. It
updates RFC 6325 and obsoletes RFC 6439.
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 <trill@ietf.org>.
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: Appointed Forwarders
Table of Contents
1. Introduction...........................................3
1.1 Appointed Forwarders and Active-Active.................4
1.2 Terminology and Acronyms...............................4
2. Appointed Forwarders and Their Appointment..............6
2.1 The Appointment Databases and DRB Actions..............7
2.1.1 Efficiency of Appointment Encoding...................8
2.2 Appointment Effects of DRB Elections...................8
2.2.1 Processing Forwarder Appointments in Hellos..........9
2.2.2 Frequency of Appointments...........................11
2.2.3 Appointed Forwarders Hello Limits...................11
2.3 Local Configuration Action Appointment Effects........11
2.4 Overload and Appointed Forwarders.....................12
2.5 VLAN Mapping within a Link............................12
3. The Inhibition Mechanism...............................14
3.1 Inhibited Appointed Forwarder Behavior................16
4. Optional TRILL Hello Reduction.........................17
5. Multiple Ports on the Same Link........................19
6. VLAN-FGL Mapping Consistency Checking..................20
7. Support of E-L1CS......................................21
7.1 Backwards Compatibility...............................21
8. Security Considerations................................22
9. Code Points and Data Structures........................23
9.1 IANA Considerations...................................23
9.2 Appointment Bitmap APPsub-TLV.........................23
9.3 Appointment List APPsub-TLV...........................24
9.4 VLAN-FGL Mapping Bitmap APPsub-TLV....................25
9.5 VLAN-FGL Mapping Pairs APPsub-TLV.....................27
Normative References......................................28
Informative References....................................29
Acknowledgements..........................................30
Authors' Addresses........................................31
Appendix A: VLAN Inhibition Example.......................32
Appendix B: Changes to [RFC6325] and [RFC6439]............33
Appendix Z: Change Record.................................34
D. Eastlake, et al [Page 2]
INTERNET-DRAFT TRILL: Appointed Forwarders
1. Introduction
The IETF TRILL protocol [RFC6325] provides optimal pair-wise data
frame forwarding without configuration in multi-hop networks with
arbitrary topology and link technology, 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 (Intermediate System to Intermediate System) [IS-IS] link state
routing and encapsulating traffic using a header that includes a hop
count. The design supports VLANs, 24-bit fine grained labels
[RFC7172], and optimization of the distribution of multi-destination
frames based on VLANs and multicast groups. Devices that implement
TRILL are called TRILL switches or "RBridges" (Routing Bridges).
Section 2 of [RFC7177] discusses the environment for which the TRILL
protocol is designed and the differences between that environment and
the typical Layer 3 routing environment.
TRILL supports multi-access LAN (Local Area Network) links that can
have multiple end stations and TRILL switches attached. Where
multiple TRILL switches are attached to a link, native traffic to and
from end stations on that link is handled by a subset of those
switches called "Appointed Forwarders", with the intent that native
traffic in each VLAN be handled by at most one switch. A TRILL
switch can be Appointed Forwarder for many VLANs.
The purpose of this document is to update and improve the Appointed
Forwarder mechanism and free it from the limitations imposed by the
requirement in its initial design that all appointments fit within a
TRILL Hello PDU. This is accomplished by requiring support of link
scoped FS-LSPs (Section 7) and proving for appointment information to
be sent in those LSPs. In addition it provides an optional feature to
detect inconsistent VLAN to FGL [RFC7172] mappings among the TRILL
switch ports on a link as discussed in Section 6. It obsoleted
[RFC6439], updates [RFC6325], and includes reference implementation
details. Alternative implementations that interoperate on the wire
are permitted.
The Appointed Forwarder mechanism is irrelevant to any link on which
end station service is not offered. This includes links configured
as point-to-point IS-IS links and any link with all TRILL switch
ports on that link configured as trunk ports. (In TRILL,
configuration of a port as a "trunk port" just means that no end
station service will be provided. It does not imply that all VLANs
are enabled on that port.)
The Appointed Forwarder mechanism has no effect on the formation of
adjacencies, the election of the Designated RBridge (DRB) for a link,
MTU matching, or pseudonode formation. Those topics are covered in
[RFC7177]. Furthermore, Appointed Forwarder status has no effect on
D. Eastlake, et al [Page 3]
INTERNET-DRAFT TRILL: Appointed Forwarders
the forwarding of TRILL Data frames; it only affects the handling of
native frames to and from end stations.
For other aspects of the TRILL base protocol, see [RFC6325],
[RFC7177], and [rfc7180bis]. In case of conflict between this
document and [RFC6325], this document prevails.
1.1 Appointed Forwarders and Active-Active
As discussed in [RFC7379], TRILL active-active provides support for
end stations connected to multiple edge TRILL switches where these
connections are separate links. Since TRILL Hellos are not forwarded
between these links, the Appointed Forwarder mechanism as described
herein operates separately on each such link.
1.2 Terminology and Acronyms
This document uses the acronyms and terms defined in [RFC6325], some
of which are repeated below for convenience, and additional acronyms
and terms listed below.
E-L1CS: Extended Level 1 Circuit Scoped (Section 6).
FGL: Fine Grained Label [RFC7172].
FS-LSP: Flooding Scoped - Link State PDU (Section 6).
Link: The means by which adjacent TRILL switches are connected. May
be various technologies and in the common case of Ethernet, can be a
"bridged LAN", that is to say, some combination of Ethernet links
with zero or more bridges, hubs, repeaters, or the like.
LSDB: Link State Data Base.
RBridge: An alternative name for a TRILL switch.
TRILL: Transparent Interconnection of Lots of Links or Tunneled
Routing in the Link Layer.
TRILL switch: A device implementing the TRILL protocol. An
alternative name for an RBridge.
Trunk port: A TRILL switch port configured with the "end station
service disable" bit on, as described in Section 4.9.1 of [RFC6325].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
D. Eastlake, et al [Page 4]
INTERNET-DRAFT TRILL: Appointed Forwarders
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
D. Eastlake, et al [Page 5]
INTERNET-DRAFT TRILL: Appointed Forwarders
2. Appointed Forwarders and Their Appointment
The Appointed Forwarder on a link for VLAN-x is the TRILL switch
(RBridge) that ingresses native frames from the link and egresses
native frames to the link in VLAN-x. By default, the DRB (Designated
RBridge) on a link is in charge of native traffic for all VLANs on
the link. The DRB may, if it wishes, act as Appointed Forwarder for
any VLAN and it may appoint other TRILL switches that have ports on
the link as Appointed Forwarder for one or more VLANs.
It is important that there not be two Appointed Forwarders on a link
that are ingressing and egressing native frames for the same VLAN at
the same time. Should this occur, it could form a loop where frames
are not protected by a TRILL Hop Count for part of the loop. (Such a
condition can even occur through two Appointed Forwarders for two
different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the
link are configured to map frames between VLAN-x and VLAN-y as
discussed in Section 2.5.) While TRILL tries to avoid such
situations, for loop safety there is also an "inhibition" mechanism
(see Section 3) that can cause a TRILL switch that is an Appointed
Forwarder to not ingress or egress native frames. Appointed
Forwarder status and port "inhibition" have no effect on the
reception, transmission, or forwarding of TRILL Data or TRILL IS-IS
frames. They only affects the handling of native frames.
As discussed in Section 5, an RBridge may have multiple ports on a
link. As discussed in [RFC7177], if there are multiple ports with
the same Media Access Control (MAC) address on a link, all but one
will be suspended. The case of multiple ports on a link for the same
TRILL switch and the case of multiple ports with the same MAC address
on a link and combinations of these cases are fully accommodated;
however, multiple ports on a link for the same TRILL switch is
expected to be a rare condition and duplicate MAC addresses is not
recommended by either TRILL or IEEE 802.1 standards.
There are five mechanisms by which an RBridge can be appointed or un-
appointed as Appointed Forwarder: (1) assumption of appointment, when
the DRB decides to act as Appointed Forwarder for a VLAN, (2) Hello
appointment, as a result of appointments sent by the DRB in TRILL
Hellos, (3) E-L1CS appointment, as a result of appointments sent by
the DRB in E-L1CS FS-LSPs, (4) as a result of the DRB elections
[RFC7177] as discussed in Section 2.2, and (5) as a result of a local
configuration action as discussed in Section 2.3. Mechanisms 2 and 3
are covered in Section 2.1.
D. Eastlake, et al [Page 6]
INTERNET-DRAFT TRILL: Appointed Forwarders
2.1 The Appointment Databases and DRB Actions
The DRB MAY appoint other RBridges on the link as Appointed
Forwarders through the mechanisms A and B described below. Each
RBridge maintains two databases of appointment information: (1) its
E-L1CS LSDB that shows appointments each RBridge on the link would
make using mechanism A if it were the DRB, and (2) its Hello
appointment database that shows the appointments most recently sent
by the DRB in a TRILL Hello. The E-L1CS LSDB is semi-permanent and is
only changed by E-L1CS FS-LSPs or IS-IS purges. The Hello appointment
database is more transient and is completely reset by each Hello
received from the DRB that contains any appointments and is also
cleared under other circumstances as described below. An RBridge
considers itself to be the Appointed Forwarder for VLAN-x if this is
indicate by either its Hello appointment database or its E-L1CS LSDB
entries from the DRB.
The two mechanisms by which the DRB can appoint other RBridges on a
link Appointed Forwarders are as follows:
(A) The inclusion of one or more Appointed Forwarders sub-TLVs
[RFC7176], Appointment Bitmap APPsub-TLVs (Section 9.2), or
Appointment List APPsub-TLVs (Section 9.3) in E-L!CS LSPs it
sends on a link. Appointments sent with this method will not be
seen by legacy RBridges that do not support E-L1CS (Section 6).
(B) The inclusion of one or more Appointed Forwarders sub-TLVs
[RFC7176] in a TRILL Hello it sends on the Designated VLAN out
the port that won the DRB election. When the DRB sends any
appointments in a TRILL Hello, it must send all appointments it
is sending in Hellos for that link in that Hello. Any previous
appointment it has sent in a Hello that is not included is
implicitly revoked.
To avoid the size limitations of the Hello PDU, it is recommended
that the E-L1CS FS-LSP method be used to distribute forwarder
appointments and that all RBridges on a link advertise by this method
the appointments they would make if they were DRB. However, if some
RBridges on a link do not support E-L1CS FS-LSPs, then Hello
appointments must be used for the DRB to appoint such legacy RBridges
Appointed Forwarder.
Although the DRB does not need to announce the VLANs for which it has
chosen to act as Appointed Forwarder by sending appoints for itself,
if the DRB wishes to revoke all appointments made in Hellos for
RBridges other than itself on the link, it can do so by sending a
TRILL Hello with just an appointment for itself for some VLAN.
How the DRB decides what other RBridges on the link, if any, to
appoint forwarder for which VLANs is beyond the scope of this
D. Eastlake, et al [Page 7]
INTERNET-DRAFT TRILL: Appointed Forwarders
document.
Unnecessary changes in Appointed Forwarders SHOULD NOT be made as
they may result in transient lack of end station service.
Should the network manager have misconfigured the enabled VLANs and
Appointed Forwarders, resulting in two RBridges believing they are
Appointed Forwarders for the same VLAN, then item 4 in Section 3 will
cause one or more of the RBridges to be inhibited for that VLAN.
2.1.1 Efficiency of Appointment Encoding
When forwarder appontments are being encoded for transmission,
different patterns of VLANs are most efficiently encoded in different
ways. The following table gives advice for the most efficient
encoding:
sub-TLV and Reference
Pattern of VLANs |enclosing TLV(s) and Reference
----------------- ----------------------------------
Blocks of VLANs Appointed Forwarders sub-TLV [RFC7176]
|Router Capabilities TLV [RFC4971]
|or MT Capabilities TLV [RFC6329]
Scattered VLANs within a small range
Appointment Bitmap APPsub-TLV (Section 9.2)
|TRILL GENINFO TLV [RFC7357]
Scattered VLANs over a large range
Appointment List APPsub-TLV (Section 9.3)
|TRILL GENINFO TLV (RFC7357)
2.2 Appointment Effects of DRB Elections
When an RBridge believes that it has become the DRB on a link, by
default, it can act as Appointed Forwarder for any VLANs on that link
that it chooses as long as its port is not configured as a trunk port
and has that VLAN enabled (or at least one of its ports meets these
criteria, if it has more than one port on the link).
An RBridge loses all Hello appointments and changes which E-L1CS FS-
LSP appointments it uses as follows:
1. When it decides that it has lost the status of being the DRB for a
link; or
D. Eastlake, et al [Page 8]
INTERNET-DRAFT TRILL: Appointed Forwarders
2. When it observes a change in the RBridge that is the DRB for the
link without itself becoming the DRB.
In both cases, it switches to being Appointed Forwarder for the
appointments in its E-L1CS FS-LSP appointment database from the new
DRB.
In the corner case where a TRILL switch has more than one port on a
link, one of which was previously the DRB election winner but has
just lost the DRB election to a different port of the same TRILL
switch (possibly due to management configuration of port priorities),
there is no change in which TRILL switch is the DRB. Therefore,
neither of the above points applies and there is no change in
Appointed Forwarder status.
2.2.1 Processing Forwarder Appointments in Hellos
When a non-DRB RBridge that can offer end station service on a link
receives a TRILL Hello that is not discarded for one of the reasons
given in [RFC7177], it checks the source MAC address and the Port ID
and System ID in the Hello to determine if it is from the winning DRB
port. If it is not from that port, any forwarder appointment sub-
TLVs in the Hello are ignored, and there is no change in the
receiving RBridge's Appointed Forwarder status due to that Hello.
Also, if no forwarder appointment sub-TLVs are present in the TRILL
Hello, there is no change in the receiver's Appointed Forwarder
status due to that Hello.
However, if the TRILL Hello is from the winning DRB port and the
Hello includes one or more forwarder appointment sub-TLVs, then the
receiving RBridge sets its Hello appointment database to be the VLANs
that are both listed for it in the Hello and are enabled on the
receiving port. (If the appointment includes VLAN IDs 0x000 or
0xFFF, they are ignored, but any other VLAN IDs are still effective.)
It then becomes Appointed Forwarder for all the VLANs for which it is
appointed in either its Hello appointment database or its E-L1CS
appointment database from the DRB if the VLAN is enabled and if the
port is not configured as a trunk or IS-IS point-to-point port. If
the receiver was Appointed Forwarder for any VLANs because they were
in the Hello appointment database and they are no longer in the Hello
appointment database, its Appointed Forwarder status for such VLANs
is revoked. For example, if none of these sub-TLVs in a Hello
appoints the receiving RBridge, then it loses all Appointed Forwarder
status on the port where the Hello was received due to Hello
appointment database entries but it retains Appointed Forwarder
status due to E-L1CS FS-LSP appointments.
The handling of one or more forwarder appointment sub-TLVs in a Hello
D. Eastlake, et al [Page 9]
INTERNET-DRAFT TRILL: Appointed Forwarders
from the winning port that appoints the receiving RBridge is as
follows: An appointment in an Appointed Forwarder sub-TLV is for a
specific RBridge and a contiguous interval of VLAN IDs; however, as
stated above, it actually appoints that RBridge forwarder only for
the VLAN(s) in that range that are enabled on one or more ports that
RBridge has on the link (ignoring any ports configured as trunk ports
or as IS-IS point-to-point ports).
There is no reason for an RBridge to remember that it received a
valid appointment Hello message for a VLAN that was ineffective
because the VLAN was not enabled on the port where the Hello was
received or because the port was a trunk or point-to-point port. It
does not become Appointed Forwarder for such a VLAN just because that
VLAN is later enabled or the port later reconfigured.
The limitations due to the size of the Hello PDU make it desirable to
use E-L1CS FS-LSPs for appointment. But if Hellos need to be used,
due to TRILL switches on the link not supporting E-L1CS FS-LSPs, the
remainder of this section gives a method to maximize the use of the
limited space in Hellos for forwarder appointment.
It should be straightforward for the DRB to send, within one Hello,
the appointments for several dozen VLAN IDs or several dozen blocks
of contiguous VLAN IDs. Should the VLANs the DRB wishes to appoint
be inconveniently distributed, for example, the proverbial case where
the DRB RB1 wishes to appoint RB2 forwarder for all even-numbered
VLANs and appoint RB3 forwarder for all odd-numbered VLANs, the
following method may be used: The network manager normally controls
what VLANs are enabled on an RBridge port. Thus, the network manager
can appoint an RBridge forwarder for an arbitrary set of scattered
VLANs by enabling only those VLANs on the relevant port (or ports)
and then having the DRB send an appointment that appears to appoint
the target RBridge forwarder for all VLANs. However, for proper
operation and inter-RBridge communication, the Designated VLAN for a
link SHOULD be enabled on all RBridge ports on that link, and it may
not be desired to appoint the RBridge forwarder for the Designated
VLAN. Thus, in the general case, it would require two appointments,
although it would still only require one appointment if the
Designated VLAN were an extreme low or high value such as VLAN 0xFFE
or the default VLAN 1.
For example, assume the DRB wants RB2 to be Appointed Forwarder for
all even-numbered VLANs and the Designated VLAN for the link is VLAN
101. The network manager could cause all even-numbered VLANs plus
VLAN 101 to be enabled on the relevant port of RB2 and then, with the
desired effect, cause the DRB to send appointments to RB2 appointing
it forwarder for all VLANs from 1 through 100 and from 102 through
4,094.
D. Eastlake, et al [Page 10]
INTERNET-DRAFT TRILL: Appointed Forwarders
2.2.2 Frequency of Appointments
Appointments made though E-L1CS FS-LSPs use the same IS-IS timing
constants as for LSP flooding. The general IS-IS link state flooding
mechanism is robust and includes acknowledgements so that it
automatically recovers from lost PDUs, re-booted TRILL switches, and
the like.
For Hello appointments, it is not necessary for the DRB to include
the Hello forwarder appointments in every TRILL Hello that it sends
on the Designated VLAN for a link. For loop safety, every RBridge is
required to indicate, in every TRILL Hello it sends in VLAN-x on a
link, whether it is an Appointed Forwarder for VLAN-x for that link
(see item 4 in Section 3 but see also Section 4). It is also
RECOMMENDED that the DRB have all VLANs for which end station service
will be offered on the link as well as the Designated VLAN, enabled.
Thus, the DRB will generally be informed by other RBridges on the
link of the VLANs for which they believe they are Appointed
Forwarder. If this matches the appointments the DRB wishes to make,
it is not required to re-send its forwarder appointments; however,
for robustness, especially in cases such as VLAN misconfigurations in
a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder
appointments on the Designated VLAN at least once per its Holding
Time on the port that won the DRB election.
2.2.3 Appointed Forwarders Hello Limits
The Hello mechanism of DRB forwarder appointment and the limited
length of TRILL Hellos impose a limit on the number of RBridges on a
link that can be Appointed Forwarders when E-L1CS FS-LSP appointments
cannot be used. To obtain a conservative estimate, assume that no
more than 1000 bytes are available in a TRILL Hello for such
appointments. Assume it is desired to appoint various RBridges on a
link forwarder for arbitrary non-intersecting sets of VLANs. Using
the technique discussed at the end of Section 2.2.1 would generally
require two appointments, or 12 bytes, per RBridge. With allowance
for sub-TLV and TLV overhead, appointments for 83 RBridges would fit
in under 1000 bytes. Including the DRB, this implies a link with 84
or more RBridges attached. Links with more than a handful of
RBridges attached are expected to be rare. And in any case such
limitations are easily avoided by using E-L1CS FS-LSP appointment.
2.3 Local Configuration Action Appointment Effects
Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder
status that RBridge has for VLAN-x unless VLAN-x is enabled on some
D. Eastlake, et al [Page 11]
INTERNET-DRAFT TRILL: Appointed Forwarders
other port that the RBridge has connected to the same link.
Configuring a port as a trunk port or point-to-point port revokes any
Appointed Forwarder status that depends on enabled VLANs at that
port.
Causing a port to no longer be configured as a trunk or point-to-
point port or enabling VLAN-x on a port does not necessarily cause
the RBridge to become an Appointed Forwarder for the link that port
is on. However, such actions allow the port's RBridge to become
Appointed Forwarder by choice if it is the DRB or, if it is not the
DRB on the link, by appointment as indicated by the Hello or E-L1CS
FS-LSP appointment databases.
2.4 Overload and Appointed Forwarders
A TRILL switch in link state overload [rfc7180bis] will, in general,
do a poorer job of ingressing and forwarding frames than a TRILL
switch not in overload and that has full knowledge of the campus
topology. For example, as explained in [rfc7180bis], an overloaded
TRILL switch may not be able to distribute multi-destination TRILL
Data frames at all.
Therefore, the DRB SHOULD NOT appoint an RBridge in overload as an
Appointed Forwarder unless there is no alternative. Furthermore, if
an Appointed Forwarder becomes overloaded, the DRB SHOULD re-assign
VLANs from the overloaded RBridge to another RBridge on the link that
is not overloaded, if one is available. A counter-example would be
if all campus end stations in VLAN-x were on links attached to RB1
via ports where VLAN-x was enabled. In such a case, RB1 SHOULD be
made the VLAN-x Appointed Forwarder on all such links even if RB1 is
overloaded.
DRB election is not affected by overload but a TRILL switch in
overload MAY reduce its own priority to be DRB.
2.5 VLAN Mapping within a Link
TRILL Hellos include a field that is set to the VLAN in which they
are sent when they are send on a link technology such as Ethernet
that has outer VLAN labeling. (For link technologies such as PPP
that do not have outer VLAN labeling, this Hello field is ignored.)
If a TRILL Hello arrives on a different VLAN than it was sent on,
then VLAN mapping is occurring within the link. VLAN mapping between
VLAN-x and VLAN-y can lead to a loop if the Appointed Forwarders for
the VLANs are different. If such mapping within a link was allowed
and occurred on two or more links so that there was a cycle of VLAN
D. Eastlake, et al [Page 12]
INTERNET-DRAFT TRILL: Appointed Forwarders
mappings, a broadcast frame, for example, would loop forever.
To prevent this potential problem, if the DRB on a link detects VLAN
mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it
MUST make or revoke appointments so as to assure that the same
RBridge (possibly the DRB) is the Appointed Forwarder on the link for
both VLAN-x and VLAN-y.
D. Eastlake, et al [Page 13]
INTERNET-DRAFT TRILL: Appointed Forwarders
3. The Inhibition Mechanism
A TRILL switch has, for every link on which it can offer end station
service (that is every link for which it can act as an Appointed
Forwarder), the following timers denominated in seconds:
- a DRB inhibition timer,
- a root change inhibition timer, and
- up to 4,094 VLAN inhibition timers, one for each legal VLAN ID.
The DRB and root change inhibition timers MUST be implemented.
The loss of native traffic due to inhibition will be minimized by
logically implementing a VLAN inhibition timer per each VLAN for
which end station service will ever be offered by the RBridge on the
link; this SHOULD be done. (See the Appendix for an example
motivating VLAN inhibition timers.) However, if implementation
limitations make a full set of such timers impractical, the VLAN
inhibition timers for more than one VLAN can, with care, be merged
into one timer. In particular, an RBridge MUST NOT merge the VLAN
inhibition timers together for two VLANs if it is the Appointer
Forwarder for one and not for the other, as this can lead to
unnecessary indefinitely prolonged inhibition. In the limit, there
will be safe operations, albeit with more native frame loss than
would otherwise be required, even if only two VLAN inhibition timers
are provided: one for VLANs for which the RBridge is the Appointed
Forwarder and one for all other VLANs. Thus, at least two VLAN
inhibition timers MUST be implemented. Where a VLAN inhibition timer
represents more than one VLAN, an update or test that would have been
done to the timer for any of the VLANs is performed on the merged
timer.
These timers are set as follows:
1. On booting or management reset, each port will have its own set of
timers, even if two or more such ports are on the same link,
because the TRILL switch will not have had a chance to learn that
yet. All inhibition timers are set to expired except the DRB
inhibition timer that is set in accordance with item 2 below. The
DRB inhibition timer is handled differently because each port will
initially believe it is the DRB.
2. When a TRILL switch decides that it has become the DRB on a link,
including when it is first booted or reset by management, it sets
the DRB inhibition timer to the Holding Time of its port on that
link that won the DRB election.
3. When a TRILL switch decides that it has lost DRB status on a link,
D. Eastlake, et al [Page 14]
INTERNET-DRAFT TRILL: Appointed Forwarders
it sets the DRB inhibition timer to expired.
Note: In the corner case where one port of a TRILL switch was the DRB
election winner, but later lost the DRB election to a different
port of the same TRILL switch on that link (perhaps due to
management configuration of port priority), neither 2 nor 3 above
applies, and the DRB timer is not changed.
4. When a TRILL switch RB1 receives a TRILL Hello asserting that the
sender is the Appointed Forwarder and that Hello either (1)
arrives on VLAN-x or (2) was sent on VLAN-x as indicated inside
the Hello, then RB1 sets its VLAN-x inhibition timer for the link
to the maximum of that timer's existing value and the Holding Time
in the received Hello. A TRILL switch MUST maintain VLAN
inhibition timers for a link to which it connects if it can offer
end station service on that link even if it is not currently
Appointed Forwarder for any VLAN on that link.
5. When a TRILL switch RB1 enables VLAN-x on a port connecting to a
link and VLAN-x was previously not enabled on any of RB1's ports
on that link, it sets its VLAN inhibition timer for VLAN-x for
that link to its Holding Time for that port. This is done even if
the port is configured as a trunk or point-to-point port as long
as there is some chance it might later be configured not to be a
trunk or point-to-point port. Remember, inhibition has no effect
on TRILL Data or IS-IS packets.
6. When a TRILL switch detects a change in the common spanning tree
root bridge on a port, it sets its root change inhibition timer
for the link to an amount of time that defaults to 30 seconds and
is configurable to any value from 30 down to zero seconds. This
condition will not occur unless the TRILL switch is receiving
Bridge PDU (BPDUs) on the port from an attached bridged LAN; if no
BPDUs are being received, the root change inhibition timer will
never be set. It is safe to configure this inhibition time to the
settling time of an attached bridged LAN. For example, if it is
known that Rapid Spanning Tree Protocol (RSTP [802.1Q]) is running
throughout the attached bridged LAN, it is safe to configure this
inhibition time to 7 seconds or, if the attached bridges have been
configured to have a minimum Bridge Hello Timer, safe to configure
it to 4 seconds.
7. When a TRILL switch decides that one of its ports (or a set of its
ports) P1 is on the same link as another of its ports (or set of
its ports) P2, then the inhibition timers are merged to a single
set of inhibition timers by using the maximum value of the
corresponding timers.
8. When an RBridge decides that a set of its ports that it had been
treating as being on the same link are no longer on the same link,
D. Eastlake, et al [Page 15]
INTERNET-DRAFT TRILL: Appointed Forwarders
those ports will necessarily be on two or more links (one link per
port in the limit). This is handled by cloning a copy of the
timers for each of the two or more links to which the TRILL switch
has decided these ports connect.
3.1 Inhibited Appointed Forwarder Behavior
Inhibition has no effect on the receipt or forwarding of TRILL Data
packets or TRILL IS-IS packets. It only affects ingressing and
egressing native frames.
An Appointed Forwarder for a link is inhibited for VLAN-x if:
1. its DRB inhibition timer for that link is not expired, or
2. its root change inhibition timer for that link is not expired, or
3. its VLAN inhibition timer for that link for VLAN-x is not expired.
If a VLAN-x Appointed Forwarder for a link is inhibited and receives
a TRILL Data packet whose encapsulated frame would normally be
egressed to that link in VLAN-x, it decapsulates the native frame as
usual. However, it does not output it to or queue it for that link,
although, if appropriate (for example, the frame is multi-
destination), it may output it to or queue it for other links.
If a VLAN-x Appointed Forwarder for a link is inhibited and receives
a native frame in VLAN-x that would normally be ingressed from that
link, the native frame is ignored except for address learning.
An TRILL switch with one or more unexpired inhibition timers,
possibly including an unexpired inhibition timer for VLAN-x, is still
required to indicate in TRILL Hellos it sends on VLAN-x whether or
not it is Appointed Forwarder for VLAN-x for the port on which it
sends the Hello.
D. Eastlake, et al [Page 16]
INTERNET-DRAFT TRILL: Appointed Forwarders
4. Optional TRILL Hello Reduction
If a network manager has sufficient confidence that they know the
configuration of bridges, ports, and the like, within a link, they
may be able to reduce the number of TRILL Hellos sent on that link by
sending Hellos in fewer VLANs; for example, if all TRILL switches on
the link will see all Hellos regardless of VLAN constraints.
However, because adjacencies are established in the Designated VLAN,
an RBridge MUST always attempt to send Hellos in the Designated VLAN.
Hello reduction makes TRILL less robust in the face of decreased VLAN
connectivity within a link, such as partitioned VLANs, many VLANs
disabled on ports, or disagreement over the Designated VLAN; however,
as long as all RBridge ports on the link are configured for the same
desired Designated VLAN, can see each other's frames in that VLAN,
and utilize the mechanisms specified below to update VLAN inhibition
timers, operations will be safe. (These considerations do not arise
on links between RBridges that are configured as point-to-point
since, in that case, each RBridge sends point-to-point Hellos, other
TRILL IS-IS PDUs, and TRILL Data frames only in what it believes to
be the Designated VLAN of the link (although it may send them un-
tagged) and no native frame end-station service is provided. Thus,
for such links, there is no reason to send Hellos in any other VLAN
than the Designated VLAN.)
The provision for a configurable set of "Announcing VLANs", as
described in Section 4.4.3 of [RFC6325], provides a mechanism in the
TRILL base protocol for a reduction in TRILL Hellos.
To maintain loop safety in the face of occasional lost frames,
RBridge failures, link failures, new RBridges coming up on a link,
and the like, the inhibition mechanism specified in Section 3 is
still required. Strictly following Section 3, a VLAN inhibition timer
can only be set by the receipt of a Hello sent or received in that
VLAN. Thus, to safely send a reduced number of TRILL Hellos on a
reduced number of VLANs requires additional mechanisms to set the
VLAN inhibition timers at an RBridge, thus extending Section 3. Two
such mechanisms are specified below. Support for both of these
mechanisms is indicated by a capability bit in the PORT-TRILL-VER
sub-TLV (Section 5.4 of [RFC7176]). It may be unsafe for an RBridge
to send TRILL Hellos on fewer VLANs than the set of VLANs recommended
in [RFC6325] on a link unless all its adjacencies on that link
(excluding those in the Down state [RFC7177]) indicate support of
these mechanisms and these mechanisms are in use.
1. An RBridge RB2 MAY include in any TRILL Hello an Appointed
Forwarders sub-TLV [RFC7176] appointing itself for one or more
ranges of VLANs. The Appointee Nickname field(s) in the Appointed
Forwarder sub-TLV MUST be the same as the Sender Nickname in the
Special VLANs and Flags sub-TLV in the TRILL Hello. This
D. Eastlake, et al [Page 17]
INTERNET-DRAFT TRILL: Appointed Forwarders
indicates the sending RBridge believes it is Appointed Forwarder
for those VLANs. An RBridge receiving such a sub-TLV sets each of
its VLAN inhibition timers for every VLAN in the block or blocks
listed in the Appointed Forwarders sub-TLV to the maximum of its
current value and the Holding Time of the Hello containing the
sub-TLV. This is backward compatible because such sub-TLVs will
have no effect on any receiving RBridge not implementing this
mechanism unless RB2 is the DRB (Designated RBridge) sending
Hellos on the Designated VLAN, in which case RB2 MUST include in
the Hello all forwarder appointments, if any, for RBridges other
than itself on the link.
2. An RBridge MAY use the VLANs Appointed sub-TLV [RFC7176]. When
RB1 receives a VLANs Appointed sub-TLV in a TRILL Hello from RB2
on any VLAN, RB1 updates the VLAN inhibition timers for all the
VLANs that RB2 lists in that sub-TLV as VLANs for which RB2 is
Appointed Forwarder. Each such timer is updated to the maximum of
its current value and the Holding Time of the TRILL Hello
containing the VLANs Appointed sub-TLV. This sub-TLV will be an
unknown sub-TLV to RBridges not implementing it, and such RBridges
will ignore it. Even if a TRILL Hello sent by the DRB on the
Designated VLAN includes one or more VLANs Appointed sub- TLVs, as
long as no Appointed Forwarders sub-TLVs appear, the Hello is not
required to indicate all forwarder appointments.
Two different encodings are providing above to optimize the listing
of VLANs. Large blocks of contiguous VLANs are more efficiently
encoded with the Appointed Forwarders sub-TLV, and scattered VLANs
are more efficiently encoded with the VLANs Appointed sub-TLV. These
encodings may be mixed in the same Hello. The use of these sub-TLVs
does not affect the requirement that the "AF" bit in the Special
VLANs and Flags sub-TLV MUST be set if the originating RBridge
believes it is Appointed Forwarder for the VLAN in which the Hello is
sent.
If the above mechanisms are used on a link, then each RBridge on the
link MUST send Hellos in one or more VLANs with such VLANs Appointed
sub-TLV(s) and/or self-appointment Appointed Forwarders sub-TLV(s),
and the "AF" bit MUST be appropriately set such that no VLAN
inhibition timer will improperly expire unless three or more Hellos
are lost. For example, an RBridge could announce all VLANs for which
it believes it is Appointed Forwarder in a Hello sent on the
Designated VLAN three times per Holding Time.
D. Eastlake, et al [Page 18]
INTERNET-DRAFT TRILL: Appointed Forwarders
5. Multiple Ports on the Same Link
A TRILL switch may have multiple ports on the same link. Some of
these ports may be suspended due to MAC address duplication as
described in [RFC7177]. Suspended ports never ingress or egress
native frames.
If an TRILL switch has one or more non-suspended ports on a link and
those ports offer end station service, that is, those ports are not
configured as point-to-point or trunk ports, then that TRILL switch
is eligible to be an Appointed Forwarder for that link. It can
become Appointed Forwarder either by its choice, because it is the
DRB, or by appointment by the DRB as described in Sections 2.1 and
2.2.
If a TRILL switch that is the Appointed Forwarder for VLAN-x on a
link has multiple non-suspended ports on that link, it may load share
the task of ingressing and egressing VLAN-x native frames across
those ports however it chooses, as long as there is no case in which
a frame it egresses onto the link from one port can be ingressed on
another of its ports, creating a loop. If the TRILL switch is the
Appointed Forwarder for multiple VLANs, a straightforward thing to do
would be to partition those VLANs among the ports it has on the link.
D. Eastlake, et al [Page 19]
INTERNET-DRAFT TRILL: Appointed Forwarders
6. VLAN-FGL Mapping Consistency Checking
TRILL switches support 24-bit Fine Grained Labels as specified in
[RFC7172]. Basically a VLAN ID in native traffic between an edge
TRILL switch and an end station is mapped to/from an FGL as an
Inner.Label in TRILL Data packets. Since the Appointed Forwarder for
a VLAN will be ingressing and egressing such native traffic, the
mapping configured at the Appointed Forwarder is the mapping
performed.
However, the Appointed Forwarder for VLAN-x on a link can change for
reasons discussed elsewhere in this document. Thus all TRILL switches
on a link that are configured with a VLAN-FGL mapping SHOULD be
configured with the same mapping. Otherwise, for example, traffic
might unpredictably jump from one FGL to another. TRILL switches
SHOULD advertise their mapping on the link using the VLAN-FGL-Bitmap
and VLAN-FGL-Pairs APPsub-TLVs (Sections 9.4 and 9.5).
A TRILL switch SHOULD compare the VLAN-FGL mappings that it sees
advertised by other TRILL switches on a link with its own and alert
the network operator if they are inconsistent. Inconsistent means
that (1) one TRILL switch maps VLAN-x to FGL-w while another maps
VLAN-x to FGL-z or (2) one TRILL switch maps FGL-z to VLAN-x while
another maps FGL-z to VLAN-y, all on the same link.
Depending of how the network is being managed, a transient
inconsistency may not be a problem. Thus the network operator SHOULD
NOT be alerted unless the inconsistency persists for a period of time
which defaults to the TRILL switch's holding time and is configurable
to between zero and 2**16 - 1 seconds where 2**16 - 1 is a special
value and indicates that such alerts are disabled.
D. Eastlake, et al [Page 20]
INTERNET-DRAFT TRILL: Appointed Forwarders
7. Support of E-L1CS
All TRILL switches MUST support the E-L1CS flooding scope [RFC7356]
E-L1FS flooding scope [rfc7180bis] and base LSPs [IS-IS]. It will be
apparent to any TRILL switch on a link if any other TRILL switch is a
legacy implementation not supporting E-L1CS because, as stated in
[rfc7180bis], all TRILL switches MUST include a Scoped Flooding
Support TLV [RFC7356] in all TRILL Hellos they send. This support of
E-L1CS increases the amount of information from each TRILL switch
that can be synchronized on the link, compared with the information
capacity of a Hello, by several orders of magnitude.
For robustness, all E-L1CS PDUs (FS-LSP fragments, E-L1CS FS-CSNPs,
and E-L1CS FS-PSNPs) MUST NOT exceed 1470 bytes in length; however,
any such E-L1CS PDU that is received that is longer than 1470 bytes
is processed normally.
As with any type of IS-IS LSP, FS-LSPs are identified by the System
ID of the originating router (TRILL switch) and the fragment number.
In particular, there is no port identifier in the header of a E-L1CS
PDU. Thus a TRILL switch RB1 with more than one non-suspended port on
a link (Section 5) transmitting such a PDU MAY transmit it out any
one or more of such ports. RB1 will generally receive such a PDU that
other TRILL switches send on all of RB1's ports on the link and any
such PDU RB1 sends on the ports RB1 has on the link other than the
transmitting port.
7.1 Backwards Compatibility
Future TRILL specifications making use of E-L1CS MUST specify how
situations involving a TRILL link will be handled when one or more
TRILL switches attached to that link support E-L1CS and one or more
do not.
D. Eastlake, et al [Page 21]
INTERNET-DRAFT TRILL: Appointed Forwarders
8. Security Considerations
This memo provides improved documentation of the TRILL Appointed
Forwarder mechanism. It does not change the security considerations
of the TRILL base protocol as described in Section 6 of [RFC6325].
The E-L1CS FS-LSPs added by Section 6 are securable with [RFC5310]
Authentication TLVs in the same way as Hellos or other IS-IS PDUs.
D. Eastlake, et al [Page 22]
INTERNET-DRAFT TRILL: Appointed Forwarders
9. Code Points and Data Structures
This section provides IANA Considerations for this document and
specifies the structure of the Appointment Bitmap, Appointment List,
VLAN-FGL Mapping Bit Map, and VLAN-FGL Mapping Pairs APPsub-TLVs.
These APPsub-TLVs appears within a TRILL GENINFO TLV [RFC7357] in E-
L1CS FS-LSPs [RFC7356].
9.1 IANA Considerations
IANA is requested to assign four new APPsub-TLV type codes from the
range below 255 and enter them in the "TRILL APPsub-TLV Types under
IS-IS TLV 251 Application Identifier 1" Registry as follows:
Type Name Reference
---- ----------------- ---------------
tbd1 AppointmentBitmap [this document]
tbd2 AppointmentList [this document]
tbd3 VLAN-FGL-Bitmap [this document]
tbd4 VLAM-FGL-Pairs [this document]
IANA is requested to update the reference for the "Hello reduction
support" bit in the "PORT-TRILL-VER Sub-TLV Capability Flags"
registry on the TRILL Parameters IANA web page to refer to this
document.
9.2 Appointment Bitmap APPsub-TLV
The Appointment Bitmap APPsub-TLV provides an efficient method for a
TRILL switch to indicate which TRILL switches it appoints as
forwarders for which VLAN IDs when those VLAN IDs are relatively
compact, that is, they do not span a large numeric range. Such
appointment is only effective when the appointing TRILL switch is
DRB.
D. Eastlake, et al [Page 23]
INTERNET-DRAFT TRILL: Appointed Forwarders
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
o Type: APPsub-TLV type, set to AppointmentBitmap sub-TLV tbd1.
o Length: 4 + size of bit map in bytes. If Length is less than 4,
the APPsub-TLV is corrupt and MUST be ignored.
o Appointee Nickname: The nickname of the TRILL switch being
appointed a forwarder.
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o Starting VLAN ID: The smallest VLAN ID to which the bits in the
Bit Map correspond.
o Bit Map: A bit map of the VLANs for which the TRILL switch with
appointee nickname is appointed the forwarder. The size of the bit
map is length minus 4. If the size of the bit map is zero, no
appointments are made.
Each bit in the Bit Map corresponds to a VLAN ID. Bit 0 is for the
VLAN whose ID appears in the Starting VLAN field. Bit 1 is for that
VLAN ID plus 1 (treating VLAN IDs as unsigned integers) and so on
with Bit N generally being Starting VLAN ID plus N. VLAN 0x000 and
VLAN 0xFFF or any larger ID are invalid and are ignored.
If the Appointment Bitmap APPsub-TLV is originated by the DRB on a
link, it appoints the TRILL switch whose nickname appears in the
Appointee Nickname field for the VLAN IDs corresponding to 1 bits in
the Bit Map and revokes any Hello appointment of that TRILL switch
for VLANs corresponding to 0 bits in the Bit Map.
9.3 Appointment List APPsub-TLV
The Appointment List APPsub-TLV provides a convenient method for a
TRILL switch to indicate which TRILL switches it appoints as
D. Eastlake, et al [Page 24]
INTERNET-DRAFT TRILL: Appointed Forwarders
forwarders for which VLAN IDs. Such appointment is only effective
when the appointing TRILL switch is DRB.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 1 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID 2 | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID k | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: APPsub-TLV type, set to AppointmentList sub-TLV tbd2.
o Length: 4*k. If Length is not a multiple of 4, the APPsub-TLV
is corrupt and MUST be ignored.
o Appointee Nickname: The nickname of the TRILL switch being
appointed a forwarder.
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o VLAN ID: A 12-bit VLAN ID for which appointee is being
appointed the forwarder.
Type and Length are 2 bytes because these are extended FS-LSPs.
This APPsub-TLV appoints the TRILL switch with Appointee Nickname to
be the Appointed Forwarder for the VLAN IDs listed.
9.4 VLAN-FGL Mapping Bitmap APPsub-TLV
The VLAN-FGL Mapping Bitmap APPsub-TLV provides a method for a TRILL
switch to indicate the VLAN ID to FGL mappings it is configured to
perform when ingressing and egressing native frames. The coding is
efficient when the VLAN IDs are compact, that is, they do not span a
large numeric range.
D. Eastlake, et al [Page 25]
INTERNET-DRAFT TRILL: Appointed Forwarders
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Starting VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit Map ... (variable)
+-+-+-+-+-+-+-+-...
o Type: APPsub-TLV type, set to VLAN-FGL-Bitmap sub-TLV tbd3.
o Length: 5 + size of bit map in bytes. If Length is less than 5,
the APPsub-TLV is corrupt and MUST be ignored.
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o Starting VLAN ID: Initial VLAN ID for the mapping information
as discussed below.
o FGL: Fine Grained Label [RFC7172]
o Bit Map: Map of bits for VLANs to FGL mappings. The size of the
bit map is Length minus 5. If the size of the bit map is zero, no
mappings are indicated.
Each bit in the Bit Map corresponds to a VLAN ID and to an FGL. Bit 0
is for the VLAN whose ID appears in the Starting VLAN field and the
Fine Grained Label that appears in the FGL field. Bit 1 is for that
VLAN ID plus 1 and that FGL plus 1 (treating VLAN IDs and FGLs as
unsigned integers) and so on with Bit N generally being Starting VLAN
ID plus N and FGL plus N.
If a Bit Map bit is a 1, it indicates that the advertising TRILL
switch will map between the corresponding VLAN ID and FGL on
ingressing native frames and egressing TRILL Data packets if it is
Appointed Forwarder for the VLAN. If a Bit Map bit is a 0, it does
not indicate any configured VLAN ID to FGL mapping. However, VLAN ID
0x000 and VLAN ID 0xFFF or any larger ID are invalid and FGLs larger
than 0xFFFFFF are invalid; any Bit Map bits that corresponds to an
illegal VLAN ID or illegal FGL is ignored.
D. Eastlake, et al [Page 26]
INTERNET-DRAFT TRILL: Appointed Forwarders
9.5 VLAN-FGL Mapping Pairs APPsub-TLV
The VLAN-FGL Mapping Pairs APPsub-TLV provides a method for a TRILL
switch to indicate a list of VLAN ID to FGL mappings it is configured
to perform when ingressing and egressing native frames.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 1 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD 2 | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
| Mapping RECORD k | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=-+-...-+-+-+
Where a Mapping RECORD has the following structure:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FGL | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: APPsub-TLV type, set to VLAN-FGL-Pairs sub-TLV tbd4.
o Length: 5*k. If Length is not a multiple of 5, the APPsub-TLV
is corrupt and MUST be ignored.
o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o VLAN ID: 12-bit VLAN label.
o FGL: Fine Grained Label [RFC7172]
Each Mapping RECORD indicates that the originating TRILL switch is
configured to map between the VLAN and FGL given on ingressing and
egressing native frames. However, VLAN ID 0x000 and VLAN ID 0xFFF
are invalid; any Mapping RECORD that corresponds to an illegal VLAN
ID is ignored.
D. Eastlake, et al [Page 27]
INTERNET-DRAFT TRILL: Appointed Forwarders
Normative References
[802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
networks - Virtual Bridged Local Area Networks", IEEE Std
802.1Q-2014, 19 December 2014.
[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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4971] - Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
"Intermediate System to Intermediate System (IS-IS) Extensions
for Advertising Router Information", RFC 4971, July 2007,
<http://www.rfc-editor.org/info/rfc4971>.
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011, <http://www.rfc-
editor.org/info/rfc6325>.
[RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq
Shortest Path Bridging", RFC 6329, April 2012, <http://www.rfc-
editor.org/info/rfc6329>.
[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,
<http://www.rfc-editor.org/info/rfc7172>.
[RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", RFC 7176, May 2014,
<http://www.rfc-editor.org/info/rfc7176>.
[RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H.,
and V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014, <http://www.rfc-
editor.org/info/rfc7177>.
[RFC7356] - Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356, September 2014,
<http://www.rfc-editor.org/info/rfc7356>.
[RFC7357] - Zhai, H., Hu, F., Perlman, R., Eastlake 3rd, D., and O.
D. Eastlake, et al [Page 28]
INTERNET-DRAFT TRILL: Appointed Forwarders
Stokes, "Transparent Interconnection of Lots of Links (TRILL):
End Station Address Distribution Information (ESADI) Protocol",
RFC 7357, September 2014, <http://www.rfc-
editor.org/info/rfc7357>.
[rfc7180bis] - Eastlake, D., Zhang, M., Perlman, R. Banerjee, A.,
Ghanwani, A., and S. Gupta, "TRILL: Clarifications,
Corrections, and Updates", Draft-ietf-trill-rfc7180bis, work in
progress.
Informative References
[RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
6439, November 2011, <http://www.rfc-editor.org/info/rfc6439>.
[RFC7180] - Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V.,
and A. Banerjee, "Transparent Interconnection of Lots of Links
(TRILL): Clarifications, Corrections, and Updates", RFC 7180,
May 2014, <http://www.rfc-editor.org/info/rfc7180>.
[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, October 2014, <http://www.rfc-
editor.org/info/rfc7379>
D. Eastlake, et al [Page 29]
INTERNET-DRAFT TRILL: Appointed Forwarders
Acknowledgements
The following are hereby thanked for their contributions to this
document:
Mingui Zhang
The following were acknowledged and thanked by in [RFC6439] or were
an author of [RFC6439], the predecessor to this document:
Ron Bonica, Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik
Nordmark, Radia Perlman, Dan Romascanu, and Mike Shand.
D. Eastlake, et al [Page 30]
INTERNET-DRAFT TRILL: Appointed Forwarders
Authors' Addresses
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China
Phone: +86-25-56622310
EMail: liyizhou@huawei.com
Mohammad Umair
IPinfusion
EMail: mohammed.umair2@ipinfusion.com
Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134 USA
Phone: +1-408-333-7149
EMail: ayabaner@cisco.com
Fangwei Hu
ZTE Corporation
889 Bibo Road
Shanghai 201203
China
Phone: +86-21-68896273
EMail: hu.fangwei@zte.com.cn
D. Eastlake, et al [Page 31]
INTERNET-DRAFT TRILL: Appointed Forwarders
Appendix A: VLAN Inhibition Example
The per-VLAN inhibition timers (or the equivalent) are needed to be
loop safe in the case of misconfigured bridges on a link.
For a simple example, assume that RB1 and RB2 are the only RBridges
on the link, that RB1 is higher priority to be the DRB, and that they
both want VLAN 1 (the default) to be the Designated VLAN. However,
there is a bridge between them configured so that RB1 can see all the
frames sent by RB2 but none of the frames from RB1 can get through to
RB2.
Both will think they are the DRB. RB1 because it is higher priority
even though it sees the Hellos from RB2, and RB2 because it doesn't
see the Hellos from RB1 and therefore thinks it is highest priority.
Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while
RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There
is no problem with VLANs 2 and 4 but if you do not do something about
it, you could have a loop involving VLAN 3. RB1 will see the Hellos
RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1
will be inhibited on VLAN 3. RB2 does not see the Hellos issued by
RB1 on VLAN 3, so RB2 will become uninhibited and will handle VLAN 3
native traffic.
However, this situation may change. RB2 might crash, the bridge
might crash, or RB2 might be reconfigured so it no longer tried to
act as Appointed Forwarder for VLAN 3, or other issues may occur.
So, RB1 has to maintain a VLAN 3 inhibition timer, and if it sees no
Hellos from any other RBridge on the link claiming to be Appointed
Forwarder for VLAN 3 in a long enough time, then RB1 becomes
uninhibited for that VLAN on the port in question and can handle end
station traffic in VLAN 3.
D. Eastlake, et al [Page 32]
INTERNET-DRAFT TRILL: Appointed Forwarders
Appendix B: Changes to [RFC6325] and [RFC6439]
This document updates [RFC6325] and obsoletes [RFC6439].
Changes to [RFC6325] are as follows:
Addition of mandatory support for E-L1CS FS-LSPs.
Changes from [RFC6439] are as follows"
1. Specify APPsub-TLVs and procedures to be used in E-L1CS FS-LSP
forwarder appointments.
2. Incorporate updates to [RFC6439] that appeared in Section 10 of
[RFC7180] which has been obsoleted by [rfc7180bis]. They appear
primarily in Section 4 of this document.
3. Add optional VLAN-FGL consistency check feature including
specification of APPsub-TLVs.
4. Delete references to draft-ietf-trill-rbridge-vlan-mapping
which has been dropped by the TRILL WG.
5. Eliminate requirement that the DRB not send appointments in
Hellos until its DRB inhibition timer has expired. This was an
unnecessary safety precaution which is pointless given that
appointments in E-L1CS FS-LSPs are immediately visible.
6. Editorial changes.
D. Eastlake, et al [Page 33]
INTERNET-DRAFT TRILL: Appointed Forwarders
Appendix Z: Change Record
This appendix summarizes changes between versions of this draft.
RFC Editor: Please delete this Appendix before publication.
D. Eastlake, et al [Page 34]
INTERNET-DRAFT TRILL: Appointed Forwarders
Copyright and 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 35]
| PAFTECH AB 2003-2026 | 2026-04-23 16:14:31 |