One document matched: draft-eastlake-trill-rbridge-clear-correct-00.txt
TRILL Working Group Donald Eastlake
INTERNET-DRAFT Mingui Zhang
Intended status: Proposed Standard Huawei
Updates: 6325 Anoop Ghanwani
Brocade
Ayan Banerjee
Cisco
Vishwas Manral
Hewlett-Packard
Expires: April 23, 2012 October 24, 2011
RBridges: Clarifications and Corrections
<draft-eastlake-trill-rbridge-clear-correct-00.txt>
Abstract
The IETF TRILL (TRansparent Interconnection of Lots of Links)
standard 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.
Since the TRILL base protocol, RFC 6325, was approved, active
development of TRILL has revealed corner cases that could use
clarification and a few errors in the original RFC. RFCs 6327, XXXX,
and YYYY, provide clarifications with respect to Adjacency, Appointed
Forwarders, and the TRILL ESADI protocol. This document provide other
known clarifications and corrections and 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
material or to cite them other than as "work in progress."
D. Eastlake, et al [Page 1]
INTERNET-DRAFT RBridges: Clarifications and Corrections
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 2]
INTERNET-DRAFT RBridges: Clarifications and Corrections
Table of Contents
1. Introduction............................................4
1.1 Terminology and Acronyms...............................4
2. Overloaded and/or Unreachable RBridges..................5
2.1 Distribution Tree Roots................................6
2.2 Overloaded Receipt of TRILL Data Frames................6
2.3 Overloaded Origination of TRILL Data Frames............6
2.3.1 Known Unicast Origination............................7
2.3.2 Multi-Destination Origination........................7
3. Distribution Tree Updates...............................9
4. Nickname Selection.....................................10
5. MTU....................................................12
5.1 MTU PDU Addressing and Processing.....................12
5.2 MTU Values............................................12
6. The CFI / DEI Bit......................................13
7. Graceful Restart.......................................14
8. IANA Considerations....................................15
9. Security Considerations................................15
Normative References......................................16
Informative References....................................16
D. Eastlake, et al [Page 3]
INTERNET-DRAFT RBridges: Clarifications and Corrections
1. Introduction
The IETF TRILL (Transparent Interconnection of Lots of Links)
standard [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] [RFC6326] 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.
Since the TRILL base protocol [RFC6325] was approved, the active
development of TRILL has revealed corner cases that could use
clarification and a few errors in the original specification document
[RFC6325]. [RFC6327], [RFCXXXX], and [RFCYYYY], provide
clarifications with respect to Adjacency, Appointed Forwarders, and
the TRILL ESADI protocol. This document provide other known
clarifications and corrections and updates [RFC6325].
1.1 Terminology and Acronyms
This document uses the acronyms defined in [RFC6325] and the
following acronyms:
CFI - Canonical Format Indicator
DEI - Drop Eligibility Indicator
OOMF - Overload Originated Multi-destination Frame
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].
D. Eastlake, et al [Page 4]
INTERNET-DRAFT RBridges: Clarifications and Corrections
2. Overloaded and/or Unreachable RBridges
RBridges may be in overload as indicated by the [IS-IS] overload flag
in their LSPs. This means that either (1) they are incapable of
holding the entire link state database and thus do not have a view on
the entire topology or (2) they have been configured to have the
overload bit on. Although networks should be engineered to avoid
actual link state overload, it might occur if a large campus included
one or more low end RBridges.
It is a common operational practice to set the overload bit in an
[IS-IS] router (such as an RBridge) when performing maintenance on
that router that might affect its ability for correctly forward
frames; this will usually leave the router reachable for maintenance
traffic but through traffic will not normally be routed through it.
(Also, in some cases, TRILL provides for setting the overload bit in
the pseudo node of a link to stop TRILL Data traffic on an access
link (see Section 4.9.1 of [RFC6325]).)
[IS-IS] and TRILL make a reasonable effort to do what they can even
if some RBridge/routers are in overload. They can do reasonable well
if a few scattered nodes are in overload. However, actual least cost
paths are no longer assured if any RBridges are in overload.
An RBridge in overload cannot be trusted to correctly calculate
distribution trees or correctly perform the Reverse Path Forwarding
Check. Therefore, it cannot be trusted to forward multi-destination
TRILL Data frames. It can only appear as a leaf node in a TRILL
multi-destination distribution tree.
Frames are not routed through an overloaded RBridge if any other path
is available, although they may originate or terminate at overloaded
RBridge. In addition, TRILL will not route frames over links with
cost 2**24 - 1; such links are reserved for traffic engineered frames
the handling of which is beyond the scope of this document.
As a result, a portion of the campus may be unreachable for TRILL
Data because all paths to it would be through a link with cost 2**24
- 1. For example, an RBridge RB1 is TRILL Data unreachable if all of
its neighbors are connected to RB1 by links with cost 2**24 - 1. Such
RBridges are data unreachable.
The link state database at an RBridge RB1 can also contain
information on RBridges that are unreachable by IS-IS link state
flooding due to link or RBridge failures. When such failures
partition the campus, the RBridges adjacent to the failure and on the
same side of the failure as RB1 will update their LSPs to show the
lack of connectivity and RB1 will receive those updates. However,
LSPs held by RB1 for RBridges on the far side of the failure will not
be updated and may stay around until they time out, which could be
D. Eastlake, et al [Page 5]
INTERNET-DRAFT RBridges: Clarifications and Corrections
tens of seconds or longer. Since a link is only usable if both ends
declare it up in their LSP, RB1 will be aware of the partition and
will know about the unreachability of nodes on the far side of the
failure. Such nodes are both IS-IS unreachable and data unreachable.
2.1 Distribution Tree Roots
When an RBridge determines what nicknames to use as the roots of the
distribution trees it calculates, it MUST ignore all nicknames held
by RBridges that are in overload or are data unreachable. When
calculating reverse path forwarding checks for multi-destination
frames, an RBridge RB1 should similarly ignore any trees that cannot
reach to RB1 even if other RBridges list them as trees those other
RBridges might use. (But see Section 3.)
2.2 Overloaded Receipt of TRILL Data Frames
An RBridge in overload, RB2, will not normally receive unicast TRILL
Data frames unless it is the egress, in which case it processes the
frame normally.
If RB2 receives a unicast TRILL Data frame for which it is not the
egress, perhaps because a neighbor does not yet know it is in
overload, it decrements the Hop Count as usual and discards the frame
if the Hop Count is zero or the egress nickname is illegal. It SHOULD
NOT discard the frame because the egress nickname is unknown as it
might now know about all nicknames due to overload. It MUST then
forwards the unicast frame to any neighbor that is not overloaded but
SHOULD NOT forward the frame back to the RBridge from which it
received it.
If RB2 in overload receives a multi-destination TRILL Data frame, RB2
performs the usual Hop Count processing but MUST NOT apply a Reverse
Path Forwarding Check since, due to overload, it might not do so
correctly. RB2 egresses and delivers the frame locally as appropriate
but RB2 MUST NOT forward it.
2.3 Overloaded Origination of TRILL Data Frames
Overloaded origination of unicast frames with know egress and of
multi-destination frames are discussed in the subsections below.
D. Eastlake, et al [Page 6]
INTERNET-DRAFT RBridges: Clarifications and Corrections
2.3.1 Known Unicast Origination
When an overloaded RBridge RB2 ingresses or creates a unicast TRILL
Data frame, it delivers it locally if the destination MAC is local.
Otherwise RB2 link unicasts it to any neighbor RBridge that is not
overloaded.
2.3.2 Multi-Destination Origination
RB2 ingressing or creating a multi-destination TRILL Data frame is
more complex.
RB2 would like to hand multi-destination frames it is originating to
a neighbor RB3 such that that (1) RB3 is not overloaded, (2) RB3 will
distribute the frame on a tree in which RB2 is a leaf node from RB3,
and (3) where RB3 will know not to send a copy back to RB2. In the
absence of criteria 2 and 3, RB2 would received a duplicate copy back
which might be confusing. Criteria 2 is no problem as RBridges in
overload can only be leaf nodes for any TRILL distribution tree.
Neighbors of RB2 that are willing to accept such frames advertise
this in the TRILL Neighbor TLV in their TRILL Hellos by setting a bit
associated with the SNPA (MAC address) of RB2 on the link. (See
Section 6.) If no neighbor of RB2 that is not in overload offers such
service, then RB2 cannot originate multi-destination TRILL Data
frames, although it will still receive them.
If RB2 sees this OOMF (Overloaded Origination of Multi-destination
Frame) service advertised by any of its neighbors on any link to
which RB2 connects, it selects one such neighbor by a means beyond
the scope of this document. Assuming RB2 selects RB3 to handle multi-
destination frames it originates. RB2 MUST advertise in its LSP that
it might use any of the distribution trees that RB3 advertises it
might use so that the Reverse Path Forwarding Check will work.
RB2 then encapsulates such frames as TRILL data frames to RB3 as
follows: M bit = 1, Hop Count = 2, ingress nickname = a nickname held
by RB2, and, since RB2 cannot tell what distribution tree RB3 will
use, egress nickname = a special nickname indicating an OOMF (see
Section 6). RB2 then link unicasts this encapsulation to RB3.
On receipt of such a frame, RB3 does the following:
- change the egress nickname field to designate a distribution tree
that RB3 normally uses for which RB2 is a leaf from RB3 (if there
is no such tree, RB3 MUST NOT offer the OOMF service to RB2),
- change the Hop Count to the value it would normally use if it were
the ingress, and
D. Eastlake, et al [Page 7]
INTERNET-DRAFT RBridges: Clarifications and Corrections
- forward the frame on that tree except that it MUST NOT send a copy
back to RB2.
RB3 MAY rate limit the number of frames for which it is providing
this service by discarding some such frame from RB2. (The provision
of even a limited bandwidth for OOMFs by RB3, for example via a slow
path, may be important to bootstrapping of services at RB2 or end
stations connected to RB2.)
D. Eastlake, et al [Page 8]
INTERNET-DRAFT RBridges: Clarifications and Corrections
3. Distribution Tree Updates
When a link state database change causes a change in the distribution
tree(s), there are several possibilities. If a tree root remains a
tree root but the tree changes, then local forwarding and RPFC
entries for that tree should be updated as soon as practical.
Similarly, if a new nickname becomes a tree root, forwarding and RPFC
entries for the new tree should be installed as soon as practical.
However, if a nickname ceases to be a tree root and there is
sufficient room in local tables, it is RECOMMENDED that forwarding
and RPFC entries for the former tree be retained so that any frames
in flight on that tree can still be forwarded.
D. Eastlake, et al [Page 9]
INTERNET-DRAFT RBridges: Clarifications and Corrections
4. Nickname Selection
Nickname selection is covered by Section 3.7.3 of [RFC6325]. However,
the following should be noted:
1. The second sentence in the second bullet item in Section 3.7.3 of
[RFC6325] on page 25 is erroneous and is corrected as follows:
1.a The occurrence of "IS-IS ID (LAN ID)" is replaced with
"priority".
1.b The occurrence of "IS-IS System ID" is replaced with "seven
byte IS-IS ID (LAN ID)".
The resulting corrected [RFC6325] sentence reads as follows: "If
RB1 chooses nickname x, and RB1 discovers, through receipt of an
LSP for RB2 at any later time, that RB2 has also chosen x, then
the RBridge or pseudonode with the numerically higher priority
keeps the nickname, or if there is a tie in priority, the RBridge
with the numerically higher seven byte IS-IS ID (LAN ID) keeps the
nickname, and the other RBridge MUST select a new nickname."
2. In examining the link state database for nickname conflicts,
nicknames held by IS-IS unreachable RBridges MUST be ignored but
nicknames held by TRILL data unreachable RBridges MUST NOT be
ignored.
3. An RBridge may need to select a new nickname, either initially
because it has none or because of a conflict. When doing so, the
RBridge MUST consider as available all nicknames that do not
appear in its link state database or that appear to be held by IS-
IS unreachable RBridges; however, it SHOULD give preference to
selecting new nicknames that do not appear to be held by any
RBridge in the campus, reachable or unreachable, so as to minimize
conflicts if unreachable RBridges later become reachable.
4. An RBridge, even after it has acquired a nickname for which there
appears to be no conflicting claimant, MUST continue to monitor
for conflicts with the nickname or nicknames it holds. It does so
by checking in LSPs that update its link state database for any of
its nicknames held with higher priority by another RBridge that is
IS-IS reachable. If it finds such a conflict, it MUST select a new
nickname.
5. In the very unlikely case that an RBridge is unable to obtain a
nickname because all valid nicknames (0x0001 through 0xFFBF
inclusive) are in use with higher priority by reachable RBridges,
it will be unable to act as an ingress, egress, or tree root but
will still be able to function as a transit RBridge. Such an
RBridge with no valid nickname MUST announce its nickname in its
D. Eastlake, et al [Page 10]
INTERNET-DRAFT RBridges: Clarifications and Corrections
LSP as 0x0000. Although it cannot be a tree root, such an RBridge
is included in every distribution tree computed for the campus. It
would not be possible to send an RBridge Channel message to such
an RBridge [Channel].
D. Eastlake, et al [Page 11]
INTERNET-DRAFT RBridges: Clarifications and Corrections
5. MTU
Section 5.1 below corrects an Errata in [RFC6325] and Section 5.2
clarifies the meaning of various MTU numbers.
5.1 MTU PDU Addressing and Processing
[RFC6325] in Section 4.3.2 incorrectly states that multi-destination
MTU-probe and MTU-ack TRILL IS-IS PDUs are sent on Ethernet links
with the All-RBridges multicast address as the Outer.MacDA. As TRILL
IS-IS PDUs, when multicast on an Ethernet link, they MUST be sent to
the All-IS-IS-RBridges multicast address.
As discussed in [RFC6325] and, in more detail, in [RFC6327], MTU-
probe and MTU-ack PDUs MAY be unicast; however, Section 4.6 of
[RFC6325] erroneously does not allow for this possibility. It is
corrected by replacing item numbered "1" in Section 4.6.2 of
[RFC6325] with the following quoted text to which RBridges MUST
conform:
"1. If the Ethertype is L2-IS-Is and the Outer.MacDA is either All-
IS-IS-RBridges or the unicast MAC address of the receiving
RBridge port, the frame is handled as described in Section
4.6.2.1"
The reference to "Section 4.6.2.1" in the above quoted text is to
that Section in [RFC6325].
5.2 MTU Values
TBD - talk about exact meaning of various MTU values
D. Eastlake, et al [Page 12]
INTERNET-DRAFT RBridges: Clarifications and Corrections
6. The CFI / DEI Bit
In May 2011, the IEEE promulgated [802.1Q-2011] which changes the
meaning of the bit between the priority and VLAN ID bits in the
payload of C-VLAN tags. Previously this bit was called the CFI
(Canonical Format Indicator) bit and had a special meaning in
connection with IEEE 802.5 (Token Ring) frames. Now, under
[802.1Q-2011], it is a DEI (Drop Eligibility Indicator) bit, similar
to that bit in S-VLAN (and B-VLAN) tags where this bit has always
been a DEI bit.
The TRILL base protocol specification [RFC6325] assumed, in effect,
that the link by which end stations are connected to RBridges and the
virtual link provided by the TRILL Data encapsulation are IEEE 802.3
Ethernet links on which the CFI bit is always zero. Should an end
station be attached by some other type of link, such as an FDDI
(Fiber Distributed Data Interface) or Token Ring link, [RFC6325]
implicitly assumed that such frames would be canonicalized to 802.3
frames before being ingressed and similarly, on egress, such frames
are converted from 802.3 to the appropriate frame type for the link.
Thus, [RFC6325] required that the CFI bit in the Inner.VLAN always be
zero.
However, for RBridge with ports conforming to the change incorporated
in the 802.1Q-2011 standard, the bit in the Inner.VLAN, now a DEI
bit, MUST be set to the DEI value provided by the EISS interface on
ingressing a native frame. Similarly, this bit MUST be provided to
the EISS when transiting or egressing a TRILL Data frame. The exact
effect on the C-VLAN Outer.VLAN DEI and priority bits and whether or
not an Outer.VLAN appears at all on the wire for output frames
depends on output port configuration.
RBridge campuses with a mixture of ports, some compliant with
[802.1Q-2011] and some compliant with pre-802.1Q-2011, especially if
they have actual Token Ring links, may operate incorrectly and may
corrupt data, just as a bridged LAN with such mixed ports would.
D. Eastlake, et al [Page 13]
INTERNET-DRAFT RBridges: Clarifications and Corrections
7. Graceful Restart
RBridge SHOULD support the features specified in [RFC5306] which
describes a mechanism for a restarting IS-IS router to signal to its
neighbors that it is restarting, allowing them to reestablish their
adjacencies without cycling through the down state, while still
correctly initiating link state database synchronization.
D. Eastlake, et al [Page 14]
INTERNET-DRAFT RBridges: Clarifications and Corrections
8. IANA Considerations
IANA is requested to allocate the previously reserved nickname 0xXXXX
for use in the TRILL Header egress nickname field to indicate an
Overload Originated Multi-destination Frame.
IANA is requested to allocate bit TBD (bit 1, the bit adjacent to the
F bit) from the seven currently reserved (RESV) bits in the per
neighbor "Neighbor RECORD" in the TRILL Neighbor TLV [RFC6326]. This
bit indicates that the RBridge sending the TRILL Hello will provide
the overload originated multi-destination frame forwarding service
described in Section 2.3 to such frames originated by the RBridge
whose SNPA (port MAC address) appears in that Neighbor RECORD.
9. Security Considerations
This memo improves the documentation of the TRILL standard and
corrects some errors in [RFC6325]. It does not change the security
considerations of the TRILL base protocol for which see Section 6 of
[RFC6325].
D. Eastlake, et al [Page 15]
INTERNET-DRAFT RBridges: Clarifications and Corrections
Normative References
[802.1Q-2011] - 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.
[RFC5306] - Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
RFC 5306, October 2008.
[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.
Informative References
[Channel] - draft-ietf-trill-rbridge-channel, work in progress.
[RFCXXXX] - R. Perlman, D. Eastlake, Y. Li, A. Banerjee, H. Fangwei,
"RBridges: Appointed Forwarders", draft-ietf-trill-rbridge-af,
in the RFC Editor's queue.
[RFCYYYY] - H. Zhai, F. Hu, R. Perlman, D. Eastlake, "RBridges: The
ESADI Protocol", draft-hu-trill-rbridge-esadi, work in
progress.
D. Eastlake, et al [Page 16]
INTERNET-DRAFT RBridges: Clarifications and Corrections
Authors' Addresses
Donald Eastlake
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Mingui Zhang
Huawei Technologies Co.,Ltd
Huawei Building, No.156 Beiqing Rd.
Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,Hai-Dian District,
Beijing 100095 P.R. China
Email: zhangmingui@huawei.com
Anoop Ghanwani
Brocade
130 Holger Way
San Jose, CA 95134 USA
Phone: +1-408-333-7149
EMail: anoop@alumni.duke.edu
Ayan Banerjee
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134 USA
EMail: ayabaner@cisco.com
Vishwas Manral
HP Networking
19111 Pruneridge Avenue
Cupertino, CA 95014 USA
Tel: +1-408-477-0000
EMail: vishwas.manral@hp.com
D. Eastlake, et al [Page 17]
INTERNET-DRAFT RBridges: Clarifications and Corrections
Appendix: Change Record
This appendix summarizes changes between versions of this draft.
RFC Editor: Please delete this Appendix before publication.
From -00 to -01
TBD
D. Eastlake, et al [Page 18]
INTERNET-DRAFT RBridges: Clarifications and Corrections
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.
D. Eastlake, et al [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 00:09:38 |