Network Working Group Donald Eastlake 3rd
INTERNET-DRAFT Eastlake Enterprises
Intended status: Proposed Standard Radia Perlman
Sun Microsystems
Dinesh Dutt
Cisco
Expires: February 2009 August 3, 2008
RBridges: Use of IS-IS
<draft-eastlake-trill-rbridge-isis-01.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 <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
RBridges implement the TRILL protocol, which in turn makes use of an
extended version of the IS-IS (Intermediate System to Intermediate
System) routing protocol to determine topology and frame forwarding.
RBridges provide optimal pair-wise forwarding with zero
configuration, safe forwarding even during periods of temporary
loops, and multipathing for both unicast and multicast traffic.
Rbridges also support VLANs. This document specifies details of TRILL
use of IS-IS.
D. Eastlake, R. Perlman, & D. Dutt [Page 1]
INTERNET-DRAFT RBridges: Use of IS-IS
Table of Contents
Status of This Document....................................1
Abstract...................................................1
Table of Contents..........................................2
1. Introduction............................................3
1.1 Terminology............................................3
2. Separation of IS-IS Instances...........................5
2.1 Protocol Separation of IS-IS Instances.................5
2.2 Instance Separation of TRILL IS-IS Instances...........5
3. TRILL IS-IS PDU Details.................................7
3.1 Hello PDUs.............................................7
3.2 LSP PDUs...............................................9
3.2.1 Core Instance LSP....................................9
3.2.2 ESADI LSP...........................................12
3.3 CSNP/PSNP PDUs........................................12
3.4 MGROUP PDUs...........................................13
4. Specific TLVs..........................................14
4.1 Area Address..........................................14
4.2 Protocols Supported...................................14
5. Bridged LAN Link Costs.................................15
6. IANA Considerations....................................16
7. Security Considerations................................16
8. Normative References...................................17
9. Informative References.................................17
Disclaimer................................................18
Additional IPR Provisions.................................18
Author's Address..........................................19
Expiration and File Name..................................19
D. Eastlake, R. Perlman, & D. Dutt [Page 2]
INTERNET-DRAFT RBridges: Use of IS-IS
1. Introduction
[RBRIDGE] specifies the TRILL base protocol which provides optimal
pair-wise forwarding with zero configuration, safe forwarding even
during periods of temporary loops, and multipathing for both unicast
and multicast traffic. Rbridges also support VLANs. The TRILL
protocol, in turn, makes use of the IS-IS [ISIS] protocol with
certain extensions. [ISIS-L2] specifies the general [ISIS]
facilities to provide true link state routing to any protocol running
directly over Layer-2.
This is a specification of details of TRILL use of IS-IS
concentrating on IS-IS PDU content. It makes use of the Router
Capabilities TLV [RFC4971] although perhaps some other TLV or a new
TLV would be better in some cases. [RBRIDGE] specifies the TRILL
enveloping of IS-IS PDUs and the flow of such PDUs, along with the
determination of the Designated RBridges (DRB, equivalent to the DIS
(Designated Intermediate System)) on a link and the like.
{{Comments in double curly braces relate to version -03 of [ISIS-
L2].}}
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
The following other special words or acronyms are used in this
document:
CSNP - Complete Sequence Number PDU
ESADI - End Station Address Distribution Instance.
LSP - Link State PDU
PDU - Protocol Data Unit.
PSNP - Partial Sequence Number PDU
RBridge - Routing Bridge. One of the devices that implement TRILL.
The second letter in Rbridge is case insensitive. Both Rbridge
and RBridge are correct.
TLV - Type, Length, Value. The general format of the data elements
included as the content of IS-IS PDUs after their header.
D. Eastlake, R. Perlman, & D. Dutt [Page 3]
INTERNET-DRAFT RBridges: Use of IS-IS
TRILL - TRansparent Interconnection of Lots of Link. The protocol
specified partly in [RBRIDGE] and document.
** - Indicates exponentiation. 2**12 is two to the twelfth power.
D. Eastlake, R. Perlman, & D. Dutt [Page 4]
INTERNET-DRAFT RBridges: Use of IS-IS
2. Separation of IS-IS Instances
TRILL implements separate IS-IS instances from those used by Layer 3,
that is, different from the one used by IP routers. It is important
that these be distinguishable to avoid possible confusion that would
occur if an IS-IS instance attempted to process IS-IS PDUs intended
for a different instance.
TRILL implements multiple instances of IS-IS for its own use. One,
mandatory instance, includes information such as basic connectivity
between routers, location of VLANs, location of IP multicast routers,
and the like. RBridges also optionally implement TRILL IS-IS ESADIs
(End Station Address Distribution Instances), to carry information
about attached end nodes. Section 2.1 explains how TRILL encodes IS-
IS frames to ensure that there is no confusion between TRILL
instances of IS-IS and Layer-3 instances of IS-IS or between the
mandatory core instance of TRILL IS-IS and ESADIs.
2.1 Protocol Separation of IS-IS Instances
TRILL IS-IS Layer-2 frames differ from those for Layer-3 use of IS-IS
and cannot be accidentally confused with them as follows:
1. TRILL IS-IS frames consist of an IS-IS frame enveloped within a
frame that uses the TRILL Ethertype and has an inner multicast
destination address of All-IS-IS-RBridges.
2. Native frames for Layer-3 IS-IS are sent to either the AllL1ISs
(01-80-C2-00-00-14) or AllL2ISs (01-80-C2-00-00-15) multicast
addresses. TRILL frames that are enveloped Layer-3 IS-IS do NOT
have All-IS-IS-RBridges as their inner destination address (it
will be AllL1ISs or AllL2ISs) and so are treated as ordinary TRILL
data frames
3. TRILL uses a distinct, constant IS-IS Area Address that would not
appear as a real Layer-3 IS-IS area address. This Area Address is
the value zero. (See Section 4.1.)
2.2 Instance Separation of TRILL IS-IS Instances
An RBridge campus may have up to (1 + 2**12 - 2) instances of TRILL
IS-IS; that is, one mandatory core instance plus one optional ESADI
per VLAN. A 12-bit field identifies a VLAN but the values 0x000 and
0xFFF are not allowed so there are (2**12 - 2) legal VLANs.
The multiple instance mechanism described in [ISIS-MI] is used to
D. Eastlake, R. Perlman, & D. Dutt [Page 5]
INTERNET-DRAFT RBridges: Use of IS-IS
distinguish these TRILL IS-IS instances for convenience in cases
where they are executed in one process on an Rbridge. In particular:
1. All IS-IS PDUs for the mandatory core TRILL IS-IS instances MAY
include the MI TLV with the instance number of zero, and
2. All IS-IS PDUs for optional TRILL IS-IS ESADIs, MUST include the
MI TLV with the instance number equal to their VLAN ID.
The instance identifier TLV is type #7.
D. Eastlake, R. Perlman, & D. Dutt [Page 6]
INTERNET-DRAFT RBridges: Use of IS-IS
3. TRILL IS-IS PDU Details
[ISIS], as extended by [ISIS-L2], supports 7 types of PDUs: Hello,
LSP, CSNP, PSNP, MGROUP, MGROUP CSNP, and MGROUP PSNP. TRILL aspects
of the contents of each of the PDU types are specified in this
Section. Some individual TLVs types are discussed in Section 4 below.
All RBridges have a 6-octet System ID that is conveyed in the header
of every TRILL IS-IS PDU they produce, just as in Layer-3 IS-IS. The
Maximum Area Addresses octet in the common fixed header is set to
0x01. An RBridge campus is a single Level 1 IS-IS Area.
Where some IS-IS TLVs assume a unique 32-bit Router ID, in TRILL IS-
IS this field is zero
All TRILL IS-IS PDUs MAY contain an Authentication TLV (TLV #10).
3.1 Hello PDUs
Hellos are only used in the core instance of TRILL IS-IS. The core
instance link state contains enough information that the DRB,
adjacencies, and holding time for any ESADI can be determined without
Hellos. (See Section 4.2.4.1 of [RBRIDGE].)
All TRILL Hello PDUs contain the TRILL Area Address TLV (see Section
4.1). The Circuit Type two bit field of TRILL IS-IS Hello PDUs MUST
be set to 0b01 indicating Level 1 only.
An IS Neighbor TLV (TLV #6) MUST be included in a TRILL Hello if the
Hello is sent on the Designated VLAN and MUST NOT be included if it
is sent on any other VLAN.
Core IS-IS instance Hello PDUs MUST include one or more Capability
TLVs [RFC4971] (TLV #242). The D and S flags in the Capability TLV
MUST be zero. Other information is included by instances of the
following TRILL related subTLVs:
1. Special VLANs (subTLV #<tbd3.1a>). This subTLV MUST appear once in
a Capability TLV in every TRILL Hello PDU. The length of the value
is four octets.
The first two octets are a copy of the Outer.VLAN tag value
associated with the Hello frame when it was sent.
The third and forth octets give the Designated VLAN for the link.
The lower 4 bits of the third octet give the upper ID bits of the
Designated VLAN and the forth octet gives the lower VLAN ID bits.
The upper 4 bits of the third octet are reserved and MUST be sent
D. Eastlake, R. Perlman, & D. Dutt [Page 7]
INTERNET-DRAFT RBridges: Use of IS-IS
as zero and ignored on receipt.
2. Enabled VLANs (subTLV #<tbd3.1b>). Specifies the VLANs enabled for
output at the port on which the Hello was sent. The minimum size
of the value is 3 octets. The third and subsequent octets provide
a bit map of enabled VLANs starting at the VLAN ID indicated in
the first two octets. The lower order four bits of the first octet
give the upper bits of the starting VLAN ID and the second octet
gives the lower bits of that VLAN ID. The upper four bits of the
first octet are reserved and MUST be sent as zero and ignored on
receipt. The highest order bit of the third octet indicates the
VLAN equal to the starting ID while the lowest order bit of the
third octet indicated that ID plus 7. For example, VLANs 1 and 14
being enabled could be encoded in 4-octets value 0x00 0x01 0x80
0x04.
This subTLV may occur more than once in a TRILL Hello and a VLAN
is enabled for output on the port where the Hellos was sent if
this is indicated by any occurrence in the Hello. For example, a
receiver could allocate a 512-octet buffer and, with appropriate
shifting operations, OR in the enabled bits for each TLV of this
type it finds in a Hello to derive the complete bit map of enabled
VLANs.
3. Appointed Forwarders (subTLV #<tbd3.1c>). This subTLV provides the
mechanism by which the DRB can inform other RBridges on the link
that they are the designated VLAN-x forwarder for that link for
one or more ranges of VLAN IDs. The size of the value is 5*n
octets where there are n appointments. Each 5 octet part of the
value is formatted as follows:
| octet 1 | octet 2 | octet 3 | octet 4 | octet 5 |
+----------+----------+----------+-----+----+----------+
| Appointee Nickname | Start VLAN ID | End VLAN ID |
+----------+----------+----------+-----+----+----------+
The VLAN range give is inclusive. To specify a single VLAN, that
VLAN ID appears as both the start and end VLAN. The RBridge whose
nickname is given is appointed forwarder for those VLANs for which
it has end station service enabled (see item 2 above) in the
inclusive range. For example, assume an RBridge with end station
service enabled on VLANs 100, 101, 199, and 200 (and possibly
other VLANs less than 100 or greater than 200), but not enabled
for VLANS 102 through 19. It could be appointed forwarder for
these four VLANs through either (1) a single 5-octet value
sequence with start and end VLAN IDs of 100 and 200, or (2) a
10-octet value sequence with start and enc VLAN IDs of 100 and 101
in the first part and 199 and 200 in the second part.
An RBridge's nickname may occur as appointed forwarder for
D. Eastlake, R. Perlman, & D. Dutt [Page 8]
INTERNET-DRAFT RBridges: Use of IS-IS
multiple VLAN ranges within the same or different router
capability TLVs within a DRB's Hello. In the absence of appointed
forwarder subTLVs referring to a VLAN, the DRB acts as the
appointed forwarder for that VLAN if it has end station service
enabled for its port on that link.
3.2 LSP PDUs
The TLVs to be included in TRILL LSP PDUs are very different for the
mandatory core IS-IS instance of a campus, discussed in Section 3.2.1
below, and in the optional ESADIs, discussed in section 3.2.2 below.
All TRILL LSP PDUs contain the TRILL Area Address TLV (see Section
4.1). In addition, in the LSP header, the P Flag and Att flags MUST
be zero and the IS type two bit field MUST be set to 0b01 indicating
Level 1.
3.2.1 Core Instance LSP
The content of core TRILL IS-IS instance LSP PDUs includes:
1. Information on reachable RBridge neighbors and the cost of the hop
via the usual IIS neighbors TLV (TLV #2).
2. The RBridge flags, nickname, VLANs, and other information via one
or more Capability TLVs [RFC4971] (TLV #242). The D and S flags in
the Capability TLV MUST be zero. Other information is included by
instances of the following TRILL related subTLVs:
2.a TRILL Flags (subTLV #<tbd3.2.1a>). Exactly one TRILL Flags
subTLV must occur in the link state of every RBridge. The
length of the value of this subTLV is variable with a minimum
size of 1 octet. The top four bits of the first octet are
defined as below. Additional bits may be specified in the
future and those bits may extend into subsequence octets. The
value of all bits in any octets not present is assumed by a
receiver to be zero.
first octet
0 1 2 3 4 - 7
+----+----+----+----+-----------+---
| V0 | V1 | V2 | V3 | reserved |
+----+----+----+----+-----------+---
V0 through V4 indicate support of TRILL Header Versions 0
through 4. The remaining bits of the first octet (and all bits
D. Eastlake, R. Perlman, & D. Dutt [Page 9]
INTERNET-DRAFT RBridges: Use of IS-IS
of subsequent octets if present) are reserved and MUST be zero
when sent and ignored on receipt.
2.b Nickname and Tree Root (subTLV #<tbd3.2.1b>). If an RBridge is
to be able to act as an ingress, egress, or tree root, it must
have a nickname. The value is either 3, 5, or 7 octets in
length. The first octet is the RBridge's nickname priority and
the second and third octets are its nickname. If octets 4 and
5 are present, they are the RBridge's priority to be a tree
root as an unsigned 16-bit integer that defaults to 0x8000 if
absent. If octets 6 and 7 are present, they are an unsigned
16-bit integer that gives the number of additional trees every
RBridge in the campus is to compute if the RBridge in whose
link state this occurs is the highest priority tree root. If
octets 6 and 7 are absent, this number of additional trees
defaults to 1. (See [RBRIDGE] Section 4.3.)
{{While the Device ID subTLV in [ISIS-L2] could be used for
Nickname, putting the Nickname priority in 8 of the Options
bits, the Root Priority subTLV and Root Identity subTLV in
[ISIS-L2] does not correspond with how RBridges determine
distribution tree roots or multi-path multi-destination
frames.}}
2.c Distribution Tree Roots (subTLV #<tbd3.2.1c>). The value is a
variable length array of the nicknames of the RBridges which
the originating RBridge might pick as the root of the
distribution tree for multi-destination traffic for which it
is the ingress RBridge. If the list is empty or this subTLV is
not provided, the originating RBridge can only select the
highest priority tree root (see [RBRIDGE] Section 4.3).
2.d VLANs (subTLV #<tbd3.2.1d>). The value of this subTLV consists
of a VLAN range, flags, and a variable length list of spanning
tree root bridge IDs. This subTLV may appear zero, one, or
many times. The union of the VLAN ranges in all occurrences
MUST be precisely the set of VLANs for which the originating
RBridge is appointed forwarder on at least one port and the
VLAN ranges in multiple VLANs subTLVs for an RBridge MUST NOT
overlap. That is, the intersection of the VLAN ranges for any
pair of these subTLVs originated by an RBridge must be null.
The value length is 4 + 6*n where n is the number of root
bridge IDs. The initial 4 octets of value are as follows:
0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+--
| M4 | M6 | OM | R | VLAN start | Reserved | VLAN end |
+----+----+----+----+------------+----------+------------+--
The M4 bit indicates that there is an IPv4 multicast router on
D. Eastlake, R. Perlman, & D. Dutt [Page 10]
INTERNET-DRAFT RBridges: Use of IS-IS
a link for which the originating RBridge is appointed
forwarder for every VLAN in the indicated range. The M6 bit
indicates the same for an IPv6 multicast router. The OM bit
indicates that this RBridge requests that all non-IP derived
multicast traffic in the indicated VLAN range be sent to it.
The R and Reserved bits MUST be sent as zero and are ignored
on receipt.
The VLAN start and end IDs are inclusive. A range of one VLAN
ID is indicated by setting them both to that VLAN ID value.
The list of zero or more spanning tree root bridge IDs is the
set of root bridge IDs seen for all ports for the VLANs in the
range and for which the RBridge is appointed forwarder. This
information is learned from BPDUs heard by the RBridge. If
MSTP is in use on a link, the root bridge referred to is the
CIST (common and internal spanning tree) root bridge. While,
of course, only one spanning tree root should be seen on any
particular port, there may be multiple ports in the same VLAN
connected to differed bridged LANs with different spanning
tree roots. If no spanning tree roots can be seen on any of
the links in any of the VLANs in the range indicated for which
the RBridge is appointed forwarder (for example all such links
are point-to-point links to other RBridges or to end stations
so no BPDUs are received) then the listed set of spanning tree
root IDs will be null.
If there are any two VLANs in the range indicated for which
the value of the M4, M6, or OM bits are different, the subTLV
is incorrect and must be split into multiple subTLVs each
indicating only VLANs with the same M4, M6, and OM values. If
there are any two VLANs in the range indicated for which the
set of root bridge IDs see on all links for which the RBridge
is appointed forwarder for the VLAN are not the same, the
subTLV is incorrect and must be split into multiple subTLVs
each indicating only VLANs with the same set of DRB seen root
bridge IDs. It is always safe to use subTLVs with a "range" of
one VLAN ID but this may be too verbose.
2.e ESADI Participation (subTLV #<tbd3.2.1e>). The value of this
optional subTLV is 6*N octets where N is the number of VLAN
ranges given. The presence of this subTLV in the LSP for an
RBridge constitutes the ESADI participation flag for the VLANs
in the range or ranges given. Each 6 octets of value is
structured as follows:
0 1-7 | 8-15 | 16-19 20-23 | 24-31 | 32-39 |
+-+----------+------+-------+-------+-------+--------------+
|R| Priority | VLAN start | VLAN end | Holding Time |
+-+----------+------+-------+-------+-------+--------------+
D. Eastlake, R. Perlman, & D. Dutt [Page 11]
INTERNET-DRAFT RBridges: Use of IS-IS
The R bit is reserved and MUST be sent as zero and ignored on
receipt. The Priority field gives the RBridge's priority for
being DRB on the EASDI virtual links for the VLAN or VLANs
indicated while the Holding Time field gives its holding time
if it is DRB. The VLAN start and end values give the inclusive
range of VLAN IDs for which the RBridge wishes to participate
in an ESADI. A range of one VLAN is specified by making the
start and end IDs equal.
2.f VLAN Groups (subTLV #<tbd3.2.1f>). The value of this optional
subTLV consists of two or more 16-bit fields each of which has
a VLAN ID in the low order 12 bits and the top 4 bits zero.
The first such VLAN ID is the primary, or may be zero if there
is no primary. Address learning is shared between the listed
VLANs at the originating RBridges as described in Section
4.6.3 of [RBRIDGE]. This subTLV may appear zero, one, or many
times.
Note: See Section 3.4 below for multicast groups.
3.2.2 ESADI LSP
The TRILL information in ESADI LSP PDUs consists of one or more MAC
Reachability (MAC-RI) TLVs [ISIS-L2] (TLV #139). Each MAC-RI TLV
contains the VLAN ID and one or more unicast MAC addresses of end
stations which are both on a port and in a VLAN for which the
originating RBridge is appointed forwarder, along with the one octet
unsigned Confidence in this information with a value in the range
0-254.
{{There is no place in the current MAC-Reachability TLV for the
confidence level. It could go where the VLAN-ID currently is as the
VLAN ID is not needed for the TRILL use. Alternatively, some option
bits and the confidence could be inserted before or after the VLAN-
ID. Or the confidence could be changed to 4 bits and packed in with
the VLAN-ID...}}
3.3 CSNP/PSNP PDUs
CSNP stands for Complete Sequence Number Packet and PSNP for Partial
Sequence Number Packet. These relate to the IS-IS link state flooding
algorithm and link state sequence numbers. There is no change from
typical Layer-3 sequence number IS-IS PDUs except for the inclusion
of instance separation TLVs as indicated in Section 2 above and the
addition of MGROUP CSNP and PSNP PDUs. TRILL IS-IS uses only Level 1
sequence number packets.
D. Eastlake, R. Perlman, & D. Dutt [Page 12]
INTERNET-DRAFT RBridges: Use of IS-IS
3.4 MGROUP PDUs
MGROUP PDUs [ISIS-L2] are only sent as part of the core IS-IS
instance. They contain one or more Group Address (GADDR) TLVs each of
which, in turn, contains one or more Group MAC Address (GMAC-ADDR)
sub-TLVs. Those GMAC-ADDR sub-TLVs specify the VLAN involved and list
the IP-derived multicast addresses for which there are listeners on
links for which the originating RBridge is appointed forwarder.
(MGROUP PDUs must be in the core instance of TRILL IS-IS, even if an
ESADI is in use for the relevant VLAN, so that transit RBridges can
properly prune the distribution of multicast frames.)
All TRILL MGROUP PDUs contain the TRILL Area Address TLV (see Section
4.1).
D. Eastlake, R. Perlman, & D. Dutt [Page 13]
INTERNET-DRAFT RBridges: Use of IS-IS
4. Specific TLVs
This section describes particular TLVs included or not included in
TRILL IS-IS PDUs.
4.1 Area Address
The TRILL zero Area Address TLV is encoded as follows:
+--------------------------+--------------------------+
| 0x01 (Area Address TLV) | 0x02 (Length of Value) |
+--------------------------+--------------------------+
| 0x01 (Length of Address) | 0x00 (zero Area Address) |
+--------------------------+--------------------------+
4.2 Protocols Supported
Since no NLPID (Network Layer Protocol Identifier) has been allocated
by the ISO/IEC TR 9577 Registry for the Ethernet protocol or MAC-48
address type or TRILL, there is no way to indicate support of IS-IS
routing for these in a Protocols Supported TLV (TLV #129).
D. Eastlake, R. Perlman, & D. Dutt [Page 14]
INTERNET-DRAFT RBridges: Use of IS-IS
5. Bridged LAN Link Costs
RBridges use IS-IS to support TRILL and may be interconnected by
direct links such as 802.3, or by bridged LANs. If there an
intervening bridge or bridges, the link is really multiple bridged
physical links. RBridges can automatically detect this condition
under some circumstances.
For loop avoidance purposes RBridges listen for BPDUs and keep track
of the most recent announced root bridge on a link [RBRIDGE], if any.
This bridge, or the fact that no BPDUs have been received, is
reported in the link state database as described in Section 3.2.1
above. It is still possible for RBridges to be connected by a
bridged LAN where the bridge ports to which they are connected have
been configured not to emit BPDUs. On the other hand, if any RBridge
connected to a link is seeing BPDUs, it is likely that there are one
or more intervening bridges between it and any RBridge on the link to
which it appears to be adjacent.
When a link is a bridged LAN, transit traffic will experience at
least two bridged physical links and possibly many more. To account
for this, RBridges SHOULD assume, for IS-IS routing purpose, that the
default metric for traversing such a link is 2*C + 1, where C is the
Layer-3 IS-IS default metric (usually auto-configured from port
speed).
More precise link cost can be asserted by management configuration.
D. Eastlake, R. Perlman, & D. Dutt [Page 15]
INTERNET-DRAFT RBridges: Use of IS-IS
6. IANA Considerations
IANA needs to add nine subTLV values under the IS-IS Capabilities TLV
(#242). They are all specified in Section 3.1 and 3.2.1 above and are
as follows:
Name Value
---- -----
Special VLANs <tbd3.1a>
Enabled VLANs <tbd3.1b>
Appointed Forwarders <tbd3.1c>
TRILL Flags <tbd3.2.1a>
Nickname and Tree Root <tbd3.2.1b>
Distribution Tree Roots <tbd3.2.1c>
VLANs <tbd3.2.1d>
ESADI Participation <tbd3.2.1e>
VLAN Groups <tbd3.2.1f>
7. Security Considerations
This document raises no new security issues for IS-IS. IS-IS
security may be used to secure the IS-IS messages discussed here.
See [RFC3567]. See [RBRIDGE] for TRILL Security Considerations.
D. Eastlake, R. Perlman, & D. Dutt [Page 16]
INTERNET-DRAFT RBridges: Use of IS-IS
8. Normative References
[ISIS] - "Intermediate system to Intermediate system routeing
information exchange protocol for use in conjunction with the
Protocol for providing the Connectionless-mode Network Service
(ISO 8473)", ISO, ISO/IEC 10589:1992.
[ISIS-L2] - D. Ward et. al, "Carrying Attached Addresses in IS-IS",
draft-ward-l2isis-03.txt, work in progress, May 2008.
[ISIS-MI] - S. Previd et. al., "IS-IS Multi-instance", draft-ietf-
isis-mi-00.txt, work in progress, February 2008.
[RBRIDGE] - "Rbridges: Base Protocol Specification", draft-ietf-
trill-rbridge-protocol-08.txt, work in progress, July 2008.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4971] - Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
"Intermediate System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", RFC 4971, July 2007.
9. Informative References
[RFC3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic Authentication", RFC
3567, July 2003.
D. Eastlake, R. Perlman, & D. Dutt [Page 17]
INTERNET-DRAFT RBridges: Use of IS-IS
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.
D. Eastlake, R. Perlman, & D. Dutt [Page 18]
INTERNET-DRAFT RBridges: Use of IS-IS
Author's Address
Donald E. Eastlake 3rd
Eastlake Enterprises
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-634-2066
email: d3e3e3@gmail.com
Radia Perlman
Sun Microsystems
16 Network Circle
Menlo Park, CA 94025
Phone: +1-650-960-1300
Email: Radia.Perlman@sun.com
Dinesh G. Dutt
Cisco Systems
170 Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1-408-527-0955
email: ddutt@cisco.com
Expiration and File Name
This draft expires in February 2009.
Its file name is <draft-eastlake-trill-rbridge-isis-01.txt>.
D. Eastlake, R. Perlman, & D. Dutt [Page 19]