Routing Bridges (RBridges): Appointed Forwarders
draft-ietf-trill-rbridge-af-05
The information below is for an old version of the document that is already published as an RFC.
| Document | Type | RFC Internet-Draft (trill WG) | |
|---|---|---|---|
| Authors | Radia Perlman , Ayan Banerjee , fangwei hu , Donald E. Eastlake 3rd , Yizhou Li | ||
| Last updated | 2018-12-20 (Latest revision 2011-09-26) | ||
| Replaces | draft-perlman-trill-rbridge-af | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | (None) | ||
| IESG | IESG state | RFC 6439 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Ralph Droms | ||
| IESG note | Erik Nordmark (nordmark@acm.org) is the document shepherd. | ||
| Send notices to | (None) |
draft-ietf-trill-rbridge-af-05
TRILL Working Group Radia Perlman
INTERNET-DRAFT Intel Labs
Intended status: Proposed Standard Donald Eastlake
Updates: 6325 Yizhou Li
Huawei
Ayan Banerjee
Cisco
Hu Fangwei
ZTE
Expires: March 25, 2012 September 26, 2011
RBridges: Appointed Forwarders
<draft-ietf-trill-rbridge-af-05.txt>
Abstract
The IETF TRILL (TRansparent Interconnection of Lots of Links)
protocol provides least cost pair-wise data forwarding without
configuration in multi-hop networks with arbitrary topology, 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) link state routing and by encapsulating traffic using a
header that includes a hop count. Devices that implement TRILL are
called RBridges.
TRILL supports multi-access LAN (Local Area Network) links that can
have multiple end stations and RBridges attached. Where multiple
RBridges are attached to a link, native traffic to and from end
stations on that link is handled by a subset of those RBridges called
Appointed Forwarders, with the intent that native traffic in each
VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of
this document is to improve the documentation of the Appointed
Forwarder mechanism and thus it updates RFC 6325.
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 <rbridge@postel.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
R. Perlman, et al [Page 1]
INTERNET-DRAFT RBridges: Appointed Forwarders
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
Acknowledgements
The authors of [RFC6325] and [RFC6327], those listed in the
Acknowledgements section of [RFC6325] and [RFC6327], and Ron Bonica,
Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan
Romascanu, and Mike Shand are hereby thanked for their contributions.
R. Perlman, et al [Page 2]
INTERNET-DRAFT RBridges: Appointed Forwarders
Table of Contents
1. Introduction............................................4
1.1 Terminology and Acronyms...............................5
2. Appointed Forwarders and Their Appointment..............6
2.1 Appointment Effects of DRB Elections...................6
2.2 Appointment and Removal by the DRB.....................7
2.2.1 Processing Forwarder Appointments....................7
2.2.2 Frequency of Appointments............................9
2.2.3 Appointed Forwarders Limit...........................9
2.3 Local Configuration Action Appointment Effects........10
2.4 VLAN Mapping Within a Link............................10
3. The Inhibition Mechanism...............................12
4. Inhibited Appointed Forwarder Behavior.................15
5. Multiple Ports on the Same Link........................16
6. Security Considerations................................17
7. IANA Considerations....................................17
8. References.............................................18
8.1 Normative References..................................18
8.2 Informative References................................18
Authors' Addresses........................................19
Appendix: VLAN Inhibition Example.........................20
Appendix Z: Change Record.................................21
R. Perlman, et al [Page 3]
INTERNET-DRAFT RBridges: Appointed Forwarders
1. Introduction
The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol [RFC6325] provides optimal pair-wise data frame forwarding
without configuration in multi-hop networks with arbitrary topology,
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] [RFC1195] link state routing and encapsulating
traffic using a header that includes a hop count. The design supports
VLANs (Virtual Local Area Networks) and optimization of the
distribution of multi-destination frames based on VLANs and IP
derived multicast groups. Devices that implement TRILL are called
RBridges.
Section 2 of [RFC6327] explains 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 RBridges attached. Where multiple
RBridges are attached to a link, native traffic to and from end
stations on that link is handled by a subset of those RBridges called
Appointed Forwarders, with the intent that native traffic in each
VLAN be handled by at most one RBridge. An RBridge can be Appointed
Forwarder for many VLANs.
The purpose of this document is to improve the documentation of the
Appointed Forwarder mechanism and thus it updates RFC 6325. It
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 RBridge 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 affect on the formation of
adjacencies, the election of the DRB for a link, MTU matching, or
pseudonode formation. Those topics are covered in [RFC6327].
Furthermore, Appointed Forwarder status has no effect on the
forwarding of TRILL Data frames. It only affects the handling of
native frames.
For other aspects of the TRILL base protocol see [RFC6325] and
[RFC6327]. Familiarity with [RFC6325] and [RFC6327] is assumed in
this document. In case of conflict between this document and
[RFC6325], this document prevails.
R. Perlman, et al [Page 4]
INTERNET-DRAFT RBridges: Appointed Forwarders
1.1 Terminology and Acronyms
This document uses the acronyms defined in [RFC6325].
A "trunk port" is a port configured with the "end station service
disable" bit on, as described in Section 4.9.1 of [RFC6325].
In this document, the term "link" means "bridged LAN", that is to say
some combination of physical links with zero or more bridges, hubs,
repeaters, or the like.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
R. Perlman, et al [Page 5]
INTERNET-DRAFT RBridges: Appointed Forwarders
2. Appointed Forwarders and Their Appointment
The Appointed Forwarder on a link for VLAN-x is the 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 RBridges 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.4.) While TRILL tries to avoid such
situations, for loop safety there is also an "inhibition" mechanism
(see Section 3) that can cause an RBridge that is an Appointed
Forwarder to not ingress or egress native frames.
As discussed in Section 5, an RBridge may have multiple ports on a
link. As discussed in [RFC6327], if there are multiple ports with the
same MAC address on a link, all but one will be suspended. The case
of multiple ports on a link for one RBridge 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
one RBridge is expected to be a rare condition and duplicate MAC
addresses are not recommended by either TRILL or IEEE 802.1
standards.
Appointed Forwarder status has no affect on the forwarding of TRILL
Data frames. It only affects the handling of native frames.
There are three mechanisms by which an RBridge can be appointed or
un-appointed as Appointed Forwarder: as a result of DRB elections
[RFC6327] as discussed in Section 2.1, as a result of action by the
DRB as discussed in Section 2.2, as a result of a local configuration
action as discussed in Section 2.3.
2.1 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).
R. Perlman, et al [Page 6]
INTERNET-DRAFT RBridges: Appointed Forwarders
An RBridge loses all Appointed Forwarder status when
1. it decides that it has lost the status of being DRB for a link
or
2. it observes a change in the RBridge that is DRB for the link
without itself becoming DRB.
In the rare corner case where an RBridge has more than one port on a
link, one of which was previously the DRB election winner but that
port has just lost the DRB election to a different port of the same
RBridge (possibly due to management configuration of port
priorities), there is no change in which RBridge is DRB. Therefore
neither of the above points applies and there is no change in
Appointed Forwarder status.
2.2 Appointment and Removal by the DRB
The DRB may appoint other RBridges on the link through inclusion of
one or more Appointed Forwarders sub-TLVs [RFC6326] 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 for that link in that Hello. Any previous
appointment not included is implicitly revoked.
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 for RBridges other than
itself on the link, it is recommended that it send a TRILL Hello with
an appointment for itself for some VLAN.
The DRB MUST NOT send any appointments on a link unless its DRB
inhibition timer (see Section 3) for that link is expired.
How the DRB decides what other RBridges on the link, if any, to
appoint forwarder for which VLANs is beyond the scope of this
document.
2.2.1 Processing Forwarder Appointments
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 [RFC6327], 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 Appointed Forwarder sub-TLVs
in the Hello are ignored and there is no change in the receiving
RBridge's Appointed Forwarder status. Also, if no Appointed Forwarder
sub-TLVs are present in the TRILL Hello, there is no change in the
R. Perlman, et al [Page 7]
INTERNET-DRAFT RBridges: Appointed Forwarders
receiver's Appointed Forwarder status.
However, if the TRILL Hello is from the winning DRB port and the
Hello includes one or more Appointed Forwarder sub-TLVs, then the
receiving RBridge becomes appointed for 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.) If the receiver was
Appointed Forwarder for any other VLANs, its Appointed Forwarder
status for such other 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 and is no longer Appointed Forwarder for
any VLAN.
The handling of one or more Appointed Forwarder sub-TLVs in a Hello
from the winning port that appoint 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). If the RBridge was Appointed
Forwarder for any additional VLANs beyond the VLANs for which it was
being appointed, it loses Appointed Forwarder status for such
additional VLANs.
There is no reason for an RBridge to remember that it received a
valid appointment message for a VLAN that was ineffective because the
VLAN was not enabled on the port where the message 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 re-configured.
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 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 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
R. Perlman, et al [Page 8]
INTERNET-DRAFT RBridges: Appointed Forwarders
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.
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.2.2 Frequency of Appointments
It is not necessary for the DRB to include the 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). And it
is 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 Limit
The mechanism of DRB forwarder appointment and the limited length of
TRILL Hellos imposes a limit on the number of RBridges on a link that
can be Appointed Forwarders. 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 forwarders for arbitrary non-intersecting sets of
VLANs. Using the technique discussed above 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
R. Perlman, et al [Page 9]
INTERNET-DRAFT RBridges: Appointed Forwarders
RBridges attached. Links with more than a handful of RBridges
attached are expected to be rare.
(If the Designated VLAN were an extreme low or high value, such as
VLAN 1, which is the default and may be a common value in practice,
only 6 bytes per RBridge would be required. This would permit twice
as many different Appointed Forwarder RBridges than indicated by the
general analysis above or, alternatively, would take only half as
much space to appoint the same number of Appointed Forwarders.)
Unnecessary changes in Appointed Forwarders SHOULD NOT be made as
they may result in transient lack of end station service. Large
numbers of Appointed Forwarders on a link (in excess of 65) are NOT
RECOMMENDED due to the complexity of their establishment and
maintenance.
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
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, in itself, cause
the RBridge to become an Appointed Forwarder for the link that port
is on. However, such actions can allow the port's RBridge to become
Appointed Forwarder by choice if it is DRB or by appointment if it is
not DRB on the link.
2.4 VLAN Mapping Within a Link
TRILL Hellos include a field that is set to the VLAN in which they
are sent. If they arrive on a different VLAN, then VLAN mapping is
occurring within the link. (Such VLAN mapping within a link between
RBridges should not be confused with VLAN mapping inside an RBridge.
[VLANmap]) 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 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
R. Perlman, et al [Page 10]
INTERNET-DRAFT RBridges: Appointed Forwarders
MUST make or revoke appointments so as to assure that the same
RBridge (possibly the DRB) is Appointed Forwarder on the link for
both VLAN-x and VLAN-y.
R. Perlman, et al [Page 11]
INTERNET-DRAFT RBridges: Appointed Forwarders
3. The Inhibition Mechanism
An RBridge 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 and this SHOULD be done. (See 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 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 Appointed Forwarder and one for all other VLANs. 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 be 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, as even if two or more are on the same link as the
RBridge 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 DRB.
2. When an RBridge decides that it has become 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 an RBridge decides that it has lost DRB status on a link,
it sets the DRB inhibition timer to expired.
R. Perlman, et al [Page 12]
INTERNET-DRAFT RBridges: Appointed Forwarders
Note: In the rare corner case where one port of an RBridge was
the DRB election winner but later loses the DRB election to a
different port of the same RBridge 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 an RBridge RB1 receives a TRILL Hello asserting that the
sender is Appointed Forwarder that 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. An RBridge 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 an RBridge 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 be later
configured to not be a trunk or point-to-point port.
6. When an RBridge 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 RBridge is receiving
BPDUs on the port from an attached bridged LAN. 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 should be 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. Note that, while an RBridge could
determine what version of spanning tree is running on the
physical link between it and any directly connected bridge by
examination of the BPDUs it receives, it could not tell if
inter-bridge links beyond those directly connected bridges were
running classic Spanning Tree Protocol (STP), which might
require the root change inhibition timer to be set to 30
seconds for safety.
7. When an RBridge 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.
R. Perlman, et al [Page 13]
INTERNET-DRAFT RBridges: Appointed Forwarders
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, 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 the
RBridge has decided these ports connect to.
R. Perlman, et al [Page 14]
INTERNET-DRAFT RBridges: Appointed Forwarders
4. Inhibited Appointed Forwarder Behavior
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 frame whose encapsulated frame is in VLAN-x and would
normally be egressed to that link, it decapsulates the native frame
as usual. But 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 RBridge with one or more un-expired 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.
Inhibition has no effect on the receipt or forwarding of TRILL Data
frames.
R. Perlman, et al [Page 15]
INTERNET-DRAFT RBridges: Appointed Forwarders
5. Multiple Ports on the Same Link
An RBridge may have multiple ports on the same link. Some of these
ports may be suspended due to MAC address duplication as described in
[RFC6327]. Suspended ports never ingress or egress native frames.
If an RBridge 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 RBridge is
eligible to be an Appointed Forwarder for that link. It can become
Appointed Forwarder either by its choice because it is DRB, or by
appointment by the DRB as described in Sections 2.1 and 2.2.
If an RBridge which is 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 RBridge is Appointed Forwarder for
multiple VLANs, a straightforward thing to do would be to partition
those VLANs among the ports it has on the link.
R. Perlman, et al [Page 16]
INTERNET-DRAFT RBridges: Appointed Forwarders
6. 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. See Section 6 of [RFC6325].
7. IANA Considerations
This document requires no IANA actions. RFC Editor: Please delete
this section before publication.
R. Perlman, et al [Page 17]
INTERNET-DRAFT RBridges: Appointed Forwarders
8. References
Normative and Informational references for this document are listed
below.
8.1 Normative References
[802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
networks - Virtual Bridged Local Area Networks", IEEE Std
802.1Q-2011, May 2011.
[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.
[RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "Transparent Interconnection of Lots of Links (TRILL)
Use of IS-IS", RFC 6326, July 2011.
[RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
6327, July 2011.
8.2 Informative References
[VLANmap] - Perlman, R., D. Dutt, A. Banerjee, A. Rijhsinghani, D.
Eastlake, "RBridges: Campus VLAN and Priority Regions", draft-
ietf-trill-rbridge-vlan-mapping, work in progress.
R. Perlman, et al [Page 18]
INTERNET-DRAFT RBridges: Appointed Forwarders
Authors' Addresses
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054 USA
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Donald Eastlake
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
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
R. Perlman, et al [Page 19]
INTERNET-DRAFT RBridges: Appointed Forwarders
Appendix: 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 DRB, and that they
both want VLAN 1 (the default) to be the designated VLAN. But 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 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 so 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 and so RB1
will be inhibited on VLAN 3. RB2 does not see the Hellos issued by
RB1 on VLAN 3 and so RB2 will become uninhibited and will handle VLAN
3 native traffic.
But this situation may change. RB2 might crash or the bridge might
crash or RB2 might be re-configured so it no longer tried to act as
appointed forwarder for VLAN 3 or ... 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.
R. Perlman, et al [Page 20]
INTERNET-DRAFT RBridges: Appointed Forwarders
Appendix Z: Change Record
This appendix summarizes changes between versions of this draft.
RFC Editor: Please delete this Appendix before publication.
From -00 to -01
1. Clarify that an RBridge needs to check the source MAC, Port ID,
and System Id in received TRILL Hellos to determine whether
forwarder appointment sub-TLVs are ignored or take effect.
2. Note that RB1's Appointed Forwarder status for VLAN-x is cancelled
if VLAN-x is disabled on all ports RB1 has on a link.
3. Minor editorial changes.
From -01 to -02
1. Include additional appropriate references to configuring ports as
trunk ports or to no longer be trunk ports.
2. Minor editorial changes.
From -02 to -03
1. Add note on "trunk port" to Section 1.1.
2. Clarify that RBridges do not maintain state for AF appointments
that were ineffective due to being for a disabled VLAN, trunk
port, or point-to-point port.
3. Add material in Section 2.2.1 pointing to Item 4 in Section 3 as
the safety measure when you do have two AFs on a link for the same
VLAN.
4. Add VLAN inhibition timer example Appendix.
5. Provide that an inhibited AF can still learn end station addresses
from native frames it receives.
6. Minor editorial changes.
R. Perlman, et al [Page 21]
INTERNET-DRAFT RBridges: Appointed Forwarders
From -03 to -04
1. Add a definition of "link".
2. Specify that VLAN IDs 0x000 and 0xFFF are ignored in appointments.
3. Add Section 2.4 on VLAN Mapping Within a Link.
4. Note that a VLAN inhibition timer is set for the VLAN identified
inside an appropriate Hello as well as for the VLAN in which that
Hello is delivered.
5. Add to Section 2.2 a recommendation that, if the DRB wants to
clear all appointments, it just send a appointment for itself.
6. Minor editorial changes.
From -04 to -05
1. In Section 3, Item 6, correct the default safe RSTP root bridge
change inhibition timer value to 7 seconds and note that it
requires minimum Bridge Hello Timer configuration of attached
bridges to be able to safely reduce this to 4 seconds.
2. Update references for RFCs that have been published.
3. Add a few acknowledgements.
4. Note in the Abstract and Introduction that this document updates
RFC 6325.
5. Minor editorial changes.
R. Perlman, et al [Page 22]
INTERNET-DRAFT RBridges: Appointed Forwarders
Copyright and IPR Provisions
Copyright (c) 2011 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.
R. Perlman, et al [Page 23]