Network Working Group D. Ward
Internet-Draft Cisco Systems
Expires: November 23, 2008 R. Perlman
Sun Microsystems
R. White
D. Farinacci
A. Banerjee
Cisco Systems
May 22, 2008
Carrying Attached Addresses in IS-IS
draft-ward-l2isis-03
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 November 23, 2008.
Abstract
This draft specifies the IS-IS extensions necessary to support multi-
link IPv4 and IPv6 networks, as well as to provide true link state
routing to any protocols running directly over layer 2. While
supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in
IS-IS is used.
Ward, et al. Expires November 23, 2008 [Page 1]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
1. Overview
There are a number of systems (for example, [RBRIDGES]) which have
proposed using layer 2 addresses carried in a link state routing
protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer
2 routing in specific environments. This draft proposes a set of
TLVs and sub-TLVs to be added to [IS-IS] level 1 PDUs, and three new
PDU types, to support these proposed systems.
This draft does not propose new forwarding mechanisms using this
additional information carried within IS-IS. There is a short
section included on two possible ways to build a shortest path first
tree including this information, to illustrate how this information
might be used.
2. Proposed Enhancements to IS-IS
This draft proposes additional TLVs, to carry unicast and multicast
attached address information. It also proposes additional sub-tlvs
to carry information regarding building trees for Layer 2 networks.
This draft proposes three new IS-IS PDUs, the Multicast Group
(MGROUP) PDU, for carrying a list of attached or joined multicast
groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP)
PDU and the Multicast Group Partical Sequence Number (MGROUP-PSNP)
PDU packets are also defined to be used with the new MGROUP-PDU to
perform database exchange on the MGROUP PDU packets.
2.1. The MAC-Reachability TLV
The MAC-Reachability (MAC-RI) sub-TLV is IS-IS TLV type 139 and has
the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type= MAC-RI | Length | Vlan-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (1) | MAC (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ward, et al. Expires November 23, 2008 [Page 2]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
o Type: TLV Type, set to 139 (MAC-RI).
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV.
o MAC(i): This is the 48-bit MAC address reachable from the IS that
is announcing this TLV.
The MAC-RI TLV is carried in a standard Level 1 link state PDU. It
MUST contain only unicast addresses.
2.2. The Group Address TLV
The Group Address (GADDR) TLV is IS-IS TLV type 140 [TBD] and has the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = GADDRTLV| Length | sub-tlvs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to GADDR-TLV 140 [TBD].
o Length: Total number of octets contained in the TLV, including the
length of the sub-tlvs carried in this TLV.
o sub-tlvs: The following sub-TLVs are defined.
The GADDR TLV is carried within Multicast Group Level 1 link state
PDU.
2.2.1. The Group MAC Address sub-TLV
The Group MAC Address (GMAC-ADDR) sub-TLV is IS-IS TLV type 1 and has
the following format:
+-+-+-+-+-+-+-+-+
| Type=GMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ward, et al. Expires November 23, 2008 [Page 3]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 1 (GMAC-ADDR) of length 1 byte.
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV.
o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed
by the number of sources, each of length 1 byte. It then has a
48-bit multicast Group Address followed by 48-bit source MAC
addresses. An address being a group multicast address or unicast
source address can be checked using the multicast bit in the
address.
The GMAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU.
2.2.2. The Group IP Address sub-TLV
The Group IP Address (GIP-ADDR) sub-TLV is IS-IS TLV type 2 and has
the following format:
Ward, et al. Expires November 23, 2008 [Page 4]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
+-+-+-+-+-+-+-+-+
| Type=GIP-ADDR |
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 2 (GIP-ADDR).
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV.
o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed
by the number of sources, each of length 1 byte. It is followed
by a 32-bit IPv4 Group Address followed by 32-bit source IPv4
addresses.
The GIP-ADDR TLV is carried within the GADDR TLV and MUST be carried
in a standard Level 1 link state MGROUP PDU.
Ward, et al. Expires November 23, 2008 [Page 5]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
2.2.3. The Group IPv6 Address sub-TLV
The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and
has the following format:
+-+-+-+-+-+-+-+-+
|Type=GIPv6-ADDR|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan-Id | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the form:
+-+-+-+-+-+-+-+-+
| RESERVED | (1 byte)
+-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 3 (GIPV6-ADDR).
o Length: Total number of octets contained in the TLV.
o Vlan-id: This carries a 16 bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV.
o Number of Group Records: This of length 1 byte and lists the
number of group records in this TLV.
o Group Record: Each group record has a reserved space and followed
by the number of sources, each of length 1 byte. It is followed
by a 128-bit multicast IPv6 Group Address followed by 128-bit
source IPv6 addresses.
Ward, et al. Expires November 23, 2008 [Page 6]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
The GIPV6-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU.
2.3. Sub-TLVs for the Capability TLV
The Capability TLV is an optional TLV [RFC 4971] that may be
generated by the originating IS. We introduce these additional sub-
TLVs that are carried within it. These sub-tlvs announce the
capabilities of the router for the entire IS-IS routing domain.
2.3.1. The Device ID sub-TLV
The Device ID (DEVID) sub-TLV carries information about the identity
of the advertising device, along with information about device
priority. The Device-Id sub-TLV MUST be carried within the
CAPABILITY TLV in a level-1 non-pseudo-node LSP generated by the
originating IS.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Id |
+---------------------------------------------------------------+
o Type: TLV Type, set to 5 (DEVID).
o Length: Total number of octets contained in the TLV.
o Options: Set to 0.
o Device ID: Left padded device ID or alias.
2.3.2. The Root Priority sub-TLV
The Root Priority sub-TLV MUST be carried within the CAPABILITY TLV
in a level-1 non-pseudo-node LSP generated by the originating IS.
Each switch announces a broadcast root-priority and a multicast root-
priority. Once a node receives a new LSP, it runs an election
algorithm, independently of the other nodes in the network, to
determine the broadcast root. The node that announced the lowest
broadcast priority becomes the root of the broadcast tree. If two
devices advertise the same broadcast priority, the device with the
lower system ID becomes the root of the broadcast tree. The elected
broadcast-root will decide on the multicast-roots based on the
multicast priorities advertised. The elected broadcast-root then
decides on the number of multicast trees to be computed and their
roots. This announcement takes place in the roots identifier sub-
TLV.
Ward, et al. Expires November 23, 2008 [Page 7]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = ROOT-PRI| Length | Br. Root Pri | Mu. Root Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 6 (ROOT-PRI).
o Length: Total number of octets contained in the TLV.
o Br Root Pri: This gives the value of the priority with which this
node wants to be the broadcast root node in the Layer-2 domain.
o Mu Root Pri: This gives the value of the priority with which this
node wants to be the multicast root node in the Layer-2 domain.
2.3.3. The Root Identifier Sub-tlv
The root identifier sub-tlv is populated by the root of the broadcast
tree. It is carried within the CAPABILITY TLV in a level-1 non-
pseudo-node LSP and is given as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type= ROOT-IDs | Length | Broadcast Root System Id... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Broadcast Root System Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Root System Id ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Multicast Root System Id | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 7 (ROOT-IDs).
o Length: Total number of octets contained in the TLV.
o Broadcast Root System Id: The Broadcast Root System ID at which a
broadcast tree is rooted. It is of length 6 bytes.
o Multicast Root System Id: The Multicast Root System ID at which a
multicast tree is rooted. It is of length 6 bytes.
A locally significant hash is used by edge devices to determine which
multicast root (or set of multicast roots) is used to send traffic
for a specific multicast group.
2.4. The Multicast Group PDU
The Multicast Group (MGROUP) PDU can be used to advertise a set of
attached, or joined, multicast groups. The MGROUP PDU is formatted
identical to a Level 1 Link State PDU, as described in Section 9.3 of
[IS-IS]. One field, PDU Type, is changed to [TBD], to signify this
PDU is carrying multicast group information, rather than unicast
reachability information.
Ward, et al. Expires November 23, 2008 [Page 8]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
The Multicast Group PDU carries TLVs indicating multicast groups.
There are three sub-TLVs defined in this document, that MAY be
present in this PDU, namely, GMAC-ADDR, GIP-ADDR, and GIPV6-ADDR
TLVs.
One or more TLVs MAY be carried in a single MGROUP PDU. Future
multicast address TLVs MAY be defined using other type codes, and be
carried in an MGROUP PDU.
2.5. The Multicast Group Partial Sequence Number PDU
The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used
to reliably flood the MGROUP PDU following the base protocol
specifications.
2.6. The Multicast Group Complete Sequence Number PDU
The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is
used to reliably flood the MGROUP PDU following the base protocol
specifications.
3. Considerations for Using L2 Information in IS-IS
While this document does not specify the way in which addresses
carried in these TLVs is used in IS-IS, two general areas of concern
are considered in this section: building the SPF tree when using this
information, and the election of designated intermediate systems
(DIS) in an environment using this information.
3.1. Building SPF Trees with Layer 2 Information
Each IS which is part of a single broadcast domain from a layer 2
perspective will build multiple SPF trees (SPT) for every IS that is
announced by the IS deemed to be the broadcast root.
We assume some mechanism for forwarding traffic to these attached
addresses added to the SPT is provided for in the mechanism proposing
the use of these extension TLVs.
3.2. Designated Intermediate Routers
A single DIS SHOULD be elected as described in [IS-IS] for each layer
2 broadcast domain (VLAN) for which information is being carried in
IS-IS. This reduces the amount of work required to flood and
maintain synchronized databases over the underlying media on which
IS-IS is running and providing layer 2 forwarding information for.
Ward, et al. Expires November 23, 2008 [Page 9]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
4. Acknowledgements
The authors would like to thank Les Ginsberg for his useful comments.
5. Security Considerations
This document adds no additional security risks to IS-IS, nor does it
provide any additional security for IS-IS.
6. IANA Considerations
This document creates three new PDU types, namely the MCAST PDU,
MCAST-CSNP PDU, and the MCAST-PSNP PDU. IANA SHOULD assign a new PDU
type to the level-1 PDUs described above and reflect it in the PDU
registry.
MCAST-PDU Level-1 PDU Type: 19
MCAST-CSNP-PDU Level-1 PDU Type: 22
MCAST-PSNP-PDU Level-1 PDU Type: 28
This document requires the definition a set of new ISIS TLVs, the
MAC-Reachability TLV (type 139), and the Group Address TLV (type 140)
that needs to be reflected in the ISIS TLV code-point registry.
This document creates a number of new sub-TLV in the numbering space
for the Group Address TLV and the Capability TLV. The TLV and sub-
TLVs are given below:
IIH LSP SNP MCAST MCAST
LSP SNP
MAC-RI TLV - X - - -
GADDR-TLV - - - X -
GADDR-TLV.GMAC-ADDR sub-tlv 1 - - - X -
GADDR-TLV.GMAC-IP sub-tlv 2 - - - X -
GADDR-TLV.GMAC-IPV6 sub-tlv 3 - - - X -
CAPABILITY.Device ID sub-tlv 5 - X - X -
CAPABILITY.Root Priority sub-tlv 6 - X - - -
CAPABILITY.Roots sub-tlv 7 - X - - -
IANA SHOULD manage the remaining space using the consensus method.
7. References
Ward, et al. Expires November 23, 2008 [Page 10]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
7.1. Normative References
[IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System
Intra-Domain Routing Exchange Protocol for use in
Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2005.
[RFC 1195]
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990.
[RFC 4971]
Vasseur, JP. and N. Shen, "Intermediate System to
Intermediate System (IS-IS) Extensions for Advertising
Router Information", 2007.
7.2. Informative References
[RBRIDGES]
Perlman, R. and J. Touch, "Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability
Statement", 2008.
Authors' Addresses
David Ward
Cisco Systems
Email: wardd@cisco.com
Radia Perlman
Sun Microsystems
Email: Radia.Perlman@Sun.com
Russ White
Cisco Systems
Email: riw@cisco.com
Ward, et al. Expires November 23, 2008 [Page 11]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
Dino Farinacci
Cisco Systems
Email: dino@cisco.com
Ayan Banerjee
Cisco Systems
Email: ayabaner@cisco.com
Ward, et al. Expires November 23, 2008 [Page 12]
Internet-Draft Carrying Attached Addresses in IS-IS May 2008
Full Copyright Statement
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.
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.
Intellectual Property
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.
Ward, et al. Expires November 23, 2008 [Page 13]