draft-ietf-isis-layer2-03.txt   draft-ietf-isis-layer2-04.txt 
Network Working Group A. Banerjee, Ed. Network Working Group A. Banerjee, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track March 8, 2010 Intended status: Standards Track D. Ward
Expires: September 9, 2010 Expires: October 18, 2010 Juniper Networks
R. White
D. Farinacci
Cisco Systems
R. Perlman
Intel Labs
D. Eastlake
Stellar Switches
P. Ashwood-Smith
Huawei
D. Fedyk
Alcatel-Lucent
April 16, 2010
Extensions to IS-IS for Layer-2 Systems Extensions to IS-IS for Layer-2 Systems
draft-ietf-isis-layer2-03 draft-ietf-isis-layer2-04
Abstract Abstract
This document specifies the IS-IS extensions necessary to support This document specifies the IS-IS extensions necessary to support
multi-link IPv4 and IPv6 networks, as well as to provide true link multi-link IPv4 and IPv6 networks, as well as to provide true link
state routing to any protocols running directly over layer 2. While state routing to any protocols running directly over layer 2. While
supporting this concept involves several pieces, this document only supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in these IS-IS extensions to explain how the information carried in
IS-IS is used. IS-IS is used.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on October 18, 2010.
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 September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. PDU, TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . 4 2. PDU, TLV and sub-TLV Enhancements to IS-IS . . . . . . . . . . 5
2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 4 2.1. The MAC-Reachability TLV . . . . . . . . . . . . . . . . . 5
2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6 2.2. The Group Address TLV . . . . . . . . . . . . . . . . . . 6
2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6 2.2.1. The Group MAC Address sub-TLV . . . . . . . . . . . . 6
2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8 2.2.2. The Group IP Address sub-TLV . . . . . . . . . . . . . 8
2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10 2.2.3. The Group IPv6 Address sub-TLV . . . . . . . . . . . . 10
2.2.4. The SPBV MAC Address sub-TLV . . . . . . . . . . . . . 11 2.2.4. The SPBV MAC Address sub-TLV . . . . . . . . . . . . . 12
2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 13 2.3. Multi Topology aware Port Capability TLV . . . . . . . . . 14
2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 14 2.3.1. The Special VLANs and Flags sub-TLV . . . . . . . . . 14
2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 15 2.3.2. Enabled VLANs sub-TLV . . . . . . . . . . . . . . . . 16
2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 16 2.3.3. Appointed Forwarders sub-TLV . . . . . . . . . . . . . 17
2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 17 2.3.4. Hop-by-Hop Options (HBHOPT) sub-TLV . . . . . . . . . 18
2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 18 2.3.5. Base VLAN-Identifiers sub-TLV . . . . . . . . . . . . 19
2.3.6. SPB Digest sub-TLV . . . . . . . . . . . . . . . . . . 19 2.3.6. SPB Digest sub-TLV . . . . . . . . . . . . . . . . . . 20
2.3.7. Site Identifier sub-TLV . . . . . . . . . . . . . . . 21 2.3.7. Site Identifier sub-TLV . . . . . . . . . . . . . . . 21
2.3.8. Site Group IPv4 sub-TLV . . . . . . . . . . . . . . . 21 2.3.8. Site Group IPv4 sub-TLV . . . . . . . . . . . . . . . 22
2.3.9. Site Group IPv6 sub-TLV . . . . . . . . . . . . . . . 22 2.3.9. Site Group IPv6 sub-TLV . . . . . . . . . . . . . . . 23
2.3.10. Adjacency Server IPv4 sub-TLV . . . . . . . . . . . . 22 2.3.10. Adjacency Server IPv4 sub-TLV . . . . . . . . . . . . 23
2.3.11. Adjacency Server IPv6 sub-TLV . . . . . . . . . . . . 23 2.3.11. Adjacency Server IPv6 sub-TLV . . . . . . . . . . . . 24
2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 23 2.4. Sub-TLVs for the Router Capability TLV . . . . . . . . . . 25
2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 23 2.4.1. The TRILL Version sub-TLV . . . . . . . . . . . . . . 25
2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 24 2.4.2. The Nickname sub-TLV . . . . . . . . . . . . . . . . . 26
2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 25 2.4.3. The Trees sub-TLV . . . . . . . . . . . . . . . . . . 27
2.4.4. The Tree Identifiers Sub-TLV . . . . . . . . . . . . . 26 2.4.4. The Tree Identifiers Sub-TLV . . . . . . . . . . . . . 28
2.4.5. The Trees Used Identifiers Sub-TLV . . . . . . . . . . 27 2.4.5. The Trees Used Identifiers Sub-TLV . . . . . . . . . . 29
2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 27 2.4.6. Interested VLANs and Spanning Tree Roots sub-TLV . . . 29
2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 29 2.4.7. The VLAN Group sub-TLV . . . . . . . . . . . . . . . . 31
2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV . . . . 30 2.4.8. The Ingress-to-Egress Options (ITEOPT) sub-TLV . . . . 32
2.4.9. VLAN Mapping (VMAP) sub-TLV . . . . . . . . . . . . . 31 2.4.9. VLAN Mapping (VMAP) sub-TLV . . . . . . . . . . . . . 33
2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 32 2.5. Multi Topology Aware Capability TLV . . . . . . . . . . . 34
2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 33 2.5.1. SPB Instance sub-TLV . . . . . . . . . . . . . . . . . 35
2.5.2. SPBM Service Identifier and Unicast Address sub-TLV . 36 2.5.2. SPBM Service Identifier and Unicast Address sub-TLV . 38
2.6. Sub-TLVs of the Extended Reachability TLV . . . . . . . . 37 2.6. Sub-TLVs of the Extended Reachability TLV . . . . . . . . 39
2.6.1. SPB Link Metric sub-TLV . . . . . . . . . . . . . . . 37 2.6.1. SPB Link Metric sub-TLV . . . . . . . . . . . . . . . 39
2.6.2. MTU sub-TLV . . . . . . . . . . . . . . . . . . . . . 38 2.6.2. MTU sub-TLV . . . . . . . . . . . . . . . . . . . . . 40
2.7. TRILL Neighbor TLV . . . . . . . . . . . . . . . . . . . . 39 2.7. TRILL Neighbor TLV . . . . . . . . . . . . . . . . . . . . 41
2.8. The Group Membership Active Source TLV . . . . . . . . . . 40 2.8. The Group Membership Active Source TLV . . . . . . . . . . 42
2.8.1. The Group MAC Active Source sub-TLV . . . . . . . . . 41 2.8.1. The Group MAC Active Source sub-TLV . . . . . . . . . 43
2.8.2. The Group IP Active Source sub-TLV . . . . . . . . . . 42 2.8.2. The Group IP Active Source sub-TLV . . . . . . . . . . 44
2.8.3. The Group IPv6 Active Source sub-TLV . . . . . . . . . 44 2.8.3. The Group IPv6 Active Source sub-TLV . . . . . . . . . 46
2.9. PDU Extensions to IS-IS . . . . . . . . . . . . . . . . . 46 2.9. PDU Extensions to IS-IS . . . . . . . . . . . . . . . . . 48
2.9.1. The Multicast Group PDU . . . . . . . . . . . . . . . 46 2.9.1. The Multicast Group PDU . . . . . . . . . . . . . . . 48
2.9.2. The TRILL-Hello PDU . . . . . . . . . . . . . . . . . 48 2.9.2. The Multicast Group Partial Sequence Number PDU . . . 49
2.9.3. The MTU PDU . . . . . . . . . . . . . . . . . . . . . 49 2.9.3. The Multicast Group Complete Sequence Number PDU . . . 49
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 2.9.4. MGROUP PDU related changes to Base protocol . . . . . 49
4. Security Considerations . . . . . . . . . . . . . . . . . . . 50 2.9.4.1. Enhancements to the flooding process . . . . . . . 50
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 2.9.4.2. Enhancements to Graceful Restart . . . . . . . . . 50
6. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 53 2.9.4.3. Enhancements to the maximum sequence number
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 reached . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 54 2.9.4.4. Enhancements to the SPF . . . . . . . . . . . . . 51
7.2. Informative References . . . . . . . . . . . . . . . . . . 55 2.9.5. The TRILL-Hello PDU . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.9.6. The MTU PDU . . . . . . . . . . . . . . . . . . . . . 51
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
4. Security Considerations . . . . . . . . . . . . . . . . . . . 54
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1. Normative References . . . . . . . . . . . . . . . . . . . 58
6.2. Informative References . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
1. Overview 1. Overview
There are a number of systems (for example, [RBRIDGES], [802.1aq]) There are a number of systems (for example, [RBRIDGES], [802.1aq],
that use layer 2 addresses carried in a link state routing protocol, [OTV]) that use layer 2 addresses carried in a link state routing
specifically IS-IS [IS-IS] [RFC1195], to provide true layer 2 protocol, specifically IS-IS [IS-IS] [RFC1195], to provide true layer
routing. This document specifies a set of TLVs and sub-TLVs to be 2 routing. This document specifies a set of TLVs and sub-TLVs to be
added to [IS-IS] level 1 PDUs, and six new PDU types, to support added to [IS-IS] level 1 PDUs, and six new PDU types, to support
these proposed systems. Some of these TLVs are generic layer 2 these proposed systems. Some of these TLVs are generic layer 2
additions and some are specific to [RBRIDGES] or to [802.1aq]. This additions and some are specific to [RBRIDGES] or [802.1aq] or [OTV].
draft does not propose any new forwarding mechanisms using this This draft does not propose any new forwarding mechanisms using this
additional information carried within IS-IS. additional information carried within IS-IS.
This document specifies additional TLVs and sub-TLVs, to carry This document specifies additional TLVs and sub-TLVs, to carry
unicast and multicast attached address information. It also unicast and multicast attached address information. It also
specifies additional TLVs and sub-TLVs to carry information as specifies additional TLVs and sub-TLVs to carry information as
required by the IETF TRILL and IEEE 802.1aq protocols. required by the IETF TRILL and IEEE 802.1aq protocols.
This document specifies six new IS-IS PDUs. The Multicast Group This document specifies six new IS-IS PDUs. The Multicast Group
(MGROUP) PDU, for carrying a list of attached or joined multicast (MGROUP) PDU, for carrying a list of attached or joined multicast
groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP) groups. The Multicast Group Complete Sequence Number (MGROUP-CSNP)
skipping to change at page 5, line 28 skipping to change at page 5, line 38
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (N) (6 bytes) | | MAC (N) (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 141 (MAC-RI). o Type: TLV Type, set to 141 (MAC-RI).
o Length: Total number of bytes contained in the value field given o Length: Total number of bytes contained in the value field given
by 5 + 6*n bytes. by 5 + 6*n bytes.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
MUST be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname : Depending on the technology in which it is o Topology-Id/Nickname : Depending on the technology in which it is
used, this carries the topology-id or nickname. When this field used, this carries the topology-id or nickname. When this field
is set to zero this implies that the MAC addresses are reachable is set to zero this implies that the MAC addresses are reachable
across all topologies or across all nicknames of the originating across all topologies or across all nicknames of the originating
IS. IS.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
MUST be set to zero on transmission and be ignored on receipt.
o RESV: Must be sent as zero on transmission and is ignored on o RESV: Must be sent as zero on transmission and is ignored on
receipt. receipt.
o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV, or the value zero if no all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified. VLAN is specified.
o MAC(i): This is the 48-bit MAC address reachable from the IS that o MAC(i): This is the 48-bit MAC address reachable from the IS that
is announcing this TLV. is announcing this TLV.
skipping to change at page 7, line 26 skipping to change at page 7, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) | | Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) | | Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 1 (GMAC-ADDR) of length 1 byte. o Type: sub-TLV Type, set to 1 (GMAC-ADDR) of length 1 byte.
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
MUST be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname : Depending on the technology in which it is o Topology-Id/Nickname : Depending on the technology in which it is
used, this carries the topology-id or nickname. When this field used, this carries the topology-id or nickname. When this field
is set to zero this implies that the MAC addresses are reachable is set to zero this implies that the MAC addresses are reachable
across all topologies or across all nicknames of the originating across all topologies or across all nicknames of the originating
IS. IS.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
MUST be set to zero on transmission and be ignored on receipt.
o RESERVED: Must be sent as zero on transmission and is ignored on o RESERVED: Must be sent as zero on transmission and is ignored on
receipt. receipt.
o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
all subsequent MAC addresses in this TLV, or the value zero if no all subsequent MAC addresses in this sub-TLV, or the value zero if
VLAN is specified. no VLAN is specified.
o Number of Group Records: This is of length 1 byte and lists the o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV. number of group records in this sub-TLV.
o Group Record: Each group record has a one byte reserved space and o Group Record: Each group record has a one byte reserved space and
the next byte carries the number of sources. It then has a 48-bit the next byte carries the number of sources. It then has a 48-bit
multicast Group Address followed by 48-bit source MAC addresses. multicast Group Address followed by 48-bit source MAC addresses.
An address being a group multicast address or unicast source An address being a group multicast address or unicast source
address can be checked using the multicast bit in the address. If address can be checked using the multicast bit in the address. If
the number of sources do not fit in a single sub-TLV, it is the number of sources do not fit in a single sub-TLV, it is
permitted to have the same group address repeated with different permitted to have the same group address repeated with different
source addresses in another sub-TLV of another instance of the source addresses in another sub-TLV of another instance of the
Group Address TLV. Group Address TLV.
The GMAC-ADDR sub-TLV is carried only within a GADDR TLV and MUST be The GMAC-ADDR sub-TLV is carried only within a GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU. carried in a standard Level 1 link state MGROUP PDU.
skipping to change at page 9, line 22 skipping to change at page 9, line 44
| Source 1 Address (4 bytes) | | Source 1 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (4 bytes) | | Source 2 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (4 bytes) | | Source M Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 2 (GIP-ADDR). o Type: sub-TLV Type, set to 2 (GIP-ADDR).
o Length: Total number of bytes contained in the value field of the o Length: Total number of bytes contained in the value field of the
TLV. sub-TLV.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the IP addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname : Depending on the technology in which it is o Topology-Id/Nickname : Depending on the technology in which it is
used, this carries the topology-id or nickname. When this field used, this carries the topology-id or nickname. When this field
is set to zero this implies that the addresses are reachable is set to zero this implies that the addresses are reachable
across all topologies or across all nicknames of the originating across all topologies or across all nicknames of the originating
IS. IS.
o Confidence: This carries an 8-bit quantity indicating the
confidence level in the IP addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
o RESERVED: Must be sent as zero on transmission and is ignored on o RESERVED: Must be sent as zero on transmission and is ignored on
receipt. receipt.
o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
all subsequent addresses in this TLV, or the value zero if no VLAN all subsequent addresses in this sub-TLV, or the value zero if no
is specified. VLAN is specified.
o Number of Group Records: This is of length 1 byte and lists the o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV. number of group records in this sub-TLV.
o Group Record: Each group record has a one byte reserved space and o Group Record: Each group record has a one byte reserved space and
the next byte carries the number of sources. It is followed by a the next byte carries the number of sources. It is followed by a
32-bit IPv4 Group Address followed by 32-bit source IPv4 32-bit IPv4 Group Address followed by 32-bit source IPv4
addresses. If the number of sources do not fit in a single sub- addresses. If the number of sources do not fit in a single sub-
TLV, it is permitted to have the same group address repeated with TLV, it is permitted to have the same group address repeated with
different source addresses repeated in another sub-TLV of another different source addresses repeated in another sub-TLV of another
instance of the Group Address TLV. instance of the Group Address TLV.
The GIP-ADDR sub-TLV is carried only within a GADDR TLV and MUST be The GIP-ADDR sub-TLV is carried only within a GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU. carried in a standard Level 1 link state MGROUP PDU.
2.2.3. The Group IPv6 Address sub-TLV 2.2.3. The Group IPv6 Address sub-TLV
The Group IPv6 Address (GIPV6-ADDR) TLV is IS-IS sub-TLV type 3 and The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3
has the following format: and has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=GIPv6-ADDR| |Type=GIPv6-ADDR|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology-Id/ Nickname | (2 bytes) | Topology-Id/ Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Confidence | (1 byte) | Confidence | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 21 skipping to change at page 12, line 12
o Topology-Id/Nickname : Depending on the technology in which it is o Topology-Id/Nickname : Depending on the technology in which it is
used, this carries the topology-id or nickname. When this field used, this carries the topology-id or nickname. When this field
is set to zero this implies that the addresses are reachable is set to zero this implies that the addresses are reachable
across all topologies or across all nicknames of the originating across all topologies or across all nicknames of the originating
IS. IS.
o RESERVED: Must be sent as zero on transmission and is ignored on o RESERVED: Must be sent as zero on transmission and is ignored on
receipt. receipt.
o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
all subsequent addresses in this TLV, or the value zero if no VLAN all subsequent addresses in this sub-TLV, or the value zero if no
is specified. VLAN is specified.
o Number of Group Records: This of length 1 byte and lists the o Number of Group Records: This of length 1 byte and lists the
number of group records in this TLV. number of group records in this sub-TLV.
o Group Record: Each group record has a one byte reserved space and o Group Record: Each group record has a one byte reserved space and
the next byte carries the number of sources. It is followed by a the next byte carries the number of sources. It is followed by a
128-bit multicast IPv6 Group Address followed by 128-bit source 128-bit multicast IPv6 Group Address followed by 128-bit source
IPv6 addresses. If the number of sources do not fit in a single IPv6 addresses. If the number of sources do not fit in a single
sub-TLV, it is permitted to have the same group address repeated sub-TLV, it is permitted to have the same group address repeated
with different source addresses repeated in another sub-TLV in with different source addresses repeated in another sub-TLV in
another instance of the Group Address TLV. another instance of the Group Address TLV.
The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV and MUST be The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU. carried in a standard Level 1 link state MGROUP PDU.
2.2.4. The SPBV MAC Address sub-TLV 2.2.4. The SPBV MAC Address sub-TLV
The SPBV MAC Address (SPBV-MAC-ADDR) TLV is IS-IS sub-TLV type 4 and The SPBV MAC Address (SPBV-MAC-ADDR) sub-TLV is IS-IS sub-TLV type 4
has the following format: and has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type=SPBV-ADDR| (1 byte) | Type=SPBV-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|S|R| SPVID | (2 bytes) |R|R|S|R| SPVID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC 1 Address | (1+6 bytes) |T|R| Reserved | MAC 1 Address | (1+6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 30 skipping to change at page 13, line 11
o Length: Total number of bytes contained in the value field. The o Length: Total number of bytes contained in the value field. The
number of MAC address associated with the SPVID is computed by number of MAC address associated with the SPVID is computed by
(Length - 2)/7. (Length - 2)/7.
o SR bits (2-bits) The SR bits are the service requirement parameter o SR bits (2-bits) The SR bits are the service requirement parameter
from MMRP. The service requirement parameters have the value 0 from MMRP. The service requirement parameters have the value 0
(Forward all Groups) and 1 (Forward All Unregistered Groups) (Forward all Groups) and 1 (Forward All Unregistered Groups)
defined. However this attribute may also be missing. So the SR defined. However this attribute may also be missing. So the SR
bits are defined as 0 not declared, 1 Forward all Groups and 2 bits are defined as 0 not declared, 1 Forward all Groups and 2
Forward All Unregistered Groups. These bits have a two Reserved Forward All Unregistered Groups. These bits have two Reserved
bits set before them. bits set before them.
o SPVID (12-bits) The SPVID and by association Base VID and the ECT- o SPVID (12-bits) The SPVID and by association Base VID and the ECT-
ALGORITHM and SPT Set that the MAC addresses defined below will ALGORITHM and SPT Set that the MAC addresses defined below will
use. If the SPVID is not allocated the SPVID Value is 0. Note use. If the SPVID is not allocated the SPVID Value is 0. Note
that if the ECT-Algorithm in use is Spanning Tree Algorithm this that if the ECT-Algorithm in use is Spanning Tree Algorithm this
value should be populated with the Base VID and the MAC can be value should be populated with the Base VID and the MAC can be
populated. populated.
o T Bit (1-bit) This is the Transmit allowed Bit for the following o T Bit (1-bit) This is the Transmit allowed Bit for the following
skipping to change at page 13, line 17 skipping to change at page 13, line 45
Addresses as receiver should be populated (for bridges advertising Addresses as receiver should be populated (for bridges advertising
this Group MAC Address with the T bit set) and installed when the this Group MAC Address with the T bit set) and installed when the
bridge computing the trees lies on the corresponding shortest path bridge computing the trees lies on the corresponding shortest path
for this ECT-ALGORITHM between this receiver and any transmitter for this ECT-ALGORITHM between this receiver and any transmitter
on this Group MAC Address. An entry that does not have this bit on this Group MAC Address. An entry that does not have this bit
set for a Group MAC Address is prevented from receiving on this set for a Group MAC Address is prevented from receiving on this
Group MAC Address because transit bridges will not install Group MAC Address because transit bridges will not install
multicast forwarding state towards it in their FDBs or the traffic multicast forwarding state towards it in their FDBs or the traffic
is explicitly filtered. is explicitly filtered.
o MAC Address (48-bits) The MAC is the address is either a group o MAC Address (48-bits) The MAC is address is either a group address
address or an individual address. Individual addresses are or an individual address. Individual addresses are optional and
optional and normal MAC learning can be used. When the MAC normal MAC learning can be used. When the MAC address is a group
address is a group address it declares this bridge as part of the address it declares this bridge as part of the multicast interest
multicast interest for this destination MAC address. Multicast for this destination MAC address. Multicast trees can be
trees can be efficiently constructed for destination by populating efficiently constructed for destination by populating multicast
multicast FDB entries for the subset of the shortest path tree FDB entries for the subset of the shortest path tree that connects
that connects the bridges supporting the multicast address. This the bridges supporting the multicast address. This replaces the
replaces the function of MMRP for SPTs. The T and R bits above function of MMRP for SPTs. The T and R bits above have meaning if
have meaning if this is a group address. Individual addresses are this is a group address. Individual addresses are populated only
populated only as if the R bit was not set. as if the R bit was not set.
The SPBV-MAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be The SPBV-MAC-ADDR sub-TLV is carried within the GADDR TLV and MUST be
carried only in a standard Level 1 link state MGROUP PDU. carried only in a standard Level 1 link state MGROUP PDU.
2.3. Multi Topology aware Port Capability TLV 2.3. Multi Topology aware Port Capability TLV
The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS The Multi Topology aware Port Capability (MT-PORT-CAP) is an IS-IS
TLV type 143 [TBD], and has the following format: TLV type 143 [TBD], and has the following format:
0 1 2 3 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 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
skipping to change at page 14, line 21 skipping to change at page 14, line 48
o sub-TLVs: The MT aware Port Capabilities TLV value contains sub- o sub-TLVs: The MT aware Port Capabilities TLV value contains sub-
TLVs formatted as described in [RFC5305]. They are defined in the TLVs formatted as described in [RFC5305]. They are defined in the
next sections. next sections.
The MT-PORT-CAP TLV may occur multiple times, and is carried only The MT-PORT-CAP TLV may occur multiple times, and is carried only
within a Hello PDU. within a Hello PDU.
2.3.1. The Special VLANs and Flags sub-TLV 2.3.1. The Special VLANs and Flags sub-TLV
The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST only appear The Special VLANs and Flags (VLAN and Flags) sub-TLV MUST only appear
in a MT-PORT-CAP TLV. This is carried exactly once in every TRILL in a MT-PORT-CAP TLV. It is carried exactly once in every TRILL IIH
IIH PDU. It has the following format: PDU. It has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=VLAN Flags| (1 byte) |Type=VLAN Flags| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+--------------------------------+ +--------------------------------+
| Port ID | (2 bytes) | Port ID | (2 bytes)
+--------------------------------+ +--------------------------------+
| Sender Nickname | (2 bytes) | Sender Nickname | (2 bytes)
+--+--+--+--+--------------------+ +--+--+--+--+--------------------+
|AF|AC|VM|BY| Outer.VLAN | (2 bytes) |AF|AC|VM|BY| Outer.VLAN | (2 bytes)
+-----------+--------------------+ +-----------+--------------------+
|Reserved | Desig.VLAN | (2 bytes) |Reserved | Desig.VLAN | (2 bytes)
+-----------+--------------------+ +-----------+--------------------+
o Type: TLV Type, set to VLAN and Flags sub-TLV 1 [TBD]. o Type: sub-TLV Type, set to VLAN and Flags sub-TLV 1 [TBD].
o Length: 8 - Number of bytes contained in the value field. o Length: 8 - Number of bytes contained in the value field.
o Port ID: An ID for the port on which the enclosing TRILL IIH PDU o Port ID: An ID for the port on which the enclosing TRILL IIH PDU
is being sent. The transmitting RBridge assigns this ID such that is being sent. The transmitting RBridge assigns this ID such that
each of its ports has an ID different from all of its other ports. each of its ports has an ID different from all of its other ports.
o Sender nickname: If the sending intermediate system is holding any o Sender nickname: If the sending intermediate system is holding any
nicknames, one MUST be included here. Otherwise, the field is set nicknames, one MUST be included here. Otherwise, the field is set
to zero. This field is to support intelligent end stations that to zero. This field is to support intelligent end stations that
skipping to change at page 15, line 32 skipping to change at page 16, line 13
bits. The upper 4 bits of the seventh byte are reserved and MUST bits. The upper 4 bits of the seventh byte are reserved and MUST
be sent as zero and ignored on receipt. be sent as zero and ignored on receipt.
The VLAN and Flags sub-TLV is carried within the MT-PORT-CAP TLV. It The VLAN and Flags sub-TLV is carried within the MT-PORT-CAP TLV. It
MUST be carried exactly once in a TRILL IIH PDU. It MUST NOT be MUST be carried exactly once in a TRILL IIH PDU. It MUST NOT be
carried within a LAN or a P2P IIH PDU. carried within a LAN or a P2P IIH PDU.
2.3.2. Enabled VLANs sub-TLV 2.3.2. Enabled VLANs sub-TLV
The Enabled VLAN sub-TLV specifies the VLANs enabled for end station The Enabled VLAN sub-TLV specifies the VLANs enabled for end station
service at the port on which the Hello was sent. service at the port on which the Hello was sent. It has the
following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=EnabledVLAN| |Type=EnabledVLAN|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv | Start Vlan Id | (2 bytes) |Resv | Start Vlan Id | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vlan bit-map.... | Vlan bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 17 skipping to change at page 16, line 47
third byte indicates the VLAN equal to the starting ID while the third byte indicates the VLAN equal to the starting ID while the
lowest order bit of the third byte indicates that ID plus 7. For lowest order bit of the third byte indicates that ID plus 7. For
example, VLANs 1 and 14 being enabled for end station service example, VLANs 1 and 14 being enabled for end station service
could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or, could be encoded in 4-bytes value 0x00 0x01 0x80 0x04 or,
alternatively, as 0x00 0x00 0x40 0x02. alternatively, as 0x00 0x00 0x40 0x02.
This sub-TLV may occur more than once in a Hello and a VLAN is This sub-TLV may occur more than once in a Hello and a VLAN is
enabled for end station service on the port where the Hello was sent enabled for end station service on the port where the Hello was sent
if this is indicated by any occurrence in the Hello. For example, a if this is indicated by any occurrence in the Hello. For example, a
receiver could allocate a 512-byte buffer and, with appropriate receiver could allocate a 512-byte buffer and, with appropriate
shifting operations, OR in the enabled bits for each subTLV of this shifting operations, OR in the enabled bits for each sub-TLV of this
type it finds in a Hello to derive the complete bit map of these type it finds in a Hello to derive the complete bit map of these
VLANs. VLANs.
The Enabled VLAN sub-TLV is carried only within the MT-PORT-CAP TLV. The Enabled VLAN sub-TLV is carried only within the MT-PORT-CAP TLV.
If present, it MUST be carried in TRILL IIH PDU. It MUST NOT be If present, it MUST be carried in TRILL IIH PDU. It MUST NOT be
carried within a LAN IIH or a P2P IIH PDU. carried within a LAN IIH or a P2P IIH PDU.
2.3.3. Appointed Forwarders sub-TLV 2.3.3. Appointed Forwarders sub-TLV
The Appointed Forwarder sub-TLV provides the mechanism by which the The Appointed Forwarder sub-TLV provides the mechanism by which the
Designated Intermediate System can inform other Intermediate Systems Designated Intermediate System can inform other Intermediate Systems
on the link that they are the designated VLAN-x forwarder for that on the link that they are the designated VLAN-x forwarder for that
link for one or more ranges of VLAN IDs. link for one or more ranges of VLAN IDs. It has the following
format:
o Type: sub-TLV Type, set to Appointed Forwarders sub-TLV 3 [TBD].
o Length: The size of the value is 6*n bytes where there are n
appointments. Each 6-byte part of the value is formatted as
follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=App Frwrdr| |Type=App Frwrdr|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes) | Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes) | Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o where each appointment information is of the form: where each appointment information is of the form:
+---------------------------+ +---------------------------+
| Appointee Nick | (2 bytes) | Appointee Nick | (2 bytes)
+---------------------------+ +---------------------------+
| Res | Start VLAN ID | (2 bytes) | Res | Start VLAN ID | (2 bytes)
+---------------------------+ +---------------------------+
| Res | End VLAN ID | (2 bytes) | Res | End VLAN ID | (2 bytes)
+---------------------------+ +---------------------------+
o Type: sub-TLV Type, set to Appointed Forwarders sub-TLV 3 [TBD].
o Length: The size of the value is 6*n bytes where there are n
appointments.
o The appointed forwarder Intermediate System is specified by its o The appointed forwarder Intermediate System is specified by its
nickname in the first two bytes. nickname in the first two bytes.
o The "Res" fields of 4 bits each are reserved and MUST be sent as o The "Res" fields of 4 bits each are reserved and MUST be sent as
zero and ignored on receipt. zero and ignored on receipt.
The VLAN range given is inclusive. To specify a single VLAN, that The VLAN range given is inclusive. To specify a single VLAN, that
VLAN ID appears as both the start and end VLAN. The Intermediate VLAN ID appears as both the start and end VLAN. The Intermediate
System whose nickname is given is appointed forwarder for those VLANs System whose nickname is given is appointed forwarder for those VLANs
for which it has end station service enabled (see item 2 above) in for which it has end station service enabled (see item 2 above) in
skipping to change at page 18, line 15 skipping to change at page 18, line 45
The bit-encoded options supported are indicated by an HBHOPT sub-TLV The bit-encoded options supported are indicated by an HBHOPT sub-TLV
of length 3: an initial value byte of 0x00 followed by two bytes in of length 3: an initial value byte of 0x00 followed by two bytes in
which each bit indicates that the corresponding bit option is which each bit indicates that the corresponding bit option is
implemented; in those two bytes the top two bits (0xC000) are implemented; in those two bytes the top two bits (0xC000) are
critical option summary bits that all RBridges MUST understand; critical option summary bits that all RBridges MUST understand;
therefore support for these bits need not be advertised. Those two therefore support for these bits need not be advertised. Those two
bits are reserved in the HBHOPT sub-TLV and must be sent as zero and bits are reserved in the HBHOPT sub-TLV and must be sent as zero and
are ignored on receipt. are ignored on receipt.
The implementation of a TLV encoded option is indicated by an HBHOPT The implementation of the type of option encoded in a TRILL Header as
sub-TLV whose value starts with a byte equal to the first byte of the a TLV is indicated by an HBHOPT sub-TLV whose value starts with a
option. Such HBHOPT sub-TLVs may have additional value bytes further byte equal to the first byte of the option. Such HBHOPT sub-TLVs may
indicating how the option is supported as specified with the option's have additional value bytes further indicating how the option is
definition, for example a list of supported security algorithms. supported as specified with the option's definition, for example a
list of supported security algorithms.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = HBHOPT | | Type = HBHOPT |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Option | (1 byte) | Option | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option dependent variable length information | | Option dependent variable length information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Hop-by-Hop sub-TLV 4 [TBD]. o Type: sub-TLV Type, set to Hop-by-Hop sub-TLV 4 [TBD].
o Length: variable, minimum 1. o Length: variable, minimum 1.
o Value: The first byte of the TLV encoded option which must be non- o Value: Either 0x00 followed by implementation information for bit
zero, followed by option dependent information. encoded options or a non-zero option type byte followed by option
dependent information for that option.
2.3.5. Base VLAN-Identifiers sub-TLV 2.3.5. Base VLAN-Identifiers sub-TLV
This sub-TLV is added to an IIH PDU to indicate the algorithms for This sub-TLV is added to an IIH PDU to indicate the algorithms for
the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) that the VIDs and the Base VIDs and VIDs or Backbone-VIDs (B-VIDs) that
are in use. This information should be the same on all bridges in are in use. This information should be the same on all bridges in
the topology identified by MT-PORT-CAP TLV it is being carried. the topology identified by MT-PORT-CAP TLV it is being carried.
Discrepancies between neighbours with respect to this sub-TLV are Discrepancies between neighbours with respect to this sub-TLV are
temporarily allowed but the Base-VID must agree and use a spanning temporarily allowed but the Base-VID must agree and use a spanning
tree algorithm. tree algorithm.
skipping to change at page 19, line 50 skipping to change at page 20, line 33
The Base VLAN-Identifier sub-TLV is carried within the MT-PORT-CAP The Base VLAN-Identifier sub-TLV is carried within the MT-PORT-CAP
TLV and this is carried in a IIH PDU. TLV and this is carried in a IIH PDU.
2.3.6. SPB Digest sub-TLV 2.3.6. SPB Digest sub-TLV
This sub-TLV is added to an IIH PDU to indicate the digest for This sub-TLV is added to an IIH PDU to indicate the digest for
Multiple spanning tree configuration Digests (MCID) and the IS-IS Multiple spanning tree configuration Digests (MCID) and the IS-IS
agreement Digest. This information should be the same on all bridges agreement Digest. This information should be the same on all bridges
in the topology identified by MT-PORT-CAP TLV it is being carried. in the topology identified by MT-PORT-CAP TLV it is being carried.
These digest indicate when the configuration and the topology are These digests indicate when the configuration and the topology are
synchronized and are used to control the updating of forwarding synchronized and are used to control the updating of forwarding
information. The MCID is controlled solely by configuration and is a information. The MCID is controlled solely by configuration and is a
digest of the allocated VIDs to various protocols. Two MCIDs are digest of the allocated VIDs to various protocols. Two MCIDs are
carried to allow transitions when the configuration changes are non- carried to allow transitions when the configuration changes are non-
critical. During the propagation of LSPs the agreement digest will critical. During the propagation of LSPs the agreement digest will
vary between neighbors until the LSPs are common. During that period vary between neighbors until the LSPs are common. During that period
switches or bridges running SPB will not allow multicast forwarding switches or bridges running SPB will not allow multicast forwarding
between neighbors that have differing digests. Discrepancies between between neighbors that have differing digests. Discrepancies between
neighbours with respect to this sub-TLV are temporarily allowed but neighbors with respect to this sub-TLV are temporarily allowed but
the Base-VID must agree and use a spanning tree algorithm. the Base-VID must agree and use a spanning tree algorithm.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type =SPBDigest| |Type =SPBDigest|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCID (50 Bytes) | | MCID (50 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aux MCID (50 Bytes) | | Aux MCID (50 Bytes) |
skipping to change at page 21, line 9 skipping to change at page 21, line 49
this node changes this number is updated. Once an Agreement has this node changes this number is updated. Once an Agreement has
been sent it is considered outstanding until a matching or more been sent it is considered outstanding until a matching or more
recent Discarded Agreement Number is received. recent Discarded Agreement Number is received.
The SPB Digest sub-TLV is carried within the MT-PORT-CAP TLV and this The SPB Digest sub-TLV is carried within the MT-PORT-CAP TLV and this
is carried in a IIH PDU. is carried in a IIH PDU.
2.3.7. Site Identifier sub-TLV 2.3.7. Site Identifier sub-TLV
The site identifier sub-TLV carries information about the site this The site identifier sub-TLV carries information about the site this
device belongs to. device belongs to. This is used in OTV [OTV] to aid in Authoritative
Edge Device election. It has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = SiteCap | |Type = SiteCap |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System ID (6 bytes) | | System ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cluster ID (2 bytes) | | Cluster ID (2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags (1 byte)| |Resv (7bits) |U| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Site Identifier sub-TLV 250 [TBD]. o Type: sub-TLV Type, set to Site Identifier sub-TLV 250 [TBD].
o Length: The size of the value. o Length: The size of the value.
o System Id: The system-id of the site. o System Id: The system-id of the site.
o Cluster Id: The cluster-id within the site. o Cluster Id: The cluster-id within the site.
o Flags: Indicates unicast reachability. o Reserved: Must be sent as zero on transmission and is ignored on
receipt.
The Site Capability sub-TLV is carried within the MT-PORT-CAP TLV and o U bit: Denotes if the site is a unicast only site.
this is carried in a Hello PDU.
The Site Capability sub-TLV is carried only within the MT-PORT-CAP
TLV and this is carried in a Hello PDU. There must be only one
occurrence of this sub-TLV in the Hello PDU.
2.3.8. Site Group IPv4 sub-TLV 2.3.8. Site Group IPv4 sub-TLV
The Site Group IPv4 sub-TLV carries information about the overlays
active on this device. This is used in OTV [OTV] to aid in
Authoritative Edge Device election. It has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=SiteGrpIP | |Type=SiteGrpIP |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) | | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .................. | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) | | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Site Group IP sub-TLV 251 [TBD]. o Type: sub-TLV Type, set to Site Group IP sub-TLV 251 [TBD].
o Length: The size of the value. o Length: The size of the value.
o Value: The list of IPv4 addresses used by the site. o Value: The list of IPv4 addresses used by the site.
The Site Group IP sub-TLV is carried within the MT-PORT-CAP TLV and The Site Group IPv4 sub-TLV is carried within the MT-PORT-CAP TLV and
this is carried in a Hello PDU. this is carried in a Hello PDU. There may be more than one
occurrence of this sub-TLV in the Hello PDU.
2.3.9. Site Group IPv6 sub-TLV 2.3.9. Site Group IPv6 sub-TLV
The Site Group IPv6 sub-TLV carries information about the overlays
active on this device. This is used in OTV [OTV] to aid in
Authoritative Edge Device election. It has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=SiteGrpIPv6| |Type=SiteGrpIPv6|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) | | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .................. | | .................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) | | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Site Group IPv6 sub-TLV 252 [TBD]. o Type: sub-TLV Type, set to Site Group IPv6 sub-TLV 252 [TBD].
o Length: The size of the value. o Length: The size of the value.
o Value: The list of IPv6 addresses used by the site. o Value: The list of IPv6 addresses used by the site.
The Site Group IPv6 sub-TLV is carried within the MT-PORT-CAP TLV and The Site Group IPv6 sub-TLV is carried within the MT-PORT-CAP TLV and
this is carried in a Hello PDU. this is carried in a Hello PDU. There may be more than one
occurrence of this sub-TLV in the Hello PDU.
2.3.10. Adjacency Server IPv4 sub-TLV 2.3.10. Adjacency Server IPv4 sub-TLV
+-+-+-+-+-+-+-+-+ The Adjacency Server IPv4 sub-TLV carries information about the
|Type = ASIPv4 | capability of the sites in OTV [OTV]. It has the following format:
+-+-+-+-+-+-+-+-+
| Length | (1 byte) +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = ASIPv4 |
| IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (1 byte)
| Flags(1 byte)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | Adjacency IPv4 Information (1) | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacency IPv4 Information (N) | (5 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each adjacency IPv4 information is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv (7bits) |U| (1 byte)
+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Adjacency Server IP sub-TLV 253 [TBD]. o Type: sub-TLV Type, set to Adjacency Server IP sub-TLV 253 [TBD].
o Length: The size of the value. o Length: The size of the value, 5*n, where there are n adjacency
server information blocks.
o Value: The list of IPv4 addresses used by the site. o IPv4 Address: The IPv4 addresses used by the sites.
o Flags: Indicates unicast reachability. o Reserved: Must be sent as zero on transmission and is ignored on
receipt.
The Adjacency Server IP sub-TLV is carried within the MT-PORT-CAP TLV o U bit: Denotes if the site is a unicast only site.
and this is carried in a Hello PDU.
The Adjacency Server IPv4 sub-TLV is carried within the MT-PORT-CAP
TLV and this is carried in a Hello PDU.
2.3.11. Adjacency Server IPv6 sub-TLV 2.3.11. Adjacency Server IPv6 sub-TLV
+-+-+-+-+-+-+-+-+ The Adjacency Server IPv6 sub-TLV carries information about the
|Type = ASIPv6 | capability of the sites in OTV [OTV]. It has the following format:
+-+-+-+-+-+-+-+-+
| Length | (1 byte) +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type = ASIPv6 |
| IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | (1 byte)
| Flags(1 byte)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | Adjacency IPv6 Information (1) | (17 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adjacency IPv6 Information (N) | (17 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each adjacency IPv6 information is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Resv (7bits) |U| (1 byte)
+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Adjacency Server IPv6 sub-TLV 254 o Type: sub-TLV Type, set to Adjacency Server IPv6 sub-TLV 254
[TBD]. [TBD].
o Length: The size of the value. o Length: The size of the value.
o Value: The list of IPv6 addresses used by the site. o Value: The IPv6 addresses used by the sites.
o Flags: Indicates unicast reachability. o Reserved: Must be sent as zero on transmission and is ignored on
receipt.
o U bit: Denotes if the site is a unicast only site.
The Adjacency Server IPv6 sub-TLV is carried within the MT-PORT-CAP The Adjacency Server IPv6 sub-TLV is carried within the MT-PORT-CAP
TLV and this is carried in a Hello PDU. TLV and this is carried in a Hello PDU. Multiple such TLVs may be
carried in a IIH PDU.
2.4. Sub-TLVs for the Router Capability TLV 2.4. Sub-TLVs for the Router Capability TLV
The Router Capability TLV is an optional TLV [RFC 4971] that may be The Router Capability TLV is an optional TLV [RFC 4971] that may be
generated by the originating Intermediate System. We specify these generated by the originating Intermediate System. We specify these
additional sub-TLVs that can be carried in it. These sub-TLVs additional sub-TLVs that can be carried in it. These sub-TLVs
announce the capabilities of the Intermediate System to the entire announce the capabilities of the Intermediate System to the entire
IS-IS routing domain. IS-IS routing domain.
2.4.1. The TRILL Version sub-TLV 2.4.1. The TRILL Version sub-TLV
skipping to change at page 25, line 12 skipping to change at page 27, line 12
| Nickname | (2 bytes) | Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 6 (NICKNAME). o Type: sub-TLV Type, set to 6 (NICKNAME).
o Length: 5*N, where N is the number of nickname records present. o Length: 5*N, where N is the number of nickname records present.
o Nickname Priority: This is an unsigned 8-bit integer that gives o Nickname Priority: This is an unsigned 8-bit integer that gives
the priority with which this node holds this nickname. the priority with which this node holds this nickname.
o Tree Root Priority: This is an unsigned 16-bit integer that gives o Tree Root Priority: This is an unsigned 16-bit integer that gives
the value of the priority with which this nickname wants to be the the priority of this nickname to become a distribution tree root.
highest priority root node in the Layer-2 domain.
o Nickname: This is an unsigned 16-bit integer that gives device o Nickname: This is an unsigned 16-bit integer that gives device
identifier or alias. identifier or alias.
Each nickname record consists of a one-byte priority set to Each nickname record consists of a one-byte priority set to
application dependent values, two bytes of tree root priority and two application dependent values, two bytes of tree root priority and two
bytes of device identifier or alias (i.e., actual nickname). bytes of device identifier or alias (i.e., actual nickname).
2.4.3. The Trees sub-TLV 2.4.3. The Trees sub-TLV
skipping to change at page 26, line 19 skipping to change at page 28, line 18
that gives the requested number of distribution trees for multi- that gives the requested number of distribution trees for multi-
destination frames that will be in use in the Layer-2 domain, if destination frames that will be in use in the Layer-2 domain, if
this device becomes the highest priority tree root in the domain. this device becomes the highest priority tree root in the domain.
o Maximum number of trees able to compute: This is an unsigned 16- o Maximum number of trees able to compute: This is an unsigned 16-
bit integer that give the maximum number of threes that the bit integer that give the maximum number of threes that the
originating IS is able to compute for the campus. originating IS is able to compute for the campus.
o Number of trees to use: This is an unsigned 16-bit integer that o Number of trees to use: This is an unsigned 16-bit integer that
gives the number of distribution trees the originating IS wishes gives the number of distribution trees the originating IS wishes
to be able to use. to use.
2.4.4. The Tree Identifiers Sub-TLV 2.4.4. The Tree Identifiers Sub-TLV
The tree identifiers sub-TLV is an ordered list of nicknames. When The tree identifiers sub-TLV is an ordered list of nicknames. When
originated by the Intermediate System which is the highest priority originated by the Intermediate System which is the highest priority
tree root, this list is the trees which the other Intermediate tree root, this list is the trees which the other Intermediate
Systems are required to compute. If this information is spread Systems are required to compute. If this information is spread
across multiple sub-TLVs, the starting tree number is used to figure across multiple sub-TLVs, the starting tree number is used to to
out the ordered list. It is carried within the Router CAPABILITY TLV allow the ordered lists to be correctly concatenated. It is carried
in a level-1 non-pseudo-node LSP and is given as: within the Router CAPABILITY TLV in a level-1 non-pseudo-node LSP and
is given as:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=TREE-RT-ID| |Type=TREE-RT-ID|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes) |Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes) | Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 51 skipping to change at page 28, line 51
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) | | Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 8 (TREE-RT-IDs). o Type: sub-TLV Type, set to 8 (TREE-RT-IDs).
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Starting Tree Number: This identifies the starting tree number of o Starting Tree Number: This identifies the starting tree number of
the nicknames that are trees for the domain. This is set to 1 for the nicknames that are trees for the domain. This is set to 1 for
the first sub-TLV. The starting value and the length field gives the first sub-TLV. Subsequent sub-TLVs will have the starting
the number of nicknames being carried in the sub-TLV. In the number of the ordered list. In the event a tree identifier can be
event a tree identifier can be computed from two such sub-TLVs and computed from two such sub-TLVs and are different, then it is
are different, then it is assumed that this is a transient assumed that this is a transient condition that will get cleared.
condition that will get cleared. During this transient time, such trees cannot be computed.
o Nickname: The nickname on which this tree is based. o Nickname: The nickname on which this tree is based.
2.4.5. The Trees Used Identifiers Sub-TLV 2.4.5. The Trees Used Identifiers Sub-TLV
This sub-TLV has the same structure as the Tree Identifiers sub-TLV This sub-TLV has the same structure as the Tree Identifiers sub-TLV
specified in the above section. The only difference is that its sub- specified in the above section. The only difference is that its sub-
TLV type is set to 9 TBD (TREE-USE-IDs) and the trees listed are only TLV type is set to 9 TBD (TREE-USE-IDs) and the trees listed are only
those that the originating intermediate systems wishes to use. those that the originating intermediate systems wishes to use.
skipping to change at page 27, line 47 skipping to change at page 29, line 46
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interested VLANS | (8 bytes) | Interested VLANS | (8 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Bridges | (6*n bytes) | Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 10 (INT-VLAN). o Type: sub-TLV Type, set to 10 (INT-VLAN).
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Nickname: If this is set to 0, then it applies to all device-ids o Nickname: If this is set to 0, then it applies to all nicknames
generated by the node. It may alternatively be set to a specific generated by the node. It may alternatively be set to a specific
nickname, in the event a node wants to segregate traffic using nickname, in the event a node wants to segregate traffic using
multiple device-ids. multiple nicknames.
o Interested VLANS: In the Interested VLANs, as shown below, the M4 o Interested VLANS: In the Interested VLANs, as shown below, the M4
bit indicates that there is an IPv4 multicast router on a link for bit indicates that there is an IPv4 multicast router on a link for
which the originating Intermediate System is appointed forwarder which the originating Intermediate System is appointed forwarder
for every VLAN in the indicated range. The M6 bit indicates the for every VLAN in the indicated range. The M6 bit indicates the
same for an IPv6 multicast router. The R and Reserved bits MUST same for an IPv6 multicast router. The R and Reserved bits MUST
be sent as zero and are ignored on receipt. The VLAN start and 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 end IDs are inclusive. A range of one VLAN ID is indicated by
setting them both to that VLAN ID value. The Appointed Forwarder setting them both to that VLAN ID value. The Appointed Forwarder
Status Lost Counter is also included here. It is a count of how Status Lost Counter is also included here. It is a count of how
skipping to change at page 28, line 48 skipping to change at page 30, line 48
listed set of spanning tree root IDs will be null. listed set of spanning tree root IDs will be null.
If there are any two VLANs in the range indicated for which the value If there are any two VLANs in the range indicated for which the value
of the M4, or M6 bits or the Appointed Forwarder Status Lost Counter of the M4, or M6 bits or the Appointed Forwarder Status Lost Counter
are different, the sub-TLV is incorrect and must be split into are different, the sub-TLV is incorrect and must be split into
multiple sub-TLVs each indicating only VLANs with the same M4, M6, multiple sub-TLVs each indicating only VLANs with the same M4, M6,
and Appointed Forwarder Status Lost Counter values. If there are any and Appointed Forwarder Status Lost Counter values. If there are any
two VLANs in the range indicated for which the set of root bridge IDs two VLANs in the range indicated for which the set of root bridge IDs
see on all links for which the Intermediate System is appointed see on all links for which the Intermediate System is appointed
forwarder for the VLAN are not the same, the sub-TLV is incorrect and forwarder for the VLAN are not the same, the sub-TLV is incorrect and
must be split into multiple subTLVs each indicating only VLANs with must be split into multiple sub-TLVs each indicating only VLANs with
the same set of DRB seen root bridge IDs. It is always safe to use the same set of DRB seen root bridge IDs. It is always safe to use
sub-TLVs with a "range" of one VLAN ID but this may be too verbose. sub-TLVs with a "range" of one VLAN ID but this may be too verbose.
Wherever possible, an implementation SHOULD advertise the update to a Wherever possible, an implementation SHOULD advertise the update to a
interested vlan and spanning tree roots sub-TLV in the same LSP interested vlan and spanning tree roots sub-TLV in the same LSP
fragment as the advertisement that it replaces. Where this is not fragment as the advertisement that it replaces. Where this is not
possible, the two affected LSP fragments should be flooded as an possible, the two affected LSP fragments should be flooded as an
atomic action. atomic action.
Systems that receive an update to an existing interested vlan and Systems that receive an update to an existing interested vlan and
skipping to change at page 29, line 21 skipping to change at page 31, line 21
associated with the update by employing a holddown time prior to associated with the update by employing a holddown time prior to
processing the update so as to allow for the receipt of multiple LSP processing the update so as to allow for the receipt of multiple LSP
fragments associated with the same update prior to beginning fragments associated with the same update prior to beginning
processing. processing.
Where a receiving system has two copies of a interested vlan and Where a receiving system has two copies of a interested vlan and
spanning tree roots sub-TLV from the same system that have different spanning tree roots sub-TLV from the same system that have different
settings for a given vlan, the procedure used to choose which copy settings for a given vlan, the procedure used to choose which copy
shall be used is undefined (refer to RFC 4971, Section 3). shall be used is undefined (refer to RFC 4971, Section 3).
This sub-TLV is carried within the CAPABILITY TLV in a level-1 non- This sub-TLV is carried within the CAPABILITY TLV in a level-1
pseudo-node LSP. multicast group PDU.
2.4.7. The VLAN Group sub-TLV 2.4.7. The VLAN Group sub-TLV
The VLAN Group sub-TLV consists of two or more 16-bit fields each of The VLAN Group sub-TLV consists of two or more 16-bit fields each of
which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be which has a VLAN ID in the low order 12 bits. The top 4 bits MUST be
sent as zero and ignored on receipt. The first such VLAN ID is the sent as zero and ignored on receipt. The first such VLAN ID is the
primary, or may be zero if there is no primary. It is carried within primary, or may be zero if there is no primary. It is carried within
the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is structured the CAPABILITY TLV in a level-1 non-pseudo-node LSP and is structured
as follows: as follows:
skipping to change at page 30, line 25 skipping to change at page 32, line 25
By including this sub-TLV within one or more Router Capability TLVs By including this sub-TLV within one or more Router Capability TLVs
in its LSPs, an RBridge can advertise the Ingress-to-Egress options in its LSPs, an RBridge can advertise the Ingress-to-Egress options
it supports. This sub-TLV may appear zero or more times within a it supports. This sub-TLV may appear zero or more times within a
Router Capability TLV. By default, in the absence of any ITEOPT sub- Router Capability TLV. By default, in the absence of any ITEOPT sub-
TLVs, no Ingress-to-Egress options are supported. TLVs, no Ingress-to-Egress options are supported.
There are two types of Ingress-to-Egress option encoding within the There are two types of Ingress-to-Egress option encoding within the
TRILL Header: bit options and TLV encoded options. TRILL Header: bit options and TLV encoded options.
The bit-encoded options supported are indicated by an ITEOPT sub-TLV The bit-encoded options supported are indicated by an ITEOPT TLV of
of length 3: an initial value byte of 0x00 followed by two bytes in length 3: an initial value byte of 0x00 followed by two bytes in
which each bit indicates that the corresponding bit Ingress-to-Egress which each bit indicates that the corresponding bit Ingress-to-Egress
option is implemented. option is implemented.
Other Ingress-to-Egress options are TLV encoded within the TRILL Other Ingress-to-Egress options are TLV encoded within the TRILL
Header options area. The implementation of a TLV encoded option is Header options area. The implementation of a TLV encoded option is
indicated by an ITEOPT sub-TLV whose value starts with a byte equal indicated by an ITEOPT sub-TLV whose value starts with a byte equal
to the first byte of the option. Such ITEOPT sub-TLVs may have to the first byte of the option. Such ITEOPT sub-TLVs may have
additional value bytes further indicating how the option is supported additional value bytes further indicating how the option is supported
as specified in the option's definition, for example a list of as specified in the option's definition, for example a list of
supported security algorithms. supported security algorithms.
skipping to change at page 31, line 5 skipping to change at page 33, line 5
| Option | (1 byte) | Option | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option dependent variable length information | | Option dependent variable length information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12 o Type: sub-TLV Type, set to Ingress-to-Egress option sub-TLV 12
[TBD]. [TBD].
o Length: variable, minimum 1. o Length: variable, minimum 1.
o Value: The first byte of the option followed by option dependent o Value: Either 0x00 followed by implementation information for bit
information. encoded options or a non-zero option type byte followed by option
dependent information for that option.
2.4.9. VLAN Mapping (VMAP) sub-TLV 2.4.9. VLAN Mapping (VMAP) sub-TLV
The VLAN Mapping (VMAP) TLV carries information concerning VLAN The VLAN Mapping (VMAP) sub-TLV carries information concerning VLAN
mappings configured at the originating IS. VLAN mapping is used when mappings configured at the originating IS. VLAN mapping is used when
an RBridge campus is divided into regions such that the same VLAN is an RBridge campus is divided into regions such that the same VLAN is
represented by different VLAN IDs in different regions or there is a represented by different VLAN IDs in different regions or there is a
VLAN is one region that has no equivalent in another region. Each VLAN is one region that has no equivalent in another region. Each
port on each of the border RBridges between two or more regions MUST port on each of the border RBridges between two or more regions MUST
be configured at to which region each port connects with. The be configured as to which region each port connects with. The
numbering of regions is an arbitrary choice but all border RBridges numbering of regions is an arbitrary choice but all border RBridges
in the campus MUST agree on the number of each region. in the campus MUST agree on the number of each region.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = VMAP | | Type = VMAP |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+----------...+ +-+-+-+-+-+-+-+-+----------...+
| Mapping 1 | (8 bytes) | Mapping 1 | (8 bytes)
+-+-+-+-+-+-+-+------------... +-+-+-+-+-+-+-+------------...
skipping to change at page 32, line 8 skipping to change at page 34, line 8
* Count: If this four bit unsigned integer is zero or 1, then the * Count: If this four bit unsigned integer is zero or 1, then the
mapping of a single VLAN ID is being specified. If it is any mapping of a single VLAN ID is being specified. If it is any
value from 2 through 15, then a block of that many contiguous value from 2 through 15, then a block of that many contiguous
VLAN IDs starting with the From VLAN ID is mapped to a block of VLAN IDs starting with the From VLAN ID is mapped to a block of
that many contiguous VLAN IDs starting with the To VLAN ID. that many contiguous VLAN IDs starting with the To VLAN ID.
* From VLAN ID: This is the VLAN ID that, when received on a port * From VLAN ID: This is the VLAN ID that, when received on a port
connect to the From Region on a frame being sent to the To connect to the From Region on a frame being sent to the To
Region, is mapped to the To VLAN ID. This must be a real VLAN Region, is mapped to the To VLAN ID. This must be a real VLAN
ID, that is, the values 0x000 and 0xFFF are prohibited. ID, that is, the values 0x000 and 0xFFF are prohibited and
mappings in which they occur are ignored.
* From Region: This is the region number, within the campus, such * From Region: This is the region number, within the campus, such
that frames received on a port connected to that region and that frames received on a port connected to that region and
destined to a port connected to the To Region have their VLAN destined to a port connected to the To Region have their VLAN
ID mapped as specified by the From VLAN ID and To VLAN ID ID mapped as specified by the From VLAN ID and To VLAN ID
fields. fields.
* RESV: MUST be sent as zero and ignored on receipt. * RESV: MUST be sent as zero and ignored on receipt.
* To VLAN ID: This is the VLAN ID to be used on frames sent out a * To VLAN ID: This is the VLAN ID to be used on frames sent out a
port connected to the To Region if they were received on a port port connected to the To Region if they were received on a port
connected to the From Region with the From VLAN ID; except that connected to the From Region with the From VLAN ID; except that
if the To VLAN ID is 0x000 the frame is dropped. The value if the To VLAN ID is 0x000 the frame is dropped. The value
invalid VLAN ID 0xFFF is prohibited in this field. invalid VLAN ID 0xFFF is prohibited in this field and if it
occurs the mapping is ignored.
* To Region: This is the region number, within the campus, such * To Region: This is the region number, within the campus, such
that frames sent on a port connected to this region from a port that frames sent on a port connected to this region from a port
connected to the From Region have their VLAN ID mapped as connected to the From Region have their VLAN ID mapped as
specified by the From VLAN ID and To VLAN ID fields. specified by the From VLAN ID and To VLAN ID fields.
2.5. Multi Topology Aware Capability TLV 2.5. Multi Topology Aware Capability TLV
This section defines a new optional Intermediate System to This section defines a new optional Intermediate System to
Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of Intermediate System (IS-IS) TLV named MT-CAPABILITY, formed of
multiple sub-TLVs, which allows a router to announce its capabilities multiple sub-TLVs, which allows a router to announce its capabilities
for a particular topology within an IS-IS level or the entire routing for a particular topology within an IS-IS level or the entire routing
domain. This is different from Router Capability TLV defined in RFC domain. This is different from Router Capability TLV defined in RFC
4971, in the sense, the capabilities announced here are topology 4971, in the sense that the capabilities announced here are topology
scoped. scoped.
The Multi Topology Aware Capability (MT-CAPABILITY) is an optional The Multi Topology Aware Capability (MT-CAPABILITY) is an optional
IS-IS TLV type 144 [TBD], that may be generated by the originating IS IS-IS TLV type 144 [TBD], that may be generated by the originating IS
and has the following format: and has the following format:
0 1 2 3 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 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=MTCAPABTLV| Length |O|R|R|R| Topology Identifier | |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 49 skipping to change at page 35, line 4
The Multi Topology Aware Capability (MT-CAPABILITY) is an optional The Multi Topology Aware Capability (MT-CAPABILITY) is an optional
IS-IS TLV type 144 [TBD], that may be generated by the originating IS IS-IS TLV type 144 [TBD], that may be generated by the originating IS
and has the following format: and has the following format:
0 1 2 3 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 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=MTCAPABTLV| Length |O|R|R|R| Topology Identifier | |Type=MTCAPABTLV| Length |O|R|R|R| Topology Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs | | sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to MT-CAPABILITY TLV 144 [TBD]. o Type: TLV Type, set to MT-CAPABILITY TLV 144 [TBD].
o Length: Total number of bytes contained in the value field, o Length: Total number of bytes contained in the value field,
including the length of the sub-TLVs carried in this TLV. including the length of the sub-TLVs carried in this TLV.
o O bit: The overload bit that follows the semantics associated with o O bit: The overload bit that follows the semantics associated with
an overloaded intermediate system. an overloaded intermediate system.
o Reserved (3 bits): Must be sent as zero on transmission and is
ignored on receipt.
o Topology Identifier: MT ID is a 12-bit field containing the MT ID o Topology Identifier: MT ID is a 12-bit field containing the MT ID
of the topology being announced. This field when set to zero of the topology being announced. This field when set to zero
implies that it is being used to carry base topology information. implies that it is being used to carry base topology information.
In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB, In TRILL this value is set to ZERO, however, in IEEE SPB and SPBB,
it may be non-zero. it may be non-zero.
o sub-TLVs: The MT aware Capabilities TLV value contains sub-TLVs o sub-TLVs: The MT aware Capabilities TLV value contains sub-TLVs
formatted as described in [RFC5305]. They are defined in the next formatted as described in [RFC5305]. They are defined in the next
sections. sections.
skipping to change at page 36, line 25 skipping to change at page 38, line 25
should match what is generated in the Hellos of the same node. should match what is generated in the Hellos of the same node.
The ECT-ALGORITHM, BASE-VIDs pairs can come in any order however. The ECT-ALGORITHM, BASE-VIDs pairs can come in any order however.
o Base VID (12-bits) The Base-VID that associated the SPT Set via o Base VID (12-bits) The Base-VID that associated the SPT Set via
the ECT-ALGORITHM. the ECT-ALGORITHM.
o SPVID (12-bits) The SPVID is the Shortest Path VID when using SPBV o SPVID (12-bits) The SPVID is the Shortest Path VID when using SPBV
mode. It is not defined for SPBM Mode and should be 0 in SPBM mode. It is not defined for SPBM Mode and should be 0 in SPBM
mode. mode.
o an opaque ECT Data TLV (type TBD) whose first 32 bits are the ECT- o an opaque ECT Data sub-TLV (type TBD) whose first 32 bits are the
ALGORITHM which this data applies to. ECT-ALGORITHM which this data applies to.
2.5.2. SPBM Service Identifier and Unicast Address sub-TLV 2.5.2. SPBM Service Identifier and Unicast Address sub-TLV
The SPBM Service Identifier and Unicast Address sub-TLV is used to The SPBM Service Identifier and Unicast Address sub-TLV is used to
introduce service group membership on the originating node and/or to introduce service group membership on the originating node and/or to
advertise an additional B-MAC unicast address present on, or advertise an additional B-MAC unicast address present on, or
reachable by the node. reachable by the node.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = SPBM-SI | |Type = SPBM-SI |
skipping to change at page 37, line 26 skipping to change at page 39, line 26
o ISID #1 .. #N are 24 bit service group membership identifiers. If o ISID #1 .. #N are 24 bit service group membership identifiers. If
two nodes have an ISID in common, intermediate nodes on the unique two nodes have an ISID in common, intermediate nodes on the unique
shortest path between them will create forwarding state for the shortest path between them will create forwarding state for the
related B-MAC addresses and will also construct multicast related B-MAC addresses and will also construct multicast
forwarding state using the ISID and the node's SPSOURCEID to forwarding state using the ISID and the node's SPSOURCEID to
construct a multicast DA as described in IEEE 802.1aq LSB. Each construct a multicast DA as described in IEEE 802.1aq LSB. Each
ISID has a Transmit(T) and Receive(R) bit which indicates if the ISID has a Transmit(T) and Receive(R) bit which indicates if the
membership is as a Transmitter/Receiver or both (with both bits membership is as a Transmitter/Receiver or both (with both bits
set). In the case where the Transmit(T) and Receive(R) bits are set). In the case where the Transmit(T) and Receive(R) bits are
both zero, the ISID is ignored. If more ISIDs are associated with both zero, the ISID is ignored. If more ISIDs are associated with
a particular B-MAC than can fit in a single TLV, this TLV can be a particular B-MAC than can fit in a single sub-TLV, this sub-TLV
repeated with the same B-MAC but with different ISID values. can be repeated with the same B-MAC but with different ISID
values.
2.6. Sub-TLVs of the Extended Reachability TLV 2.6. Sub-TLVs of the Extended Reachability TLV
This section specifies two new sub-TLVs that appear only within the This section specifies two new sub-TLVs that appear only within the
Extended Reachability TLV (type 22). Extended Reachability TLV (type 22).
2.6.1. SPB Link Metric sub-TLV 2.6.1. SPB Link Metric sub-TLV
The SPB Link Metric sub-TLV occurs nested as within the Extended The SPB Link Metric sub-TLV occurs within the Extended Reachability
Reachability TLV (type 22), or the Multi Topology Intermediate System TLV (type 22), or the Multi Topology Intermediate System TLV (type
TLV (type 222). If this sub TLV is not present for an ISIS adjacency 222). If this sub TLV is not present for an ISIS adjacency then that
then that adjacency MUST NOT carry SPB traffic for the given topology adjacency MUST NOT carry SPB traffic for the given topology instance.
instance.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=SPB-Metric| |Type=SPB-Metric|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPB-LINK-METRIC | (3 bytes) | SPB-LINK-METRIC | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of ports | (1 byte) | Num of ports | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Identifier | ( 2 bytes) | Port Identifier | ( 2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Algorithm (32 bytes) | | Opaque ECT Algorithm (32 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable ) | | Opaque ECT Information (variable ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to SPB Link Metric sub-TLV 5 [TBD]. o Type: sub-TLV Type, set to SPB Link Metric sub-TLV 5 [TBD].
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o SPB-LINK-METRIC indicates the administrative cost or weight of o SPB-LINK-METRIC indicates the administrative cost or weight of
using this link as a 24 bit unsigned number. Smaller numbers using this link as a 24 bit unsigned number. Smaller numbers
indicate lower weights and are more likely to carry SPB traffic. indicate lower weights and are more likely to carry SPB traffic.
Only one metric is allowed per SPB instance per link. If multiple Only one metric is allowed per SPB instance per link. If multiple
metrics are required multiple SPB instances are required, either metrics are required multiple SPB instances are required, either
within IS-IS or within several independent IS-IS instances. within IS-IS or within several independent IS-IS instances.
o Num of Ports is the number of ports associated with this link. o Num of Ports is the number of ports associated with this link.
o Port Identifier is the standard IEEE port identifier used to build o Port Identifier is the standard IEEE port identifier used to build
a spanning tree associated with this link. a spanning tree associated with this link.
o an opaque ECT Data TLV (type TBD) whose first 32 bits are the ECT- o an opaque ECT Data sub-TLV (type TBD) whose first 32 bits are the
ALGORITHM to which this data applies. ECT-ALGORITHM to which this data applies.
2.6.2. MTU sub-TLV 2.6.2. MTU sub-TLV
The MTU sub-TLV is used to optionally announce the MTU of a link. It The MTU sub-TLV is used to optionally announce the MTU of a link. It
occurs nested as within the Extended Reachability TLV (type 22). occurs nested as within the Extended Reachability TLV (type 22).
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = MTU | | Type = MTU |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F| Reserved | (1 byte) |F| Reserved | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes) | MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to MTU sub-TLV 6 [TBD]. o Type: sub-TLV Type, set to MTU sub-TLV 6 [TBD].
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Failed: This bit is a one if MTU testing on this link failed at o F: Failed. This bit is a one if MTU testing on this link failed
the required campus-wide MTU. at the required campus-wide MTU.
o MTU: This field is set to the largest successfully tested MTU size o MTU: This field is set to the largest successfully tested MTU size
for this link or zero if it has not been tested. for this link or zero if it has not been tested.
2.7. TRILL Neighbor TLV 2.7. TRILL Neighbor TLV
The TRILL Neighbor TLV is used in the TRILL-Hello PDU in place of the The TRILL Neighbor TLV is used in the TRILL-Hello PDU in place of the
IS Neighbor TLV. It differs in that MTU information is provided per IS Neighbor TLV. It differs in that MTU information is provided per
neighbor and provision is made for fragmentation, so that not all neighbor and provision is made for fragmentation, so that not all
neighbors need be reported in each TRILL-Hello, to support the hard neighbors need be reported in each TRILL-Hello, to support the hard
skipping to change at page 40, line 4 skipping to change at page 42, line 4
each 6-byte MAC address to be an unsigned integer, starting with the each 6-byte MAC address to be an unsigned integer, starting with the
smallest. The information present for each neighbor is as follows: smallest. The information present for each neighbor is as follows:
+-+-------------------+ +-+-------------------+
|F| Reserved | (2 bytes) |F| Reserved | (2 bytes)
+-+-------------------+ +-+-------------------+
| MTU | (2 bytes) | MTU | (2 bytes)
+--------------------------------------------------------+ +--------------------------------------------------------+
| MAC Address | (6 bytes) | MAC Address | (6 bytes)
+--------------------------------------------------------+ +--------------------------------------------------------+
o Type: TLV Type, set to TRILL-Neighbor TLV XX [TBD]. o Type: TLV Type, set to TRILL-Neighbor TLV 145 [TBD].
o Length: Total number of bytes contained in the value field, 2 + o Length: Total number of bytes contained in the value field, 2 +
10*n, where n is the number of neighbor records. 10*n, where n is the number of neighbor records.
o S: smallest flag. If this bit is a one, then the list of o S: smallest flag. If this bit is a one, then the list of
neighbors includes the neighbor with the smallest MAC address. neighbors includes the neighbor with the smallest MAC address.
o L: largest flag. If this bit is a one, then the list of neighbors o L: largest flag. If this bit is a one, then the list of neighbors
includes the neighbor with the largest MAC address. includes the neighbor with the largest MAC address.
o Reserved: These bits are reserved for future use and MUST be set o Reserved: These bits are reserved for future use and MUST be set
to zero on transmission and ignored on receipt. to zero on transmission and ignored on receipt.
o F: failed. This bit is a one if MTU testing to their neighbor o F: failed. This bit is a one if MTU testing to their neighbor
(see Section 3.3) failed at the required campus-wide MTU (see Section 2.9.6) failed at the required campus-wide MTU
o MTU: This field is set to the largest successfully tested MTU size o MTU: This field is set to the largest successfully tested MTU size
for this neighbor or zero if it has not been tested. for this neighbor or zero if it has not been tested.
o MAC Address: The MAC address of the neighbor as in the IS Neighbor o MAC Address: The MAC address of the neighbor as in the IS Neighbor
RLV (#6). RLV (#6).
2.8. The Group Membership Active Source TLV 2.8. The Group Membership Active Source TLV
The Group Active Source (GMAS) TLV is IS-IS TLV type 146 [TBD] and The Group Active Source (GMAS) TLV is IS-IS TLV type 146 [TBD] and
skipping to change at page 41, line 8 skipping to change at page 43, line 8
o sub-TLVs: The Group Active Source TLV value contains sub-TLVs o sub-TLVs: The Group Active Source TLV value contains sub-TLVs
formatted as described in [RFC5305]. The sub-TLVs for this TLV formatted as described in [RFC5305]. The sub-TLVs for this TLV
are specified in the following subsections. are specified in the following subsections.
The GMAS TLV is carried within Multicast Group Level 1 link state The GMAS TLV is carried within Multicast Group Level 1 link state
PDU. PDU.
2.8.1. The Group MAC Active Source sub-TLV 2.8.1. The Group MAC Active Source sub-TLV
The Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 1 The Group MAC Source (GMAS-MAC) sub-TLV is IS-IS sub-TLV type 1
within the GMAS TLV and has the following format: within the GMAS TLV. It is used in OTV [OTV] to create multicast
distribution trees and has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type=GMAS-MAC | (1 byte) | Type=GMAS-MAC | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|D| R | Vlan ID | (2 byte) |G|S| R | Vlan ID | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address family | (2 bytes) | Address family | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery group (afi scoped number of bytes) | | Delivery group (afi scoped number of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery Source (afi scoped number of bytes) | | Delivery Source (afi scoped number of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) |Num Group Recs | (1 byte)
skipping to change at page 42, line 8 skipping to change at page 44, line 8
| Source 1 Address (6 bytes) | | Source 1 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (6 bytes) | | Source 2 Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (6 bytes) | | Source M Address (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 1 (GMAS-MAC) of length 1 byte. o Type: sub-TLV Type, set to 1 (GMAS-MAC) of length 1 byte.
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Confidence: This carries an 8-bit quantity indicating the o G (1 bit): Delivery Group is set
confidence level in the MAC addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
MUST be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname : Depending on the technology in which it is o S (1 bit): Delivery Source is set
used, this carries the topology-id or nickname. When this field
is set to zero this implies that the MAC addresses are reachable
across all topologies or across all nicknames of the originating
IS.
o RESERVED: Must be sent as zero on transmission and is ignored on o RESERVED (2 bits) : Must be sent as zero on transmission and is
receipt. ignored on receipt.
o G: Delivery Group is set o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
all subsequent MAC addresses in this sub-TLV, or the value zero if
no VLAN is specified.
o S: Delivery Source is set o Address Family: Describes the Address family of the Delivery
Source/Group information.
o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for o Length: Gives the length of the Delivery Source and Delivery Group
all subsequent MAC addresses in this TLV, or the value zero if no field.
VLAN is specified.
o Delivery Group: Describes the group used to deliver packets.
o Delivery Source: Describes the source address used to deliver
packets.
o Number of Group Records: This is of length 1 byte and lists the o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV. number of group records in this sub-TLV.
o Group Record: Each group record has a one byte reserved space and o Group Record: Each group record has a one byte reserved space and
the next byte carries the number of sources. It then has a 48-bit the next byte carries the number of sources. It then has a 48-bit
multicast Group Address followed by 48-bit source MAC addresses. multicast Group Address followed by 48-bit source MAC addresses.
An address being a group multicast address or unicast source An address being a group multicast address or unicast source
address can be checked using the multicast bit in the address. If address can be checked using the multicast bit in the address. If
the number of sources do not fit in a single sub-TLV, it is the number of sources do not fit in a single sub-TLV, it is
permitted to have the same group address repeated with different permitted to have the same group address repeated with different
source addresses in another sub-TLV of another instance of the source addresses in another sub-TLV of another instance of the
Group Active Source TLV. Group Active Source TLV.
The GMAS-MAC sub-TLV is carried within the GMAS TLV and MUST be The GMAS-MAC sub-TLV is carried within the GMAS TLV and MUST be
carried in a standard Level 1 link state MGROUP PDU. carried in a standard Level 1 link state MGROUP PDU.
2.8.2. The Group IP Active Source sub-TLV 2.8.2. The Group IP Active Source sub-TLV
The Group IP Address (GMAS-IP) sub-TLV is IS-IS TLV type 2 and has The Group IP Address (GMAS-IP) sub-TLV is IS-IS TLV type 2. It is
the following format: used in OTV [OTV] to create multicast distribution trees and has the
following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type=GMAS-IP | (1 byte) | Type=GMAS-IP | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|D| R | Vlan ID | (2 byte) |G|S| R | Vlan ID | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address family | (2 bytes) | Address family | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery group (afi scoped number of bytes) | | Delivery group (afi scoped number of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery Source (afi scoped number of bytes) | | Delivery Source (afi scoped number of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) |Num Group Recs | (1 byte)
skipping to change at page 43, line 48 skipping to change at page 45, line 48
| Source 1 Address (4 bytes) | | Source 1 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (4 bytes) | | Source 2 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (4 bytes) | | Source M Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 2 (GIP-ADDR). o Type: sub-TLV Type, set to 2 (GIP-ADDR).
o Length: Total number of bytes contained in the value field of the o Length: Total number of bytes contained in the value field of the
TLV. sub-TLV.
o Confidence: This carries an 8-bit quantity indicating the o G (1 bit): Delivery Group is set
confidence level in the IP addresses being transported. Whether o S (1 bit): Delivery Source is set
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname : Depending on the technology in which it is o RESERVED (2 bits) : Must be sent as zero on transmission and is
used, this carries the topology-id or nickname. When this field ignored on receipt.
is set to zero this implies that the MAC addresses are reachable
across all topologies or across all nicknames of the originating
IS.
o RESERVED: Must be sent as zero on transmission and is ignored on o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
receipt. all subsequent MAC addresses in this sub-TLV, or the value zero if
no VLAN is specified.
o G: Delivery Group is set o Address Family: Describes the Address family of the Delivery
Source/Group information.
o S: Delivery Source is set o Length: Gives the length of the Delivery Source and Delivery Group
field.
o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for o Delivery Group: Describes the group used to deliver packets.
all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified. o Delivery Source: Describes the source address used to deliver
packets.
o Number of Group Records: This is of length 1 byte and lists the o Number of Group Records: This is of length 1 byte and lists the
number of group records in this TLV. number of group records in this sub-TLV.
o Group Record: Each group record has a one byte reserved space and o Group Record: Each group record has a one byte reserved space and
the next byte carries the number of sources. It is followed by a the next byte carries the number of sources. It is followed by a
32-bit IPv4 Group Address followed by 32-bit source IPv4 32-bit IPv4 Group Address followed by 32-bit source IPv4
addresses. If the number of sources do not fit in a single sub- addresses. If the number of sources do not fit in a single sub-
TLV, it is permitted to have the same group address repeated with TLV, it is permitted to have the same group address repeated with
different source addresses repeated in another sub-TLV of another different source addresses repeated in another sub-TLV of another
instance of the Group Active Source TLV. instance of the Group Active Source TLV.
The GMAS-IP TLV is carried within the GMAS TLV and MUST be carried in The GMAS-IP TLV is carried within the GMAS TLV and MUST be carried in
a standard Level 1 link state MGROUP PDU. a standard Level 1 link state MGROUP PDU.
2.8.3. The Group IPv6 Active Source sub-TLV 2.8.3. The Group IPv6 Active Source sub-TLV
The Group IPv6 Active Source (GMAS-IPv6) TLV is IS-IS sub-TLV type 3 The Group IPv6 Active Source (GMAS-IPv6) sub-TLV is IS-IS sub-TLV
and has the following format: type 3. It is used in OTV [OTV] to create multicast distribution
trees and has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type=GMAS-IP | (1 byte) | Type=GMAS-IP | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|D| R | Vlan ID | (2 byte) |G|S| R | Vlan ID | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address family | (2 bytes) | Address family | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery group (afi scoped number of bytes) | | Delivery group (afi scoped number of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delivery Source (afi scoped number of bytes) | | Delivery Source (afi scoped number of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) |Num Group Recs | (1 byte)
skipping to change at page 45, line 49 skipping to change at page 47, line 49
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (16 bytes) | | Source 2 Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (16 bytes) | | Source M Address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type, set to 3 (GIPV6-ADDR). o Type: sub-TLV Type, set to 3 (GIPV6-ADDR).
o Length: Total number of bytes contained in the value field. o Length: Total number of bytes contained in the value field.
o Confidence: This carries an 8-bit quantity indicating the o G (1 bit): Delivery Group is set
confidence level in the IPv6 addresses being transported. Whether
this field is used, and its semantics if used, are further defined
by the specific protocol using Layer-2-IS-IS. If not used, it
must be set to zero on transmission and be ignored on receipt.
o Topology-Id/Nickname : Depending on the technology in which it is o S (1 bit): Delivery Source is set
used, this carries the topology-id or nickname. When this field o RESERVED (2 bits) : Must be sent as zero on transmission and is
is set to zero this implies that the MAC addresses are reachable ignored on receipt.
across all topologies or across all nicknames of the originating
IS.
o RESERVED: Must be sent as zero on transmission and is ignored on o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for
receipt. all subsequent MAC addresses in this sub-TLV, or the value zero if
no VLAN is specified.
o G: Delivery Group is set o Address Family: Describes the Address family of the Delivery
Source/Group information.
o S: Delivery Source is set o Length: Gives the length of the Delivery Source and Delivery Group
field.
o VLAN-ID: This carries a 12-bit VLAN identifier that is valid for o Delivery Group: Describes the group used to deliver packets.
all subsequent MAC addresses in this TLV, or the value zero if no
VLAN is specified. o Delivery Source: Describes the source address used to deliver
packets.
o Number of Group Records: This of length 1 byte and lists the o Number of Group Records: This of length 1 byte and lists the
number of group records in this TLV. number of group records in this sub-TLV.
o Group Record: Each group record has a one byte reserved space and o Group Record: Each group record has a one byte reserved space and
the next byte carries the number of sources. It is followed by a the next byte carries the number of sources. It is followed by a
128-bit multicast IPv6 Group Address followed by 128-bit source 128-bit multicast IPv6 Group Address followed by 128-bit source
IPv6 addresses. If the number of sources do not fit in a single IPv6 addresses. If the number of sources do not fit in a single
sub-TLV, it is permitted to have the same group address repeated sub-TLV, it is permitted to have the same group address repeated
with different source addresses repeated in another sub-TLV in with different source addresses repeated in another sub-TLV in
another instance of the Group Address TLV. another instance of the Group Address TLV.
The GMAS-IPv6 sub-TLV is carried within the GMAS TLV and MUST be The GMAS-IPv6 sub-TLV is carried within the GMAS TLV and MUST be
skipping to change at page 47, line 27 skipping to change at page 49, line 26
The Multicast Group (MGROUP) PDU can be used to advertise a set of The Multicast Group (MGROUP) PDU can be used to advertise a set of
attached, or joined, multicast groups. The MGROUP PDU is formatted 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 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 [IS-IS]. One field, PDU Type, is changed to 19 [TBD], to signify
this PDU is carrying multicast group information, rather than unicast this PDU is carrying multicast group information, rather than unicast
reachability information. reachability information.
The Multicast Group PDU carries TLVs indicating multicast membership The Multicast Group PDU carries TLVs indicating multicast membership
information. There are three sub-TLVs of the GADDR TLV defined in information. There are three sub-TLVs of the GADDR TLV defined in
this document, that MAY be present in this PDU, namely, GMAC-ADDR, this document, that MAY be present in this PDU, namely, GMAC-ADDR,
GIP-ADDR, and GIPV6-ADDR TLVs. GIP-ADDR, and GIPV6-ADDR sub-TLVs. Furthermore, it MAY carry the
interested vlan sub-TLV of the Capability TLV.
One or more TLVs MAY be carried in a single MGROUP PDU. Future 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 multicast address TLVs MAY be defined using other type codes, and be
carried in an MGROUP PDU. carried in an MGROUP PDU.
The information carried in this PDU is processed in a similar fashion The information carried in this PDU is processed in a similar fashion
as described in [RFC 1584]. as described in [RFC 1584].
2.9.1.1. The Multicast Group Partial Sequence Number PDU 2.9.2. The Multicast Group Partial Sequence Number PDU
The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used The Multicast Group Partial Sequence Number (MGROUP-PSNP) PDU is used
to reliably flood the MGROUP PDU following the base protocol to reliably flood the MGROUP PDU following the base protocol
specifications. specifications.
2.9.1.2. The Multicast Group Complete Sequence Number PDU 2.9.3. The Multicast Group Complete Sequence Number PDU
The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is The Multicast Group Complete Sequence Number PDU (MGROUP-CSNP) PDU is
used to reliably flood the MGROUP PDU following the base protocol used to reliably flood the MGROUP PDU following the base protocol
specifications. specifications.
2.9.1.3. Enhancements to the flooding process 2.9.4. MGROUP PDU related changes to Base protocol
In this section, we describe the changes to the base protocol due to
the introduction of the MGROUP, MGROUP-PSNP, MGROUP-CNSP PDUs.
2.9.4.1. Enhancements to the flooding process
This document specifies that the information contained in the MGROUP- This document specifies that the information contained in the MGROUP-
PDU is in a parallel database and its update mechanisms mimic that of 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 the regular database. Nodes running IS-IS in an L2 domain MUST
support these additional MGROUP PDUs defined in this document. In support these additional MGROUP PDUs defined in this document. In
general, the flooding of the MGROUP-PDU in tandem with the MGROUP- general, the flooding of the MGROUP-PDU in tandem with the MGROUP-
PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined PSNP and MGROUP-CSNP PDUs uses the same update procedures as defined
for the regular LSP, PSNP, and CSNP PDUs. for the regular LSP, PSNP, and CSNP PDUs.
For example, on P2P links CSNP is exchanged on the formation of an 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 adjacency. In a similar fashion a MGROUP-CSNP MUST also be exchanged
between the neighbors at the same time. This gets the initial between the neighbors at the same time. This gets the initial
MGROUP-database synchronization going. After this similar actions of MGROUP-database synchronization going. After this similar actions of
the base protocol specifications for the regular database the base protocol specifications for the regular database
synchronization will be maintained to keep the MGROUP-database synchronization will be maintained to keep the MGROUP-database
synchronized. synchronized. There need not be any more correlation between the
updates of the regular PDU and the MGROUP-PDU.
Similarly, on LAN links the DIS is responsible for sending periodic Similarly, on LAN links the DIS is responsible for sending periodic
CSNP transmissions. The DIS in the L2 IS-IS network domain will also CSNP transmissions. The DIS in the L2 IS-IS network domain will also
be responsible for sending periodic MGROUP-CSNP transmissions. The be responsible for sending periodic MGROUP-CSNP transmissions. The
update and flooding process will work in parallel for the two update and flooding process will work in parallel for the two
databases and there is no further synchronization between them. databases and there is no further synchronization between them.
In general, the database synchronization is performed in parallel In general, the database synchronization is performed in parallel
with no interactions between the messages. However, the initial with no interactions between the messages. However, the initial
triggers that start a CSNP exchange are correlated, in the sense it triggers that start a CSNP exchange are correlated, in the sense it
also triggers a MGROUP-CSNP exchange. For example, during graceful also triggers a MGROUP-CSNP exchange.
restart [RFC 5306], the normal hello operations as described in the
RFC will be followed. The enhancements will take place such that
CSNP and PSNP triggers will necessitate a parallel MGROUP-CSNP and
MGROUP-PSNP exchange and update process will be triggered in parallel
for the MGROUP-PDUs. After both databases containing the regular
PDUs and MGROUP-PDUs have been obtained, the restart process is
deemed complete.
2.9.1.4. Enhancements to the maximum sequence number reached 2.9.4.2. Enhancements to Graceful Restart
During graceful restart [RFC 5306], the normal hello operations as
described in the RFC will be followed. The enhancements will take
place such that CSNP and PSNP triggers will necessitate a parallel
MGROUP-CSNP and MGROUP-PSNP exchange and update process will be
triggered in parallel for the MGROUP-PDUs. After both databases
containing the regular PDUs and MGROUP-PDUs have been obtained, the
restart process is deemed complete.
2.9.4.3. Enhancements to the maximum sequence number reached
In the event, LSPs reach the maximum sequence number, ISO/IEC 10589 In the event, LSPs reach the maximum sequence number, ISO/IEC 10589
states the rules for the process to shut down and its duration. With states the rules for the process to shut down and its duration. With
the introduction of the MGROUP-PDU, the same process now applies when the introduction of the MGROUP-PDU, the same process now applies when
LSPs from either database reach the maximum sequence number. LSPs from either database reach the maximum sequence number.
2.9.2. The TRILL-Hello PDU 2.9.4.4. Enhancements to the SPF
The MGROUP-PDU advertises a set of attached, or joined, multicast
groups. These groups act as leaves of the advertising nodes. As a
result, there are no new requirements of running a SPF if only
information within the MGROUP-PDU changes.
2.9.5. The TRILL-Hello PDU
A different Hello PDU is required for TRILL links because it is A different Hello PDU is required for TRILL links because it is
necessary that a single Designated RBridge (DIS) be elected on each necessary that a single Designated RBridge (DIS) be elected on each
link based just on priority and MAC address regardless of two-way link based just on priority and MAC address regardless of two-way
connectivity. However, RBridge reachability is reported by RBridges connectivity. However, RBridge reachability is reported by RBridges
in their LSP on the same basis as layer 3 Intermediate Systems report in their LSP on the same basis as layer 3 Intermediate Systems report
reachability, that is, if and only if two-way connectivity exists. reachability, that is, if and only if two-way connectivity exists.
The TRILL-Hello PDU has the same general structure as an IS-IS LAN The TRILL-Hello PDU has the same general structure as an IS-IS LAN
PDU. An RBridge (an Intermediate System supporting TRILL) sends this PDU. An RBridge (an Intermediate System supporting TRILL) sends this
PDU, with the same timing as the IS-IS LAN Hello PDU. More PDU, with the same timing as the IS-IS LAN Hello PDU. More
specifically, in a TRILL-Hello PDU the IS-IS Common Header and the specifically, in a TRILL-Hello PDU the IS-IS Common Header and the
fixed PDU Header are the same as a Level 1 IS-IS LAN Hello except fixed PDU Header are the same as a Level 1 IS-IS LAN Hello except
that a new PDU Type number is used as listed in Section 7. The that a new PDU Type number is used as listed in Section 5. The
circuit type field, of course, is always equal to one. A TRILL-Hello circuit type field, of course, is always equal to one. A TRILL-Hello
PDU SHOULD not be padded and MUST NOT exceed a length limit equal to PDU SHOULD not be padded and MUST NOT exceed a length limit equal to
42 bytes shorter than the reasonable lower bound for the link MTU. 42 bytes shorter than the reasonable lower bound for the link MTU.
For example, for an 802.3 Ethernet link, the MTU SHOULD be assumed to For example, for an 802.3 Ethernet link, the MTU SHOULD be assumed to
be 1512 bytes for the purpose of determining the maximum size of be 1512 bytes for the purpose of determining the maximum size of
TRILL-Hello PDUs on that link. Thus, for such a link, TRILL-Hellos TRILL-Hello PDUs on that link. Thus, for such a link, TRILL-Hellos
MUST NOT exceed 1470 bytes. MUST NOT exceed 1470 bytes.
The following MUST appear in every TRILL-Hello PDU: a Port Capability The following MUST appear in every TRILL-Hello PDU: a Port Capability
TLV (see Section 2.3) containing a Special VLANs and Flags sub-TLV. TLV (see Section 2.3) containing a Special VLANs and Flags sub-TLV.
skipping to change at page 49, line 32 skipping to change at page 51, line 48
Additional TLVs/sub-TLVs MAY appear in a TRILL-Hello including the Additional TLVs/sub-TLVs MAY appear in a TRILL-Hello including the
TRILL Neighbor TLV specified in Section 2.7 and the following sub- TRILL Neighbor TLV specified in Section 2.7 and the following sub-
TLVs specified in Section 2.3: Enabled VLANs sub-TLV, Appointed TLVs specified in Section 2.3: Enabled VLANs sub-TLV, Appointed
Forwarders sub-TLV, and Hop-by-Hop Options sub-TLV. Forwarders sub-TLV, and Hop-by-Hop Options sub-TLV.
The Padding TLV (#8) SHOULD NOT appear in a TRILL-Hello. The Padding TLV (#8) SHOULD NOT appear in a TRILL-Hello.
The IS-IS Neighbor TLV (#6) MUST NOT appear in a TRILL-Hello. The IS-IS Neighbor TLV (#6) MUST NOT appear in a TRILL-Hello.
Instead, it uses the TRILL Neighbor TLV (see Section 2.7). Instead, it uses the TRILL Neighbor TLV (see Section 2.7).
2.9.3. The MTU PDU 2.9.6. The MTU PDU
The MTU-probe and MTU-ack PDUs are used to determine the MTU on a The MTU-probe and MTU-ack PDUs are used to determine the MTU on a
link between intermediate systems. An MTU-probe MUST be padded to link between intermediate systems. An MTU-probe MUST be padded to
the size being tested with the Padding TLV (#8). The ability to send the size being tested with the Padding TLV (#8). The ability to send
an MTU-probe PDU is optional but an Intermediate System that supports an MTU-probe PDU is optional but an Intermediate System that supports
TRILL MUST send an MTU-ack in response to an MTU-probe and that MTU- TRILL MUST send an MTU-ack in response to an MTU-probe and that MTU-
ack MUST be padded to the size of the MTU-probe. ack MUST be padded to the size of the MTU-probe.
The MTU PDUs have the standard IS-IS common header with two new PDU The MTU PDUs have the standard IS-IS common header with two new PDU
Type numbers, one each, as listed in Section 7. They also have a 20- Type numbers, one each, as listed in Section 5. They also have a 20-
byte common fixed MTU PDU header as shown below. byte common fixed MTU PDU header as shown below.
+------------+ +------------+
| PDU Length | (2 bytes) | PDU Length | (2 bytes)
+------------+-------------------------+ +------------+-------------------------+
| Probe ID | (6 bytes) | Probe ID | (6 bytes)
+--------------------------------------+ +--------------------------------------+
| Probe Source ID | (6 bytes) | Probe Source ID | (6 bytes)
+--------------------------------------+ +--------------------------------------+
| Ack Source ID | (6 bytes) | Ack Source ID | (6 bytes)
skipping to change at page 50, line 39 skipping to change at page 55, line 7
The authors would like to thank Les Ginsberg and Mike Shand for their The authors would like to thank Les Ginsberg and Mike Shand for their
useful comments. useful comments.
4. Security Considerations 4. Security Considerations
This document adds no additional security risks to IS-IS, nor does it This document adds no additional security risks to IS-IS, nor does it
provide any additional security for IS-IS. provide any additional security for IS-IS.
5. IANA Considerations 5. IANA Considerations
This document creates six new PDU types, namely the MCAST PDU, MCAST- This document creates six new PDU types, namely the MGROUP PDU,
CSNP PDU, the MCAST-PSNP PDU, TRILL-HELLO-PDU, MTU-PROBE-PDU, and MGROUP-CSNP PDU, the MGROUP-PSNP PDU, TRILL-HELLO-PDU, MTU-PROBE-PDU,
MTU-ACK-PDU. IANA SHOULD assign a new PDU type to the level-1 PDUs and MTU-ACK-PDU. IANA SHOULD assign a new PDU type to the level-1
described above and reflect it in the PDU registry. PDUs described above and reflect it in the PDU registry.
MCAST-PDU Level-1 PDU Type: 19 MGROUP-PDU Level-1 PDU Type: 19
MCAST-CSNP-PDU Level-1 PDU Type: 22 MGROUP-CSNP-PDU Level-1 PDU Type: 22
MCAST-PSNP-PDU Level-1 PDU Type: 29 MGROUP-PSNP-PDU Level-1 PDU Type: 29
TRILL-HELLO-PDU Level-1 PDU Type: 21 TRILL-HELLO-PDU Level-1 PDU Type: 21
MTU-PROBE-PDU Level-1 PDU Type: 23 MTU-PROBE-PDU Level-1 PDU Type: 23
MTU-ACK-PDU Level-1 PDU Type: 28 MTU-ACK-PDU Level-1 PDU Type: 28
This document specifies the definition a set of new IS-IS TLVs, the This document specifies the definition of a set of new IS-IS TLVs,
MAC-Reachability TLV (type 141), the Group Address TLV (type 142), the MAC-Reachability TLV (type 141), the Group Address TLV (type
the Port-Capability TLV (type 143), the MT-Capability TLV (type 144), 142), the Port-Capability TLV (type 143), the MT-Capability TLV (type
and the Trill-Neighbor TLV (type 145), and Group Member Active Source 144), and the Trill-Neighbor TLV (type 145), and Group Member Active
TLV (type 146) that needs to be reflected in the IS-IS TLV code-point Source TLV (type 146) that need to be reflected in the IS-IS TLV
registry. code-point registry.
This document creates a number of new sub-TLVs in the numbering space This document creates a number of new sub-TLVs in the numbering space
for the Group Address TLV, the MT Port Capability TLV, the Extended for the Group Address TLV, the MT Port Capability TLV, the Extended
Reachability TLV, the MT-Capability TLV, and the Capability TLV. The Reachability TLV, the MT-Capability TLV, and the Capability TLV. The
TLV and sub-TLVs are given below along with technologies that use TLV and sub-TLVs are given below along with technologies that use
them. them.
IIH LSP SNP MCAST MCAST TRILL/ IIH LSP SNP MGROUP MGROUP TRILL/
LSP SNP IEEE LSP SNP IEEE/OTV
MAC-RI TLV (141) - X - - - T/I MAC-RI TLV (141) - X - - - T/I/O
GADDR-TLV (142) - - - X - -/I GADDR-TLV (142) - - - X - T/I/O
GADDR-TLV.GMAC-ADDR sub-TLV 1 - - - X - T/I GADDR-TLV.GMAC-ADDR sub-TLV 1 - - - X - T/-/O
GADDR-TLV.GMAC-IP sub-TLV 2 - - - X - T/I GADDR-TLV.GMAC-IP sub-TLV 2 - - - X - T/-/O
GADDR-TLV.GMAC-IPV6 sub-TLV 3 - - - X - T/I GADDR-TLV.GMAC-IPV6 sub-TLV 3 - - - X - T/-/O
GADDR-TLV.SPBV-MAC-ADDR sub-TLV 4 - - - X - -/I GADDR-TLV.SPBV-MAC-ADDR sub-TLV 4 - - - X - -/I/-
MT-Port-Cap-TLV (143) X - - - - T/- MT-Port-Cap-TLV (143) X - - - - T/I/O
PortCap.VLAN and Flags sub-TLV 1 X - - - - T/- PortCap.VLAN and Flags sub-TLV 1 X - - - - T/-/-
PortCap.Enabled-VLANs sub-TLV 2 X - - - - T/- PortCap.Enabled-VLANs sub-TLV 2 X - - - - T/-/-
PortCap.AppointedFwrdrs sub-TLV 3 X - - - - T/- PortCap.AppointedFwrdrs sub-TLV 3 X - - - - T/-/-
PortCap.HBHOPT sub-TLV 4 X - - - - T/- PortCap.HBHOPT sub-TLV 4 X - - - - T/-/-
PortCap.BaseVLANID sub-TLV 5 X - - - - -/I PortCap.BaseVLANID sub-TLV 5 X - - - - -/I/-
PortCap.SPBDigest sub-TLV 6 X - - - - -/I PortCap.SPBDigest sub-TLV 6 X - - - - -/I/-
PortCap.SiteIdentifier sub-TLV 250 X - - - - -/- PortCap.SiteIdentifier sub-TLV 250 X - - - - -/-/O
PortCap.SiteGroupIP sub-TLV 251 X - - - - -/- PortCap.SiteGroupIP sub-TLV 251 X - - - - -/-/O
PortCap.SiteGroupIPv6 sub-TLV 252 X - - - - -/- PortCap.SiteGroupIPv6 sub-TLV 252 X - - - - -/-/O
PortCap.AdjServerIP sub-TLV 253 X - - - - -/- PortCap.AdjServerIP sub-TLV 253 X - - - - -/-/O
PortCap.AdjServerIPv6 sub-TLV 254 X - - - - -/- PortCap.AdjServerIPv6 sub-TLV 254 X - - - - -/-/O
CAPABILITY.Trill-Version sub-TLV 5 - X - - - T/- CAPABILITY.Trill-Version sub-TLV 5 - X - X - T/-/-
CAPABILITY.Nickname sub-TLV 6 - X - - - T/- CAPABILITY.Nickname sub-TLV 6 - X - - - T/-/-
CAPABILITY.Tree sub-TLV 7 - X - - - T/- CAPABILITY.Tree sub-TLV 7 - X - - - T/-/-
CAPABILITY.Tree Id sub-TLV 8 - X - - - T/- CAPABILITY.Tree Id sub-TLV 8 - X - - - T/-/-
CAPABILITY.TreeUseRootId sub-TLV 9 - X - - - T/- CAPABILITY.TreeUseRootId sub-TLV 9 - X - - - T/-/-
CAPABILITY.Int-VLANs sub-TLV 10 - X - X - T/- CAPABILITY.Int-VLANs sub-TLV 10 - - - X - T/-/-
CAPABILITY.VLAN-Groups sub-TLV 11 - X - - - T/- CAPABILITY.VLAN-Groups sub-TLV 11 - X - - - T/-/-
CAPABILITY.ITEOPT sub-TLV 12 - X - - - T/- CAPABILITY.ITEOPT sub-TLV 12 - X - - - T/-/-
CAPABILITY.VMAP sub-TLV 13 - X - - - T/- CAPABILITY.VMAP sub-TLV 13 - X - - - T/-/-
MT-Capability-TLV (144) - X - - - -/I MT-Capability-TLV (144) - X - - - -/I/-
MT-Cap.SPB Instance sub-TLV 1 - X - - - -/I MT-Cap.SPB Instance sub-TLV 1 - X - - - -/I/-
MT-Cap.Service Id. sub-TLV 2 - X - - - -/I MT-Cap.Service Id. sub-TLV 2 - X - - - -/I/-
TRILL-Nieghbor TLV (145) X - - - - T/- TRILL-Nieghbor TLV (145) X - - - - T/-/-
EXT-IS.SPB Link Metric sub-TLV 5 - X - - - -/I EXT-IS.SPB Link Metric sub-TLV 5 - X - - - -/I/-
EXT-IS.MTU sub-TLV 6 - X - - - T/- EXT-IS.MTU sub-TLV 6 - X - - - T/-/-
MT-EXT-IS.SPB LinkMetric sub-TLV 5 - X - - - -/I MT-EXT-IS.SPB LinkMetric sub-TLV 5 - X - - - -/I/-
Group Mem Active Source TLV (146) - - - X - -/- Group Mem Active Source TLV (146) - - - X - -/-/O
GMAS-TLV.GMAS-MAC sub-TLV 1 - - - X - -/- GMAS-TLV.GMAS-MAC sub-TLV 1 - - - X - -/-/O
GMAS-TLV.GMAS-IP sub-TLV 2 - - - X - -/- GMAS-TLV.GMAS-IP sub-TLV 2 - - - X - -/-/O
GMAS-TLV.GMAS-IPV6 sub-TLV 3 - - - X - -/- GMAS-TLV.GMAS-IPV6 sub-TLV 3 - - - X - -/-/O
IANA SHOULD manage the remaining space using the IETF Review method IANA SHOULD manage the remaining space using the IETF Review method
[RFC 5226]. [RFC 5226].
6. Contributing Authors 6. References
David Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, California 94089-1206 USA
Phone: +1-408-745-2000
Email: dward@juniper.net
Russ White
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: riw@cisco.com
Dino Farinacci
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: dino@cisco.com
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054-1549
US
Phone: +1-408-765-8080
Email: Radia@alum.mit.edu
Donald E. Eastlake 3rd
Stellar Switches
155 Beaver Street
Milford, MA 07157
US
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Peter Ashwood-Smith
Huawei Technologies Canada Co. Ltd.
411 Legget Drive, Suite 503
Kanta, Ontario K2K 3C9
CANADA
Email: Peter.AshwoodSmith@huawei.com
Don Fedyk
Alcatel-Lucent
220 Hayden Road
Groton, MA 01450
US
Email: Donald.Fedyk@alcatel-lucent.com
7. References
7.1. Normative References 6.1. Normative References
[IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System [IS-IS] ISO/IEC 10589, "Intermediate System to Intermediate System
Intra-Domain Routing Exchange Protocol for use in Intra-Domain Routing Exchange Protocol for use in
Conjunction with the Protocol for Providing the Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2005. Connectionless-mode Network Service (ISO 8473)", 2005.
[RFC 1195] [RFC 1195]
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990. Dual Environments", 1990.
skipping to change at page 55, line 5 skipping to change at page 58, line 31
Router Information", 2007. Router Information", 2007.
[RFC 5305] [RFC 5305]
Li, T. and H. Smit, "IS-IS Extensions for Traffic Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", 2008. Engineering", 2008.
[RFC 5306] [RFC 5306]
Shand, M. and L. Ginsberg, "Restart Signaling for Shand, M. and L. Ginsberg, "Restart Signaling for
Intermediate System to Intermediate System (IS-IS)", 2004. Intermediate System to Intermediate System (IS-IS)", 2004.
7.2. Informative References 6.2. Informative References
[IEEE 802.1aq] [IEEE 802.1aq]
"Standard for Local and Metropolitan Area Networks / "Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment 9: Virtual Bridged Local Area Networks / Amendment 9:
Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008. Shortest Path Bridging, Draft IEEE P802.1aq/D1.5", 2008.
[OTV] Grover, H., Farinacci, D., and D. Rao, "OTV: Overlay
Transport Virtualization", draft-hasmit-otv-00, 2010.
[RBRIDGES] [RBRIDGES]
Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
Ghanwani, "RBridges: Base Protocol Specification", 2010. Ghanwani, "RBridges: Base Protocol Specification", 2010.
[RFC 1584] [RFC 1584]
Moy, J., "Multicast Extensions to OSPF", March 1994. Moy, J., "Multicast Extensions to OSPF", March 1994.
Author's Address Authors' Addresses
Ayan Banerjee (editor) Ayan Banerjee (editor)
Cisco Systems Cisco Systems
170 W Tasman Drive 170 W Tasman Drive
San Jose, CA 95138 San Jose, CA 95138
US US
Email: ayabaner@cisco.com Email: ayabaner@cisco.com
David Ward
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089-1206
USA
Phone: +1-408-745-2000
Email: dward@juniper.net
Russ White
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: riw@cisco.com
Dino Farinacci
Cisco Systems
170 W Tasman Drive
San Jose, CA 95138
US
Email: dino@cisco.com
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054
US
Phone: +1-408-765-8080
Email: Radia.Perlman@alum.mit.edu
Donald E. Eastlake 3rd
Stellar Switches
155 Beaver Street
Milford, MA 07157
US
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
Peter Ashwood-Smith
Huawei Technologies Canada Co. Ltd.
411 Legget Drive, Suite 503
Kanta, Ontario K2K 3C9
CANADA
Email: Peter.AshwoodSmith@huawei.com
Don Fedyk
Alcatel-Lucent
220 Hayden Road
Groton, MA 01450
US
Email: Donald.Fedyk@alcatel-lucent.com
 End of changes. 140 change blocks. 
411 lines changed or deleted 440 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/