Network Working Group D. Ward
Internet-Draft R. White
Expires: May 3, 2009 D. Farinacci
A. Banerjee
Cisco Systems
R. Perlman
Sun Microsystems
November 3, 2008
Carrying Attached Addresses in IS-IS
draft-ward-l2isis-04
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 3, 2009.
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 May 3, 2009 [Page 1]
Internet-Draft Carrying Attached Addresses in IS-IS October 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 Partial 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 141 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 May 3, 2009 [Page 2]
Internet-Draft Carrying Attached Addresses in IS-IS October 2008
o Type: TLV Type, set to 141 (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 142 [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 142 [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 May 3, 2009 [Page 3]
Internet-Draft Carrying Attached Addresses in IS-IS October 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 May 3, 2009 [Page 4]
Internet-Draft Carrying Attached Addresses in IS-IS October 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 IPv4 source or group 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 May 3, 2009 [Page 5]
Internet-Draft Carrying Attached Addresses in IS-IS October 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 IPv6 source or group 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 May 3, 2009 [Page 6]
Internet-Draft Carrying Attached Addresses in IS-IS October 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 | Reserved | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Device Id |
+---------------------------------------------------------------+
o Type: TLV Type, set to 5 (DEVID).
o Length: Total number of octets contained in the TLV.
o Reserved: Set to 0.
o Priority: Set to application dependent values.
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 device announces a broadcast root-priority and the number of
trees it expects all other nodes to compute if it does become the
broadcast root. 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 decides on the multicast-roots to be used in the
network domain and their roots. This announcement takes place in the
roots identifier sub-TLV.
Ward, et al. Expires May 3, 2009 [Page 7]
Internet-Draft Carrying Attached Addresses in IS-IS October 2008
+-+-+-+-+-+-+-+-+
|Type = ROOT-PRI|
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Broadcast Root Pri | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num of multi-destination trees | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Num of multi-destination trees: This gives the number of
distribution trees for multi-destination frames that will be in
use in the Layer-2 domain, excluding the broadcast tree rooted at
itself, if this device becomes the broadcast root in the domain.
2.3.3. The Root Identifier Sub-tlv
The root identifier sub-tlv is populated by the root of the broadcast
tree. If this is also announced by other nodes in the network, it
implies that the specific node that is advertising it will only
restrict traffic to the common set of the trees in its announcement
and the ones announced by the broadcast root. 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. If there is a discrepancy between
Ward, et al. Expires May 3, 2009 [Page 8]
Internet-Draft Carrying Attached Addresses in IS-IS October 2008
the number of multi-destination trees the broadcast-root has
announced, and the number of roots the root-identifier carries, nodes
should compute trees on the additional roots.
3. The Multicast Group PDU
The systems that this draft is concerned with want to carry not only
layer-2 unicast information in the link state protocols, but also
multicast information. This draft has defined a new Multicast Group
(MGROUP) PDU that can be used to advertise a set of attached, or
joined, multicast groups. Accordingly, it has also introduced a
couple more PDUs as described in the next sections for the flooding
and update process to work seamlessly.
In the Layer-2 environment, it is expected the join/leave frequency
of the multicast members will be much higher than unicast topology
changes. It is efficient to separate the updates for the group
membership change information from the remainder of the information
by placing this information in a separate PDU. This enables
reachability information, that would trigger an SPF, to be not
impacted at all. Furthermore, during SPF runs, TLVs being on
different PDUs which do not affect SPF need not be inspected during
processing.
The choice of a different PDU also opens the LSP-space to another 256
fragments to carry a large number of groups. This additional space
can be used judiciously to carry only multicast information.
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 19 [TBD], to signify
this PDU is carrying multicast group information, rather than unicast
reachability information.
The Multicast Group PDU carries TLVs indicating multicast membership
information. There are three sub-TLVs of the GADDR TLV 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.
Ward, et al. Expires May 3, 2009 [Page 9]
Internet-Draft Carrying Attached Addresses in IS-IS October 2008
3.1. 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.
3.2. 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.3. Enhancements to the flooding process
This draft proposes that the information contained in the MGROUP-PDU
is in a parallel database and its update mechanisms mimic that of the
regular database. Nodes running IS-IS in an L2 domain MUST support
these additional MGROUP PDUs defined in this draft. In general, the
flooding of the MGROUP-PDU in tandem with the MGROUP-PSNP and MGROUP-
CSNP PDUs uses the same update procedures as defined for the regular
LSP, PSNP, and CSNP PDUs.
For example, on P2P links CSNP is exchanged on the formation of an
adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged
between the neighbors at the same time. This gets the initial
MGROUP-database synchronization going. After this similar actions of
the base protocol specifications for the regular database
synchronization will be maintained to keep the MGROUP-database
synchronized.
Similarly, on LAN links the DIS is responsible for sending periodic
CSNP transmissions. The DIS in the L2 IS-IS network domain will also
be responsible for sending periodic MGROUP-CSNP transmissions. The
update and flooding process will work in parallel for the two
databases and there is no further synchronization between them.
In general, the database synchronization is performed in parallel
with no interactions between the messages. However, the initial
triggers that start a CSNP exchange are correlated, in the sense it
also triggers a MGROUP-CSNP exchange. For example, during graceful
restart [RFC 3847], a parallel MGROUP-CSNP and MGROUP-PSNP exchange
and update process will be run for the MGROUP-PDUs and restart
process completes after both databases have been received.
4. Considerations for Using L2 Information in IS-IS
While this document does not specify the way in which addresses
Ward, et al. Expires May 3, 2009 [Page 10]
Internet-Draft Carrying Attached Addresses in IS-IS October 2008
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.
4.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.
4.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.
5. Acknowledgements
The authors would like to thank Les Ginsberg for his useful comments.
6. Security Considerations
This document adds no additional security risks to IS-IS, nor does it
provide any additional security for IS-IS.
7. 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: 29
This document requires the definition a set of new ISIS TLVs, the
MAC-Reachability TLV (type 141), and the Group Address TLV (type 142)
Ward, et al. Expires May 3, 2009 [Page 11]
Internet-Draft Carrying Attached Addresses in IS-IS October 2008
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 (141) - X - - -
GADDR-TLV (142) - - - 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.
8. References
8.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 3847]
Shand, M. and L. Ginsberg, "Restart Signaling for
Intermediate System to Intermediate System (IS-IS)", 2004.
[RFC 4971]
Vasseur, JP. and N. Shen, "Intermediate System to
Intermediate System (IS-IS) Extensions for Advertising
Router Information", 2007.
8.2. Informative References
[RBRIDGES]
Perlman, R. and J. Touch, "Transparent Interconnection of
Lots of Links (TRILL): Problem and Applicability
Ward, et al. Expires May 3, 2009 [Page 12]
Internet-Draft Carrying Attached Addresses in IS-IS October 2008
Statement", 2008.
Authors' Addresses
David Ward
Cisco Systems
Email: wardd@cisco.com
Russ White
Cisco Systems
Email: riw@cisco.com
Dino Farinacci
Cisco Systems
Email: dino@cisco.com
Ayan Banerjee
Cisco Systems
Email: ayabaner@cisco.com
Radia Perlman
Sun Microsystems
Email: Radia.Perlman@Sun.com
Ward, et al. Expires May 3, 2009 [Page 13]
Internet-Draft Carrying Attached Addresses in IS-IS October 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 May 3, 2009 [Page 14]