Network Working Group Donald Eastlake 3rd
INTERNET-DRAFT Motorola Laboratories
Intended status: Proposed Standard Radia Perlman
Sun Microsystems
Dinesh Dutt
Cisco
Expires: August 2008 February 2008
RBridges: Use of IS-IS
<draft-eastlake-trill-rbridge-isis-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 <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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
RBridges use 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 is an early specification
of the details of TRILL use of IS-IS for purposes of discussion.
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...........................4
2.1 Protocol Separation of IS-IS Instances.................4
2.2 Instance Separation of TRILL IS-IS Instances...........4
3. IS-IS PDU Details.......................................6
3.1 Hello PDUs.............................................6
3.2 LSP PDUs...............................................7
3.2.1 Core Instance LSP....................................7
3.2.2 Per VLAN Instance LSP................................9
3.3 CSNP/PSNP PDUs........................................10
3.4 MGROUP PDUs...........................................10
4. Specific TLVs..........................................11
4.1 Area Address..........................................11
4.2 Protocols Supported...................................11
5. Bridged LAN Link Costs.................................12
6. IANA Considerations....................................13
7. Security Considerations................................13
8. Normative References...................................14
9. Informative References.................................14
Disclaimer................................................15
Additional IPR Provisions.................................15
Author's Address..........................................16
Expiration and File Name..................................16
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 an extended version of the IS-IS
[ISIS] protocol. [ISIS-L2] specifies the general [ISIS] facilities
to provide true link state routing to any protocol running directly
over Layer 2.
This is an early draft 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 Designated RBridges
(DRBs, equivalent to Designated Intermediate Systems) and the like.
{{Comments in double curly braces relate to version -02 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:
AFI - IANA registered Address Family.
PDU - Protocol Data Unit.
RBridge - One of the devices which 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.
TRILL - The protocol specified partly in [RBRIDGE] and this
document.
** - Indicates exponentiation. 2**12 is two to the twelfth power.
D. Eastlake, R. Perlman, D. Dutt [Page 3]
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 use 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.
RBridges also optionally implement per-VLAN instances of TRILL IS-IS,
to carry information about attached endnodes in that VLAN. 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, and also, between the mandatory core instance of TRILL IS-
IS and per-VLAN instances.
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 can not 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 which 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
never 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 instance
per VLAN. VLANs are identified by a 12 bit field but the values 0x000
and 0xFFF are not allowed so there are 2**12 - 2 possible VLANs.
The multiple instance mechanism described in [ISIS-MI] is used to
D. Eastlake, R. Perlman, D. Dutt [Page 4]
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 per VLAN TRILL IS-IS instances, MUST
include the MI TLV with the instance number equal to their VLAN
ID.
D. Eastlake, R. Perlman, D. Dutt [Page 5]
INTERNET-DRAFT RBridges: Use of IS-IS
3. IS-IS PDU Details
[ISIS], as extended by [ISIS-L2], supports 4 types of PDUs: Hello,
LSP, CSNP/PSNP, and MGROUP. TRILL aspects of the contents of each of
the PDU types are listed below. Some specific TLVs are discussed in
Section 4 below.
All RBridges have a 6 octet System ID which is conveyed in the header
of every TRILL IS-IS PDU they produce, just as it is 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 features of IS-IS assume a unique 32-bit Router ID for an
RBridge this shall be the RBridge's 16-bit nickname right justified
with 16 leading zero bits added. If the nickname is unknown, the
entire Router ID field is zero.
All TRILL IS-IS PDUs MAY contain an Authentication TLV (TLV #10).
3.1 Hello PDUs
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.
Core TRILL IS-IS instance Hello PDUs MAY include one or more
Capability TLVs [RFC4971] (TLV #242). The nickname of the sending
RBridge appears in the Router ID field left filled with zeros. 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. Designated VLAN (subTLV #3.1a). This subTLV is included by the DRB
to designate the VLAN to be used for communications between
RBridges on the link. The length of the value is two octets. The
lower 4 bits of the first octet give the upper VLAN ID bits and
the second octet gives the lower VLAN ID bits. The upper 4 bits of
the first octet are reserved and MUST be sent as zero and ignored
on receipt. In the absence of a Designated VLAN subTLV from the
DRB, the Designated VLAN defaults to VLAN 1.
2. Appointed Forwarders (subTLV #3.1b). 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:
D. Eastlake, R. Perlman, D. Dutt [Page 6]
INTERNET-DRAFT RBridges: Use of IS-IS
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. An RBridge's
nickname may occur as appointed forwarder for multiple VLAN ranges
within the same or different router capability TLVs within the
DRB's Hellos. In the absence of appointed forwarder subTLVs, the
DRB act as the appointed forwarder.
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 per VLAN instances, 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 contents of a core TRILL IS-IS instance LSP PDU includes:
1. Information on reachable RBridge neighbors and the cost of the hop
MUST be included via a normal IIS neighbors TLV (TLV #2).
2. The RBridge nickname and other information via one or more
Capability TLVs [RFC4971] (TLV #242). The nickname appears in the
Router ID field left filled with zeros. 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 Exactly one TRILL Flags subTLV MUST be present (subTLV
#<tbd3.2.1a>). The length of the value of this subTLV is
variable with a minimum size of 2 octets. The first octet is
the RBridge's nickname priority. The top five bits of the
second 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 to be zero.
D. Eastlake, R. Perlman, D. Dutt [Page 7]
INTERNET-DRAFT RBridges: Use of IS-IS
first octet | second octet
| 0 1 2 3 4 5 - 7
+-------------------+----+----+----+----+----+-----------+
| nickname priority | V0 | V1 | V2 | V3 | RT | reserved |
+-------------------+----+----+----+----+----+-----------+
V0 through V4 indicate support of TRILL Header Versions 0
through 4. RT is the Request Tree flag. The remaining bits of
the first octet (and all bits of subsequent octets if present)
are reserved and MUST be zero when sent and ignored on
receipt. Exactly one TRILL Flags subTLV must occur in the link
state of every RBridge.
2.b Tree Roots (subTLV #<tbd3.2.1b>). 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 not provided, the originating
RBridge can only select itself (if its Request Tree flag is
true) or the RBridge with the lowest System ID (if the
originating RBridge's Request Tree flag is false).
2.c VLANs (subTLV #<tbd3.2.1c>). 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 but the union of the VLAN ranges in all occurrences
MUST be precisely the set of VLANs for which the originating
RBridge is appointed forwarder for at least one link 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
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.
D. Eastlake, R. Perlman, D. Dutt [Page 8]
INTERNET-DRAFT RBridges: Use of IS-IS
The list of zero or more spanning tree root bridge IDs is the
set of root bridge IDs seen for all links which are in any of
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 see 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.d VLAN Groups (subTLV #<tbd3.2.1d). 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 and the rest are
secondary, as described in [RBRIDGE]. This subTLV may appear
zero, one, or many times.
3.2.2 Per VLAN Instance LSP
The TRILL information in per VLAN instance LSP PDUs consists of one
or more ADDR TLVs [ISIS-L2]. Each ADDR TLV contains one or more AFI
sub-TLVs with AFI type 6 (EUI-48). Those AFI sub-TLVs list the
unicast addresses of end stations on links 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.
{{Either one octet of the "Reserved" 16 bits for the ADDR TLV needs
to be used for the TRILL end station Confidence octet or an
additional sub-TLV under the ADDR TLV needs to be defined to carry
the Confidence.}}
D. Eastlake, R. Perlman, D. Dutt [Page 9]
INTERNET-DRAFT RBridges: Use of IS-IS
{{[ISIS-L2] currently says that ADDR TLVs can only occur in pseudo-
node LSPs but, unless you generate a pseudo-node for every link, even
a point-to-point link from an RBridge to an end station, it seems
like they are associated with RBridges, not with pseudo-nodes.}}
Each ADDR TLV MAY also contain a VLAN sub-TLV giving the VLAN of
those end station addresses. However, this is not required because
that VLAN information is also conveyed by the required MI TLV and
also indicated by the Inner VLAN tag in the TRILL enveloping of the
per-VLAN TRILL IS-IS PDU.
{{The 32 bits provided for VLAN ID in [ISIS-L2] seems excessive. VLAN
IDs are currently all 12 bits.}}
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. Only
Level 1 sequence number packets are used by TRILL 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 ADDR TLVs each of which, in turn,
contains one or more AFI sub-TLVs with AFI number 6 (MAC-48). Those
AFI sub-TLVs list the IP-derived multicast addresses for which there
are listeners on links for which the originating RBridge is appointed
forwarder.
Each ADDR TLV MUST also contain a VLAN sub-TLV giving the VLAN of
those multicast addresses. If there are IP-derived multicast
listeners in more than one VLAN, then multiple ADDR TLVs must be
originated by the RBridge. This information must be in the core IS-
IS instance so transit RBridges can perform optional multicast
distribution optimization.
{{The 32 bits provided for VLAN ID in [ISIS-L2] seems excessive. VLAN
IDs are currently all 12 bits.}}
All TRILL MGROUP PDUs contain the TRILL Area Address TLV (see Section
4.1).
D. Eastlake, R. Perlman, D. Dutt [Page 10]
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 11]
INTERNET-DRAFT RBridges: Use of IS-IS
5. Bridged LAN Link Costs
RBridges using IS-IS to support TRILL 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 links.
RBridges can automatically detect this condition under some
circumstances.
For certain 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 either RBridge is seeing BPDUs it is likely that there are one or
more intervening bridges.
When a link is a bridged LAN, transit traffic will experience at
least two bridged 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 autoconfigured from port speed).
More precise link cost can be asserted by management configuration.
D. Eastlake, R. Perlman, D. Dutt [Page 12]
INTERNET-DRAFT RBridges: Use of IS-IS
6. IANA Considerations
IANA needs to add six subTLV value 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
---- -----
Designated VLAN <tbd3.1a>
Appointed Forwarders <tbd3.1b>
TRILL Flags <tbd3.2.1a>
Tree Roots <tbd3.2.1b>
VLANs <tbd3.2.1c>
VLAN Groups <tbd3.2.1d>
NOTE: The IANA registry entry for AFI (Address Family) 6 has
traditionally said "802 (includes all 802 media plus Ethernet
'canonical format')". This was copied from RFC 1700 but may have been
dated for some time as there are different size addresses used in
IEEE 802, at least 48-bit (MAC-48) and 64-bit (MAC-64) addresses.
While 48-bit addresses are the most common, 64-bit addresses are, for
example, used in IEEE 802.15.4 (ZigBee). In this document, AFI 6 is
assumed to mean MAC-48 address. It is suggested that the AFI
registry value 6 entry be changed to "IEEE 802 MAC-48 addresses".
Should there be a need to use IEEE 802 MAC-64, or some type of IEEE
802 addresses other than MAC-48 or MAC-64, then a new AFI should be
allocated for each such type.
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 13]
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-02.txt, work in progress, June 2007.
[ISIS-MI] - S. Previd et. al., "IS-IS Multi-instance", draft-isis-
mi-00.txt, work in progress, May 2007.
[RBRIDGE] - "Rbridges: Base Protocol Specification", draft-ietf-
trill-rbridge-protocol-07.txt, work in progress, October 2007.
[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 14]
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 15]
INTERNET-DRAFT RBridges: Use of IS-IS
Author's Address
Donald E. Eastlake 3rd
Motorola Laboratories
111 Locke Drive
Marlborough, MA 01752
Phone: +1-508-786-7554
email: Donald.Eastlake@motorola.com
Radia Perlman
Sun Microsystems
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 August 2008.
Its file name is <draft-eastlake-trill-rbridge-isis-00.txt>.
D. Eastlake, R. Perlman, D. Dutt [Page 16]