Internet DRAFT - draft-gray-rbridge-scaling
draft-gray-rbridge-scaling
Network Working Group Eric Gray
Internet Draft Ericsson
Expires: May, 2008
Intended Status: Informational
November 19, 2007
Issues and Approaches to Scaling RBridge Deployments
draft-gray-rbridge-scaling-01.txt
Status of this Memo
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.
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
This Internet-Draft will expire on May 19, 2008.
Abstract
RBridges are link layer (L2) devices that use routing protocols
as a control plane. They combine several of the benefits of the
link layer with network layer routing benefits. RBridges may use
existing link state routing (without requiring configuration) to
improve RBridge to RBridge aggregate throughput. RBridges also
Gray Expires May, 2008 [Page 1]
Internet-Draft Scaling RBridge Deployments November 2007
provide support for IP multicast and IP address resolution
optimizations. They are intended to be applicable to similar L2
network sizes as conventional bridges and are intended to be
backward compatible with those bridges as both ingress/egress
and transit. They also support VLANs (although this generally
requires configuration) and otherwise attempt to retain as much
'plug and play' as is already available in existing bridges.
There has been a lot of discussion within the TRILL working
group about the potential for scaling issues when using IS-IS in
combination with (possibly as many as 4K) VLANs. This document
is intended to provide information on potential scaling issues
and the possible solutions that may be applied in deploying
RBridges.
Gray Expires May, 2008 [Page 2]
Internet-Draft Scaling RBridge Deployments November 2007
Table of Contents
1 Introduction................................................4
1.1 Terminology...........................................4
1.2 Routing Protocol Operation............................5
1.3 Other Bridging and Ethernet Protocol Operations.......5
2 Scaling Issues With IS-IS in Combination with VLANs.........6
2.1. Peering Complexity.....................................6
2.2. Designated RBridge Election and Load Splitting.........6
2.3. Messaging Complexity and Message Length................7
3 Security Considerations.....................................7
4 IANA Considerations.........................................7
5 Acknowledgments.............................................7
6 References..................................................8
6.1 Normative References..................................8
6.2 Informative References................................8
Author's Addresses.............................................8
Intellectual Property Statement................................9
Disclaimer of Validity.........................................9
Copyright Statement............................................9
Acknowledgment................................................10
Gray Expires May, 2008 [Page 3]
Internet-Draft Scaling RBridge Deployments November 2007
1 Introduction
This document describes issues with, and potential solutions
for, scaling deployments of RBridge standard implementations in
combination with standard VLANs.
1.1 Terminology
The following terminology is used, as described in this section,
throughout this document.
o IS-IS: Intermediate System to Intermediate System routing
protocol. See [2] for further information on IS-IS.
o LAN: Local Area Network, is a computer network covering a
small geographic area, like a home, office, or group of
buildings, e.g., as based on IEEE 802.3 technology, see also
IEEE 802.1Q-2005, Section 3.11 [3].
o Spanning Tree Protocol (STP): an Ethernet (802.1D) protocol
for establishing and maintaining a single spanning tree among
all the bridges on a local Ethernet segment. Also, Rapid
Spanning Tree Protocol (RSTP). In this document, STP and RSTP
are considered to be the same.
o SPF: Shortest Path First - an algorithm name associated with
routing, used to determine a shortest path graph traversal.
o TRILL: Transparent Interconnect over Lots of Links - the
working group and working name for the problem domain to be
addressed in this document.
o VLAN: Virtual Local Area Network, see IEEE 802.1Q-2005 [3].
o Adjacent RBridges: RBridges that communicate directly with
each other without relay through other RBridges.
o Designated RBridge (DR): the RBridge that is elected to
handle ingress and egress traffic to a particular Ethernet
link having shared access among multiple RBridges; that
RBridge is such a link's "Designated RBridge". The Designated
RBridge is determined by an election process among those
RBridges having shared access via a single LAN.
Gray Expires May, 2008 [Page 4]
Internet-Draft Scaling RBridge Deployments November 2007
o Edge RBridge (edge of a TRILL Campus): describes RBridges
that serve to ingress frames into the TRILL Campus and egress
frames from the TRILL Campus. L2 frames transiting an TRILL
Campus enter, and leave, it via an edge RBridge.
o Peer RBridge: The term "Peer RBridge", or (where usage is not
ambiguous) the term "Peer", are used in the RBridge context
to refer to any of the RBridges that make up a TRILL campus.
o RBridge: a logical device as described in this document,
which incorporate both routing and bridging features, thus
allowing for the achievement of TRILL Architecture goals. A
single RBridge device which can cooperate with other RBridge
devices to create a TRILL Campus.
o TRILL Campus: this term, or the term "Campus" (where usage is
not ambiguous) is used in the RBridge context to refer to the
set of cooperating RBridges and TRILL Links that connect them
to each other.
o TRILL Link: this term, or the term "Link" (where its usage is
not ambiguous) is used in the RBridge context to refer to the
Layer 2 connection that exists either between RBridges, or
between an RBridge and Ethernet end stations.
1.2 Routing Protocol Operation
The details of routing protocol operation are as specified for
IS-IS.
1.3 Other Bridging and Ethernet Protocol Operations
Perhaps the most severe scaling issue associated with RBridge
specific behaviors is that relating to interactions with VLANs
and - in particular with 802.1Q bridges.
The simplest solution would be to effectively minimize - to the
point of disallowing - VLAN configuration, particularly between
RBridges.
Unfortunately, this approach cannot be relied on except in the
case of a point to point connection between two RBridges. This
is because it is relatively easy to show a reasonable network
topology involving multiple VLAN (802.1Q) bridges in which using
Gray Expires May, 2008 [Page 5]
Internet-Draft Scaling RBridge Deployments November 2007
a single VLAN for control purposes will hide a bridge failure
resulting in an undetected partition in the VLAN network.
Even in the point to point case, it is essential that VLAN state
information is shared across the point to point link for all
VLANs (at least those for which the two associated RBridges are
configured to participate in). Several proposals have been
discussed and it is very likely that one approach will be to use
a compressed vector representation such as has been defined for
Multiple VLAN Registration Protocol (MVRP).
2 Scaling Issues With IS-IS in Combination with VLANs
Related to the issue above is the complexity associated with IS-
IS peering on a per-VLAN basis. Peer state information needs to
be maintained using a refresh-based messaging mechanism. IS-IS
peering between IS-IS adjacent peers for possibly as many as
4,094 VLANs effectively multiplies that traffic by the number of
VLANs possibly resulting in easily over-whelming slower control
plane processing devices.
However, the use of even a compressed vector scheme - such as
has been suggested - adds to message size and processing
complexity and does nothing much to reducing complexity of VLAN
state information, as mentioned in the section above, nor to
reducing the complexity associated with forwarding table size.
2.1. Peering Complexity
The details of peering complexity are yet to be determined.
Ideally, this section will contain not only analysis of this
information, but possibly simulation results - based on a number
of scenarios - as well.
2.2. Designated RBridge Election and Load Splitting
One of the possible complications that can result in the need to
have visibility into VLAN information relates to the need (on
any LAN link where VLAN traffic may flow along different paths
or be delivered to different local end stations) to allow for
multiple DRB elections - using VLAN IDs as a differentiator.
This component of the complexity issues clearly only applies on
non point-to-point TRILL Links.
One approach suggested in dealing with this was to use VLAN ID
ranges. However, it is trivial to construct a network where this
necessarily results in sub-optimal to worst-case DRB selections
Gray Expires May, 2008 [Page 6]
Internet-Draft Scaling RBridge Deployments November 2007
for at least some portion of the network. At least one such
scenario has been discussed on the mailing list to date.
With minimal additional complexity, the proposal to use
(compressed) vector representation(s) - possibly including
directly re-using the representation used by MVRP - offers a
better approach at marginally higher cost.
However there is one flaw with either of these approaches in
that they both propose to use a reduction in messages by
combining VLAN specific messages for multiple VLANs and
propagating these messages over a reduced subset of the affected
VLANs. In fact, in most of the proposals to date a single VLAN
is proposed as a control VLAN - even in the case where multiple
802.1Q bridges are known to be present - and this can lead to
undetected partitioning of the network.
This could conceivably be detected if all of the 802.1Q bridges
also supported use of the MVRP VLAN state vector information,
but there is some indication that MVRP may not be commonly
deployed in 802.1Q bridges.
2.3. Messaging Complexity and Message Length
The details of messaging complexity are yet to be determined.
It is clear that there is a trade-off involved here between many
small messages (for the per-VLAN case) verses aa much smaller
number of much larger (and/or more complicated) messages.
Ideally, this section will contain not only analysis of this
information, but possibly simulation results - based on the same
set of scenarios used for peering complexity - as well.
3 Security Considerations
TBD.
4 IANA Considerations
TBD. Should be none.
5 Acknowledgments
TBD.
Gray Expires May, 2008 [Page 7]
Internet-Draft Scaling RBridge Deployments November 2007
6 References
6.1 Normative References
TBD.
6.2 Informative References
[1] 802.1D-2004 IEEE Standard for Local and Metropolitan Area
Networks: Media Access Control (MAC) Bridges
[2] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December, 1990.
[3] 802.1Q-2005 IEEE Standard for Local and Metropolitan Area
Networks: Virtual Bridged Local Area Networks
(Incorporates IEEE Std 802.1Q-1998, IEEE Std 802.1uT-2001,
IEEE Std 802.1vT-2001, and IEEE 802.1sT-2002)
Author's Addresses
Editor:
Eric Gray
Ericsson
900 Chelmsford Street
Lowell, MA, 01851
Phone: +1 (978) 275-7470
EMail: Eric.Gray@Ericsson.com
Gray Expires May, 2008 [Page 8]
Internet-Draft Scaling RBridge Deployments November 2007
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Gray Expires May, 2008 [Page 9]
Internet-Draft Scaling RBridge Deployments November 2007
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gray Expires May, 2008 [Page 10]
