One document matched: draft-eastlake-trill-rbridge-notes-00.txt
Network Working Group Donald Eastlake 3rd
INTERNET-DRAFT Eastlake Enterprises
Intended status: Informational
Expires: February 19, 2009 August 20, 2008
Rbridge Notes
<draft-eastlake-trill-rbridge-notes-00.txt>
Status of This Document
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document provides additional informational material related to
RBridges, which are devices that implement the TRILL protocol. It is
a supplement to the RBridges base protocol specification and includes
discussion of tradeoffs in some features and configurations of
RBridges. In addition, it provides a sketch of a proof that, with
reasonable assumptions, persistent loops do not occur in a TRILL
campus.
D. Eastlake [Page 1]
INTERNET-DRAFT TRILL Header Options
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
2. Zero Configuration Comparison...........................4
2.1 IEEE 802.1D Bridges....................................4
2.2 IEEE 802.1Q Bridges....................................4
2.3 RBridges...............................................6
3. Pluses and Minuses......................................8
3.1 Trees and the Forest...................................8
3.2 Loop Safety............................................9
3.2.1 Loop Safety Mechanisms...............................9
3.2.2 Loop Safety Tradeoffs...............................10
4. No Persistent Loops....................................11
4.1 Categories of Loops...................................11
4.2 Analysis for a Single Pair of RBridges................12
4.3 Analysis for on Arbitrary Bridged LAN.................14
5. Security Considerations................................18
6. Normative References...................................18
7. Informative References.................................18
8. IANA Considerations....................................18
Disclaimer................................................19
Additional IPR Provisions.................................19
Author's Address..........................................19
Expiration and File Name..................................20
D. Eastlake [Page 2]
INTERNET-DRAFT TRILL Header Options
1. Introduction
This document provides informational material related to RBridges,
which are devices that implement the TRILL protocol.
Section 2 briefly compares some aspects of zero configuration IEEE
802.1D and 802.1Q bridges and RBridges. Section 3 discusses some
tradeoffs in features and configurations of RBridges. While Section 4
presents a sketch of a proof that, with reasonable assumptions,
persistent loops do not occur in a TRILL campus.
The terms and acronyms defined in Sections 1.3 and 1.4 of
[RFCprotocol] are used with the same definitions herein.
D. Eastlake [Page 3]
INTERNET-DRAFT TRILL Header Options
2. Zero Configuration Comparison
This section provides an informational comparison of the behavior of
a zero configuration IEEE 802.1D bridge, a zero configuration IEEE
802.1Q bridge, or a zero configuration RBridge in a network of
possibly configured devices. The goal is to clarify the behavioral
differences, particularly in regard to VLANs and priority. All three
devices can learn end station addresses in essentially the same way,
through the observation of traffic (although RBridges provide an
additional facility, which can be configured to learn such
information via TRILL IS-IS messages).
2.1 IEEE 802.1D Bridges
802.1D bridges [802.1D] are ignorant of VLANs. They are unaware
whether frames received have a C-tag (formerly called Q-tag), the tag
which provides VLAN ID and priority. As a result, 802.1D bridges
learn end station address locations based on simple 48-bit MAC
addresses unqualified by VLAN. (Actually 47 significant bits as
addresses with the group bit on are not learned.)
In a bridged LAN of 802.1D bridges, a single spanning tree is
determined and frames must flow along this tree. As a result, only
links that are part of the spanning tree can be used for through
traffic.
Since 802.1D bridges are ignorant of priority, frames do not get re-
ordered based on priority, low priority frames do not get
preferentially discarded due to he favoring of high priority frames,
and there are no facilities for mapping priority levels.
2.2 IEEE 802.1Q Bridges
802.1Q bridges [802.1Q] are aware of VLANs. Every frame internal to
such a bridge has a VLAN ID and priority associated with it. If the
frame arrived without a VLAN tag, the bridge port logic either drops
the frame or associates a VLAN and priority with it (see
[RFCprotocol] Appendix D). When a frame is transmitted by an 802.1Q
bridge, it can be sent with a VLAN tag indicating its VLAN and
priority or without such a tag, depending on port configuration.
Frames are only transmitted through a port if the VLAN of the frame
is in the set of VLANs enabled on that port. For a zero configuration
port, that set consists of only VLAN 1.
The learning of end station addresses in such a bridge is based on a
combined 12-bit VLAN ID and 48-bit (actually 47-bit as above) MAC
D. Eastlake [Page 4]
INTERNET-DRAFT TRILL Header Options
address. (However, 802.1Q bridges may support mapping VLAN IDs into a
smaller number of learning table IDs so that learning between those
VLANs is shared (see Section 4.6.3 of [RFCprotocol].)
A zero configuration 802.1Q bridge accepts frames that arrive tagged
with any valid VLAN. (They drop frames tagged with the illegal VLAN
0xFFF.) Frames without a VLAN tag are associated with VLAN 1.
However, because the ports of a zero configuration bridge have only
VLAN 1 enabled for output, accepted frames for any VLANs other than
1, unless they are addressed to the bridge itself, have no place they
can go. As a result, in an 802.1Q bridge network where there is
bridged traffic in any VLAN other than the default VLAN 1, it is
essential to configure ports to permit output for these other VLANs.
This can be done through management at each bridge or with VLAN
Registration Protocol messages (GVRP [802.1Q] or MVRP [802.1ak]) or a
combination of these techniques (see Section 4.7.2 of [RFCprotocol]).
By default, 802.1Q bridges form a single spanning tree and frames
flow along that tree. The bridge ports on spanning tree inter-bridge
links must be configured to enable all the VLANs which require the
link for connectivity. 802.1Q bridged LANs can be configured to have
up to an additional 64 spanning trees with traffic segregated between
the trees based on VLAN; however, the above considerations would
apply within each of such multiple spanning trees.
The recommended default for 802.1Q bridge ports is that VLANs be
disabled by default but dynamically registerable, except for VLAN 1,
which is fixed registered. As a result, VLAN Registration Protocol
frames can generally flow along the spanning tree adding the needed
VLANs to the ports where they are received so as to provide
connectivity between all end stations in each VLAN.
Since they recognize priority, 802.1Q bridges can re-order frames to
expedite those of higher priority and discard lower priority frames
in preference to discarding higher priority frames. 802.1Q bridge
ports not only associate a priority code point (0 through 7, default
1) with any frame received without a C-tag, they also map the
priority of a frame received with a C-tag. By default, this mapping
(which in IEEE 802.1 is called "regeneration") is the identity
mapping but can map each received priority code point to an arbitrary
other frame priority code point.
This priority mapping would make it possible, for example, to
configure a bridged LAN so that it had regions in which priority code
points had different external semantics such that the priority
associated with a frame was mapped and the regions boundaries. But
this would require careful configuration of the appropriate ports of
all bridges at inter-regional boundaries.
D. Eastlake [Page 5]
INTERNET-DRAFT TRILL Header Options
2.3 RBridges
RBridges are VLAN tag aware and, in terms of VLANs and priority, the
port behavior and configurability of an RBridge is almost identical
to that of an 802.1Q customer bridge. RBridges also learn end station
addresses based on a combined 12-bit VLAN ID and 48-bit MAC address
(actually 47-bit as above).
Zero configuration RBridges accept TRILL frames for any valid VLAN
but accept native frames only on a port where they are appointed
forwarder for the frame's VLAN. Native frames are not forwarded in
native form out of any local port unless the RBridge is the appointed
forwarder for the port and VLAN. In the zero configuration case, it
could only be appointed forwarder for VLAN 1. However, once a native
frame is encapsulated into a TRILL data frame, it is not restricted
to ports where output to its Inner.VLAN is enabled.
A zero configuration RBridge could forward TRILL data frames and
encapsulate and forward native frames to another RBridge or RBridges.
For example, a known unicast TRILL data frame would be forwarded
toward the correct egress RBridge even if it is in a VLAN other than
1. An RBridge would distribute a multidestination frame on its
distribution tree, possibly pruned for efficiency, to a subset of
RBridges. This is because an RBridge to RBridge link does not need
its end ports to have the relevant end-to-end VLANs added to them;
the encapsulation can tag the frame with the Designated VLAN as the
outer VLAN ID.
As a result of this, there is normally no need for VLAN Registration
Protocol frames to affect the receiving ports of transit or egress
RBridges. It can, however, still be useful for such frames to add
VLANs to the set for the ports of ingress RBridges where they are
received. Also, it can be useful for RBridges to send such VLAN
Registration Protocol frames to bridges (or possibly even end
stations) that may be included in the campus. (See Section 4.7.2 of
[RFCprotocol] for more details on RBridge handling of dynamic VLAN
registration.)
In terms of frame priority, RBridges associate a priority code point
with every native frame they receive in the same way that an IEEE
802.1Q bridge does. They assign a priority if the frame is untagged.
If the frame is tagged and thus has a priority code point, they map
it to a potentially different priority code point although the
default mapping is the identity mapping. While this determines the
priority of a native frame, if the frame received is a TRILL data or
ESADI frame, it contains an Inner.VLAN tag with the priority of the
frame at the time it was TRILL encapsulated. This inner priority code
point is used the case of TRILL data and ESADI frames. (Priority is
not relevant for a core TRILL IS-IS frame received by an RBridge.)
D. Eastlake [Page 6]
INTERNET-DRAFT TRILL Header Options
This use of the Inner.VLAN priority code point for forwarded TRILL
frames means that, in some sense, the interpretation of priority code
points should be uniform throughout a campus.
D. Eastlake [Page 7]
INTERNET-DRAFT TRILL Header Options
3. Pluses and Minuses
The subsections below examine the tradeoffs in various RBridge
features and configuration options.
3.1 Trees and the Forest
Although one distribution tree is logically sufficient to distribute
multi-destination frames in a campus, TRILL supports multiple
distribution trees for the following reasons:
1. It is desirable to allow choosing a different distribution tree
than the one rooted at the ingress RBridge for some frames in
order to allow multipathing of multi-destination traffic
encapsulated by a particular RBridge. (See [RFCprotocol] Appendix
C.)
2. Using a tree rooted at the ingress RBridge optimizes the
distribution path and (almost always) the cost of delivery when
the number of destination links is a subset of the total number of
links, as is the case with VLANs and IP multicasts.
3. For unknown unicast destinations, using a tree rooted at the
ingress RBridge minimizes out-of-order delivery because, in the
case where a flow starts before the location of the destination is
known by the RBridges, the path to the destination is the same as
the shortest path to the destination (unless equal cost multipath
is being used).
A distribution tree rooted in the ingress RBridge is not always the
best choice. To assure availability of such a tree, it would be
necessary to compute a tree rooted at every RBridges. 0 tradeoff
might be wanted in terms of the expense of computing many trees
versus optimality of traffic distribution, so fewer trees would be
desired.
As described in [RFCprotocol] Section 4.3, each RBridge includes in
its LSP a priority for itself to be chosen as a distribution tree
root and a number of distribution trees. Ties in priority are broken
by System ID. The number of trees specified by the RBridge that is
highest priority (lowest numeric priority / system ID) to be a
distribution tree root governs the campus. RBridge computes the
specified number, say n, trees rooted at the n RBridges that are
highest priority to be a tree root. In a zero configuration RBridge
campus, each RBridge calculates two trees, one rooted at each of the
two RBridges with lowest System IDs, and each RBridges distributes
multi-destination frames which it ingresses over the tree whose root
is least cost from the ingress RBridge.
D. Eastlake [Page 8]
INTERNET-DRAFT TRILL Header Options
3.2 Loop Safety
Avoidance of loops at Layer 2 is critical as they lead to rapid
network saturation, denial of service, and even exponential growth in
the number of frames looping.
The asynchronous and distributed nature of the processes in RBridges
and bridges and the imperfections of these devices and communications
paths between them make absolute guarantees of delivery, frame
ordering, or transient loop avoidance impossible. However, the
default loop safety provisions of TRILL, under the assumptions TRILL
makes, are intended to provide the same order of reliability in loop
avoidance as modern bridged LANs.
3.2.1 Loop Safety Mechanisms
There are two primary safety mechanisms used by RBridges to protect
against persistent loops. (There are also additional mechanisms to
greatly reduce the occueance and severity of transient loops.) The
primary persistent loop safety mechanisms are as follows:
The use of TRILL IS-IS Hellos, and
The decapsulation check.
The adequacy of the default set of TRILL Hellos to protect against
persistent loops is discussed in Section 4 below.
The second mechanism is the optional "decapsulation check" (sometimes
called the "root bridge collision" check). Every RBridge is required
to report in its link state for each VLAN for which it is appointed
forwarder on at least one of its ports, the complete list of root
bridges it sees on those ports. (This list may be null if none of
those ports leads to a bridged LAN.)
When an egress RBridge is about to decapsulate a TRILL data frame and
send a VLAN-x native frame out a port and it sees a root bridge R out
that port, it may optionally check to see if that R is on the list of
root bridges seen for VLAN-x by the frame's ingress RBridge. If this
check finds R, then the checking RBridge knows that it was about to
decapsulate onto either (1) the same bridged LAN from which the
native frame originated, possibly forming a loop, or (2) onto a
bridged LAN that was also directly connected to the ingress RBridge
on a port where the ingress RBridge was appointed forwarder for the
frame's VLAN. In this second case, the ingress RBridge should have
already forwarded the frame in native form and so it should not have
arrived at the egress RBridge in encapsulated form. In any case, if
this optional check is performed and the locally observed root bridge
is found in the ingress RBridge's list for the frame's VLAN, the
D. Eastlake [Page 9]
INTERNET-DRAFT TRILL Header Options
egress Rbridge does not send the decapsulated native frame out the
port but discards it.
3.2.2 Loop Safety Tradeoffs
The transmission and reception of many TRILL IS-IS Hellos can impact
available communications bandwidth and processing power. In other
words, they can stress the control plane. On the other hand, use of
the decapsulation (root bridge collision) check requires an
additional check in the data plane before any TRILL data is
decapsulated onto a link, making the data plane more complex.
If the computational and bandwidth load are acceptable, a campus will
be safer to the extent the RBridges are configured to perform the
decapsulation check and also send Hellos on at least the default set
of VLANs as specified in [RFCprotocol] Section 4.2.3.1.
Under normal circumstances, if any of the RBridges connected to a
link are configured to send Hellos into the link on fewer than the
default set of VLANs, it is recommended that those RBridges implement
and use the decapsulation check on their ports connected to that
link.
Under special circumstances, where it is known to be safe with a high
degree of reliability, RBridges may be configured to send Hellos on
fewer VLANs than the default without using the decapsulation check.
D. Eastlake [Page 10]
INTERNET-DRAFT TRILL Header Options
4. No Persistent Loops
This section demonstrates that, with reasonable assumptions, the
default set of Hellos that RBridges send do not permit the occurence
of persistent loops in an RBridge campus.
Section 4.1 below divides cases where a frame persistently loops into
three categories and show that only one of these can be problematic.
Section 4.2 discusses the possibly problematic case from the point of
view of a single pair of connected RBridges and provides a sketch of
a proof that, for any pair of connected RBridges and under reasonable
assumptions, the problematic case cannot persist. Finally Section 4.3
expands this sketch of a proof to an aribtrary bridged LAN connected
to an arbitrary number of RBridges.
4.1 Categories of Loops
An RBridge campus can consist of a large number of RBridges (in
principle up to 2**16 - 2 or more if some do not require nicknames)
interconnected by LANs that may be bridged. The RBridge ports and any
bridges involved could be arbitrarily configured concerning what
VLANs they pass, how they treat untagged frames on frame receipt and
for what VLANs they strip VLAN tags on transmission.
A persistent loop would be a frame that cycled indefinitely, although
it might, at various parts of that cycle, be tagged with different
VLANs and might be in TRILL encapsulated form or native form.
Persistent loops can be divided into three categories as follows:
1. The first category of persistent loop would be one within a
bridged or unbridged LAN between RBridges or end stations. The
looping frame could be any type of frame, native, TRILL, or
control. This category is the concern of IEEE 802.1 bridging
standards that solve this potential problem by forwarding frames,
when they are forwarded, in accordance with one of several
variations of the spanning tree protocol. While transient loops
can occur due to loss of spanning tree BPDUs or topology changes
that are not immediately detected, spanning tree prevents
persistent loops unless unsafe bridge options, such an inhibiting
the transmission of BPDUs, are used.
2. The second category of persistent loop would be one of TRILL
frames persistently transiting the same set of at least two
RBridges. The frames cannot loop in between RBridges as that would
be a category one loop discussed above. Also, there is no way for
core TRILL IS-IS frames to loop as they only go one RBridge hop
and are never forwarded by an RBridge. So such a loop would have
to be of a TRILL data or TRILL IS-IS ESADI frame among RBridges.
D. Eastlake [Page 11]
INTERNET-DRAFT TRILL Header Options
Such persistent loops cannot occur because TRILL uses IS-IS, which
does not produce persistent loops in the forwarding of unicast
frames or in the trees constructed for the distribution of multi-
destination frames.
In addition, all TRILL data and ESADI frames have a TTL that must
be decremented by at least one each RBridge hop and the frame
discarded, rather than forwarded, if the TTL is reduced to zero.
Therefore no individual frame can persistently loop.
Although not necessary to avoid persistent loops as herein
defined, RBridges further inhibit possible temporary looping of
multi-destination TRILL frames through the adjacecny checks,
including the reverse path forwarding check, made on arriving
TRILL data or ESADI frames.
3. There remains only one further category for persistent loops. In
category 1 above, we discuss why there cannot be persistent loops
within the possibly bridged LANs which connect RBridges. Therefore
the loop must involve frames sent between RBridges. In category 2
above, we discuss why there cannot be persistent loops of TRILL
frames being transmitted between RBridges. Therefore, any
persistent loop must involve, at least in part, non-TRILL frames
transmitted between RBridges.
There are only two non-TRILL types of frames, control frames and
native frames. Control frames are transmitted only one RBridge or
bridge hop and are not forwarded so they cannot loop. Therefore,
any persistent loop must involve a native frame sent from one
RBridge to another RBridge. Note that native frames do not have
TTL protection.
Section 4.2 below gives a sketch of a proof that native frame type 3
persistent loops cannot occur by considering a single pair of
RBridges on a link. Section 4.3 goes into excruciating detail
extending this to an arbitrary set RBridges connected to an arbitrary
bridged LAN.
4.2 Analysis for a Single Pair of RBridges
It is shown above that any persistent loop in an RBridge campus must
involve a native frame sent from one RBridge to another. These must
be separate RBridges as it is a fundamental assumption of the
Ethernet service model that a frame transmitted on an Ethernet link
will not be received by the transmitter.
For there to be a loop, the receiving RBridge must actually accept
the frame and forward it in encapsulated or native form. An RBridge
D. Eastlake [Page 12]
INTERNET-DRAFT TRILL Header Options
only accepts a native frame if it is appointed forwarder on the port
for the frame's VLAN. If it is not the appointed VLAN-x forwarder for
the native frame, the native frame is discarded and not forwarded in
any way.
An RBridge never transmits native frames unless it is appointed
forwarder for the frame's VLAN on the port where the frames are
transmitted.
Thus, for their to be a loop involving native frame transmission
between RBridges, both would have to be appointed forwarder on the
link. However, they would not necessarily have to be appointed for
the same VLAN. For example, the transmitting RBridge or some bridge
along the way could be stripping VLAN tags and some later bridge or
the receiving RBridge could insert a different VLAN tag or associate
the frame with a different VLAN.
Can this situation occur?
The primary defenses against such dual appointed forwarder situations
are, as described in [RFCprotocol] Section 4.2.3.1, the DRB and its
appointer forwarder determinations, which are mediated by TRILL IS-IS
Hellos. By default, the ports on which Hellos are transmitted include
any port where an RBridge is an appointed forwarder. Hellos are sent
out such a port for each VLAN for which the RBridge is appointed
forwarder.
Assume the RBridge sending the native frame is RBs and the RBridge
receiving it is RBr. Since a native frame is getting from RBs to RBr,
we assume that a Hello sent in the same VLAN will also get from RBs
to RBr and arrive with the same VLAN as the native frame. (This might
not be true if successive bridge/RBridge ports were configured so
that the Outer.VLAN was stripped and then frames were assigned a VLAN
based on protocol with different VLANs for TRILL frames (VLAN-T) and
for a possibly looping native frame (VLAN-n). Such a situation would
not necessarily cause a loop but could if other conditions were met
including that no VLAN-n Hellos were being sent from RBs and received
by RBr. In any case, we assume that this is not the situation.)
It will be clear to RBr from this Hello it receives from RBs that RBs
considers itself to be the appointed forwarder as there is a flag in
the Hello for this purpose. If the Hello is received with a different
Outer.VLAN ID from its Inner.VLAN ID, then VLAN mapping is occurring
and, as stated in [RFCprotocol] Section 4.2.3.1.3, native frames
received by RBr with either of those VLAN IDs will be discarded. Thus
there can be no loop with VLAN mapping.
Without VLAN mapping, RBr will receive Hellos from RBs indicating
that RBs believes itself to be appointed forwarder for the VLAN of
the native frame. This will cause RBs to inhibit its appointed
D. Eastlake [Page 13]
INTERNET-DRAFT TRILL Header Options
forwarder activity and discard the native frame, so no loop is
formed.
4.3 Analysis for on Arbitrary Bridged LAN
When a link provides full bi-directional connectivity between the
RBridges connected to it, each such RBridge can see the Hellos sent
by the others on that link. In that case, the selection of the one
DRB on the link and the decisions by that DRB as to appointed
forwarders are straightforward. However, the exact situation on an
arbitrary bridged LAN connecting multiple RBridges can, in the worst
case, be much more complex than this.
We will model the transmission of Hellos between the N RBridges
connected by an arbitrary bridged LAN as the existence of a pipe
between each pair of RBridges. Thus there are N*(N-1)/2 such pipes.
When an RBridge sends a Hello, it is pushed into all the pipes
terminating at that RBridge. Each pipe passes frames tagged with an
arbitrary subset of legal VLAN IDs. In general, the set of VLANs
passed is different in each direction through the pipe.
TRILL IS-IS Hellos have the VLAN on which they are sent embedded in
the body of the Hello. In this section, we will initially assume that
no VLAN mapping is occurring. With this assumption, we need not worry
about Outer.VLAN tags getting stripped or added by ports. By the time
a TRILL IS-IS Hello arrives at RBridge specific code as shown in
[RFCprotocol] Figure 4.3, it will have had a VLAN ID associated with
it. The no-VLAN-mapping assumption implies that this will necessarily
be the VLAN ID with which it was transmitted.
Consider the set of N RBridges connected to a bridged LAN: RB1, RB2,
... RBn which we will denote as {RB*}. (Any RBridge ports which are
disabled or have no enabled VLANs do not count as a connection to the
link to which they are physically attached.) These RBridges can be
strictly ordered by their priority to become DRB. This priority is an
unsigned 55-bit integer consisting of the RBridge's 7-bit priority to
become DRB (the IS-IS Hello header DIS priority) concatenated with
its 48-bit port MAC address. (There actually should be only 54
significant bits as the group bit in the MAC address should be zero.)
Assume, without loss of generality, that RB1 is the highest priority
to become DRB. It will specify a Designated VLAN in its Hellos and
will specify the adjacencies that it sees on its Designated VLAN in
the Hellos that it sends on that VLAN. The set of RBridges receiving
Hellos from RB1 ( h{RB1} ) on any VLAN will see that RB1 is DRB, will
defer to RB1 since, by construction, they are of lower priority, and
will announce RB1 as the DRB in all of their Hellos. If they have the
Designated VLAN enabled on the port on which they receive a Hello
D. Eastlake [Page 14]
INTERNET-DRAFT TRILL Header Options
from RB1, they will send such a Hello on the Designated VLAN on that
port. The normal IS-IS mechanisms will establish IS-IS adjacencies
between this subset of the RBridges with connectivity to RB1 over its
Designated VLAN. Thus they will be able to exchange TRILL data, LSPs,
etc. In the normal case, where the bridged LAN conforms to the
assumptions in [RFCprotocol] Section 2.3, this will be all of the
RBridges connected by this bridged LAN. It is only in the case of
badly configured bridges, that is, configurations which violate the
the assumptions in Section 2.3, that the discussion below in this
section is relevant.
There may be other RBridges in h{RB1} that can see Hellos from RB1 on
one or more VLANs but cannot establish an IS-IS adjacency with it on
the Designated VLAN as above and are orphaned from the link on that
port. This can occur for any of three reasons: (1) because the
Designated VLAN is not enabled on the port in question, (2) because,
although the Designated VLAN is enabled, it has no connectivity
through the bridged LAN from the port in question to RB1, and (3)
although there is connectivity over the Designated VLAN from the port
in question to RB1, there is no such connectivity in the other
direction.
The set of RBridges which receive Hellos from the RBridges which
receive Hellos from RB1, that is from the set of RBridges two "Hello
hops" over the link from RB1, is denoted h*2{RB1}. RBridges in that
set which are not in h{RB1} and are not RB1 itself cannot receive
Hellos directly from RB1 and so will be unable to establish adjacency
with RB1 but will see RB1 announced as the DRB. If they were to
simply believe that and announce it in their Hellos, we would have
the possibility of a live-lock. For example, assume the initially RBy
is in h*2{RB1} but is not RB1 and is not in h{RB1} and RBx is in
h{RB1}. If RBx and RBy each believe the others Hello announcement
that RB1 is DRB, they would continue to believe that even if RB1
dropped off the link or was reconfigured to have lower priority. To
break this live-lock, an RBridge believes and defers to the DRB
announcement in a Hello it receives only if the receiving RBridge is
lower priority than the RBridge actually sending the Hello. If the
announcing RBridge is higher priority than the receiving RBridge,
they do defer to the announced DRB, RB1 in this case, and announce it
in their Hellos.
There may be additional RBridges three Hello hops from RB1, that is
in h*3{RB1}, but which are not RB1 or in h{RB1} or h*2{RB1} which are
similarly affected, if they are lower priority than at least one of
the RBridges from which they receive a Hello showing RB1 as DRB, and
so on. If very limited connectivity via various VLANs exists and the
relative priorities were just right, deference to RB1 can continue to
propagate and could, in the worst case, require N-1 Hellos steps for
the last and lowest priority RBridge to get word that it should defer
to RB1. The entire set of RBridges connected to the particular
D. Eastlake [Page 15]
INTERNET-DRAFT TRILL Header Options
bridged LAN and deferring to RB1 is denoted h**{RB1}.
There may be RBridges connected to the bridged LAN which are not in
h**{RB1}, that is in the set {RB*} but not in the set h**{RB1}}. Such
RBridges may have no direct or indirect knowledge of RB1 and thus
could not defer to it or may receive Hellos showing RB1 as DRB only
from RBridges of lower priority which they do not honor to avoid
live-lock as explained above. If this set is not empty, there will be
one RBridge in this set that is highest priority to be DRB, say RBi.
We can now perform the same analysis above leading to the conclusion
that there will be a set h**{RBi} of RBridges which defer to RBi.
There are several possibilities for connectivity between the h**{RB1}
and h**{RBi} sets:
1. It may be that there is no connectivity at all between RBridges in
h**{RB1} and h**{RBi} in which case each of these sets is
connected to what is, for all practical purposes, a separate link.
In this case it is loop safe that there is a separate DRB for each
(RB1 and RBi) and there may be a different appointed forwarders in
each set for the same VLAN.
2. Alternatively, there may be some unidirectional or bi-directional
connectivity between one or more RBridges in h**{RB1} and
h**{RBi}. However, in no case could there be connectivity from a
higher priority RBridge in h**{RB1} to a lower priority RBridge in
h**{RBi} as that would cause the lower priority RBridge to defer
to RB1, leave h**{RBi}, and join h**{RB1}. However, other possible
connectivity is still potentially dangerous. In particular,
connectivity over VLAN-x between two RBridges that are both VLAN-x
appointed forwarders for that VLAN causes a loop unless one of the
appointed forwarders is inhibited. There are three possibilities:
2a. Unidirectional connectivity from a lower priority RBridge in
the set with the lower priority DRB ( h**{RBi} ) to a higher
priority RBridge in the set with a higher priority DRB (
h**{RB1} ).
2b. Unidirectional connectivity from a lower priority RBridge in
the set with the higher priority DRB to a higher priority
RBridge in the set with a lower priority DRB.
2c. Bidirectional connectivity as in 2b.
The danger possible in 2a through 2c is solved by providing that
while a higher priority RBridge is receiving Hellos on VLAN-x from a
lower priority RBridge where the lower priority RBridge is an
appointed forwarder for VLAN-x, the higher priority RBridge does not
encapsulate native frames off the link or decapsulate native frames
onto the link for VLAN-x. This is one reason why all RBridges, by
default, send Hellos on all VLANs for which they are appointed
forwarder.
D. Eastlake [Page 16]
INTERNET-DRAFT TRILL Header Options
Even outside of h**{RB1} and h**{RBi}, there may be additional
RBridges connected to the bridged LAN. If so there would be one of
them with highest priority, say RBj. We can then repeat the above
analysis and see that there is a set h**{RBj} of RBridges deferring
to RBj. As above, if there is no connectivity between any RBridge in
h**{RBj} and any RBridge in either h**{RB1} or h**{RBi}, then these
populations of RBridges can act independently without risk of a loop.
However, if there is connectivity on VLAN-x from a VLAN-x appointed
forwarder in h**{RBj} to one in h**{RB1} or h**{RBi} then the higher
priority of the conflicting appointed forwarders inhibit any
encapsulation or decapsulation any VLAN-x native frames off of or
onto the link.
This process can be continued as long as their remain RBridges
connected to the bridged LAN in question which are not yet found to
be part of a set of RBridges deferring to a DRB. The method of
construction for these sets outlined above means that the sets will
be produced in order of declining priority of the set's DRB. By
construction, they can be no persistent connectivity, unidirectional
or otherwise, from a higher priority RBridge in a set with a higher
priority DRB to a lower priority RBridge in a set with a lower
priority DRB as it would cause the lower priority RBridge to switch
sets. Any of these sets of RBridges can safely act independently if
they have no connectivity over the bridged LAN to any RBridges in any
other set. Whenever there is connectivity over VLAN-x between two
RBridges that are appointed VLAN-x forwarder, the higher priority
RBridge of the two does not encapsulate or decapsulating VLAN-x
native frames off of or onto the link.
The addition of VLAN mapping, ignored in the analysis above, makes
more complex loop possible. For example, if mappings form a cycle,
there could be loops in the campus where a frame is decapsulated from
VLAN-x, encapsulated as VLAN-y, then decapsulated from VLAN-y and
encapsulated as VLAN-x (x->y->x) or longer loops going through more
VLANs. However, as specified in [RFCprotocol] Section 4.2.3.1.3, when
VLAN mapping is detected, both the "from" and "to" VLAN IDs are
disabled at the detecting RBridge. Thus, a loop cannot be formed via
a VLAN mapping path through a bridged LAN between RBridges because
the mapping would inhibit processing of frames in the receiving
RBridge.
D. Eastlake [Page 17]
INTERNET-DRAFT TRILL Header Options
5. Security Considerations
This document provides additional informational notes related to
RBridges and the TRILL protocol but not directly related to security.
For RBridge base protocol security considerations, see [RFCprotocol].
6. Normative References
[RFCprotocol] - "Rbridges: Base Protocol Specification", R. Perlman
et al, draft-ietf-trill-rbridge-protocol-08.txt, July 14, 2008,
work in progress.
7. Informative References
[802.1ak] "IEEE Standard for Local and metropolitan area networks /
Virtual Bridged Local Area Networks / Multiple Registration
Protocol", IEEE Standard 802.1ak-2007, 22 June 2007.
[802.1D] "IEEE Standard for Local and metropolitan area networks /
Media Access Control (MAC) Bridges", IEEE Standard 802.1D-2004, 9
June 2004.
[802.1Q] "IEEE Standard for Local and metropolitan area networks /
Virtual Bridged Local Area Networks", IEEE Standard 802.1Q-2005,
19 May 2006.
8. IANA Considerations
This document requires no IANA actions. This section should be
deleted before publication.
D. Eastlake [Page 18]
INTERNET-DRAFT TRILL Header Options
Disclaimer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Additional IPR Provisions
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Copyright (C) The IETF Trust 2008 This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Author's Address
Donald E. Eastlake 3rd
Eastlake Enterprises
155 Beaver Street
Milford, MA 01757 USA
D. Eastlake [Page 19]
INTERNET-DRAFT TRILL Header Options
email: d3e3e3@gmail.com
Expiration and File Name
This draft expires in February 2009.
Its file name is draft-eastlake-trill-notes-00.txt.
D. Eastlake [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 16:07:52 |