draft-ietf-isis-rfc6326bis-03.txt   rfc7176.txt 
Network Working Group Donald Eastlake Internet Engineering Task Force (IETF) D. Eastlake 3rd
INTERNET-DRAFT Huawei Request for Comments: 7176 Huawei
Intended status: Proposed Standard Tissa Senevirathne Obsoletes: 6326 T. Senevirathne
Obsoletes: 6326 Cisco Category: Standards Track Cisco
Anoop Ghanwani ISSN: 2070-1721 A. Ghanwani
Dell Dell
Dinesh Dutt D. Dutt
Cumulus Networks Cumulus Networks
Ayan Banerjee A. Banerjee
Insieme Networks Insieme Networks
Expires: July 23, 2014 January 24, 2014 May 2014
Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS
<draft-ietf-isis-rfc6326bis-03.txt>
Abstract Abstract
The IETF TRILL (Transparent Interconnection of Lots of Links) The IETF Transparent Interconnection of Lots of Links (TRILL)
protocol provides optimal pair-wise data frame forwarding without protocol provides optimal pair-wise data frame forwarding without
configuration in multi-hop networks with arbitrary topology and link configuration in multi-hop networks with arbitrary topology and link
technology, and support for multipathing of both unicast and technology; it also provides support for multipathing of both unicast
multicast traffic. This document specifies the data formats and code and multicast traffic. This document specifies the data formats and
points for the IS-IS extensions to support TRILL. These data formats code points for the IS-IS extensions to support TRILL. These data
and code points may also be used by technologies other than TRILL. formats and code points may also be used by technologies other than
This document obsoletes RFC 6326. TRILL. This document obsoletes RFC 6326.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent This document is a product of the Internet Engineering Task Force
to the TRILL working group mailing list. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are working documents of the Internet Engineering Information about the current status of this document, any errata,
Task Force (IETF), its areas, and its working groups. Note that and how to provide feedback on it may be obtained at
other groups may also distribute working documents as Internet- http://www.rfc-editor.org/info/rfc7176.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright (c) 2014 IETF Trust and the persons identified as the
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft document authors. All rights reserved.
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
INTERNET-DRAFT TRILL Use of IS-IS This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction............................................3 1. Introduction ....................................................3
1.1 Conventions Used in This Document....................3 1.1. Conventions Used in This Document ..........................4
2. TLV and Sub-TLV Extensions to IS-IS for TRILL..........5 2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................4
2.1 Group Address TLV....................................5 2.1. Group Address TLV ..........................................5
2.1.1 Group MAC Address Sub-TLV..........................5 2.1.1. Group MAC Address Sub-TLV ...........................5
2.1.2 Group IPv4 Address Sub-TLV.........................7 2.1.2. Group IPv4 Address Sub-TLV ..........................7
2.1.3 Group IPv6 Address Sub-TLV.........................8 2.1.3. Group IPv6 Address Sub-TLV ..........................8
2.1.4 Group Labeled MAC Address Sub-TLV..................8 2.1.4. Group Labeled MAC Address Sub-TLV ...................9
2.1.5 Group Labeled IPv4 Address Sub-TLV................10 2.1.5. Group Labeled IPv4 Address Sub-TLV .................10
2.1.6 Group Labeled IPv6 Address Sub-TLV................11 2.1.6. Group Labeled IPv6 Address Sub-TLV .................11
2.2 Multi-Topology-Aware Port Capability Sub-TLVs.......11 2.2. Multi-Topology-Aware Port Capability Sub-TLVs .............12
2.2.1 Special VLANs and Flags Sub-TLV...................12 2.2.1. Special VLANs and Flags Sub-TLV ....................12
2.2.2 Enabled-VLANs Sub-TLV.............................13 2.2.2. Enabled-VLANs Sub-TLV ..............................13
2.2.3 Appointed Forwarders Sub-TLV......................14 2.2.3. Appointed Forwarders Sub-TLV .......................14
2.2.4 Port TRILL Version Sub-TLV........................15 2.2.4. Port TRILL Version Sub-TLV .........................15
2.2.5 VLANs Appointed Sub-TLV...........................16 2.2.5. VLANs Appointed Sub-TLV ............................17
2.3 Sub-TLVs of the Router and MT Capability TLVs.......17 2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs ..17
2.3.1 TRILL Version Sub-TLV.............................17 2.3.1. TRILL Version Sub-TLV ..............................18
2.3.2 Nickname Sub-TLV..................................18 2.3.2. Nickname Sub-TLV ...................................19
2.3.3 Trees Sub-TLV.....................................19 2.3.3. Trees Sub-TLV ......................................20
2.3.4 Tree Identifiers Sub-TLV..........................20 2.3.4. Tree Identifiers Sub-TLV ...........................20
2.3.5 Trees Used Identifiers Sub-TLV....................21 2.3.5. Trees Used Identifiers Sub-TLV .....................21
2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV..21 2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...22
2.3.7 VLAN Group Sub-TLV................................24 2.3.7. VLAN Group Sub-TLV .................................24
2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV.24 2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ..25
2.3.9 RBridge Channel Protocols Sub-TLV.................26 2.3.9. RBridge Channel Protocols Sub-TLV ..................27
2.3.10 Affinity Sub-TLV.................................28 2.3.10. Affinity Sub-TLV ..................................29
2.3.11 Label Group Sub-TLV..............................30 2.3.11. Label Group Sub-TLV ...............................30
2.4 MTU Sub-TLV for Ext. Reachability and MT ISN TLVs...30 2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs .....31
2.5 TRILL Neighbor TLV..................................31 2.5. TRILL Neighbor TLV ........................................31
3. MTU PDUs...............................................34 3. MTU PDUs .......................................................33
4. Use of Existing PDUs and TLVs..........................35 4. Use of Existing PDUs and TLVs ..................................35
4.1 TRILL IIH PDUs......................................35 4.1. TRILL IIH PDUs ............................................35
4.2 Area Address........................................35 4.2. Area Address ..............................................35
4.3 Protocols Supported.................................35 4.3. Protocols Supported .......................................35
4.4 Link State PDUs (LSPs)..............................36 4.4. Link State PDUs (LSPs) ....................................35
4.5 Originating LSP Buffer Size.........................36 4.5. Originating LSP Buffer Size ...............................36
5. IANA Considerations....................................37 5. IANA Considerations ............................................36
5.1 TLVs................................................37 5.1. TLVs ......................................................36
5.2 sub-TLVs............................................37 5.2. Sub-TLVs ..................................................36
5.3 PDUs................................................39 5.3. PDUs ......................................................38
5.4 Reserved and Capability Bits........................39 5.4. Reserved and Capability Bits ..............................38
5.5 TRILL Neighbor Record Flags.........................40 5.5. TRILL Neighbor Record Flags ...............................39
6. Security Considerations................................41 6. Security Considerations ........................................39
7. Change from RFC 6326...................................42 7. Changes from RFC 6326 ..........................................39
8. Normative References...................................44 8. References .....................................................41
9. Informative References.................................45 8.1. Normative References ......................................41
Acknowledgements..........................................47 8.2. Informative References ....................................43
Authors' Addresses........................................48 9. Acknowledgements ...............................................44
INTERNET-DRAFT TRILL Use of IS-IS
1. Introduction 1. Introduction
The IETF TRILL (Transparent Interconnection of Lots of Links) The IETF Transparent Interconnection of Lots of Links (TRILL)
protocol [RFC6325] [RFC6327] provides transparent forwarding in protocol [RFC6325] [RFC7177] provides transparent forwarding in
multi-hop networks with arbitrary topology and link technologies multi-hop networks with arbitrary topology and link technologies
using a header with a hop count and link state routing. TRILL using a header with a hop count and link-state routing. TRILL
provides optimal pair-wise forwarding without configuration, safe provides optimal pair-wise forwarding without configuration, safe
forwarding even during periods of temporary loops, and support for forwarding even during periods of temporary loops, and support for
multipathing of both unicast and multicast traffic. Intermediate multipathing of both unicast and multicast traffic. Intermediate
Systems (ISs) implementing TRILL are called RBridges (Routing Systems (ISs) implementing TRILL are called Routing Bridges
Bridges) or TRILL Switches. (RBridges) or TRILL Switches.
This document, in conjunction with [RFC6165], specifies the data This document, in conjunction with [RFC6165], specifies the data
formats and code points for the IS-IS [ISO-10589] [RFC1195] formats and code points for the IS-IS [ISO-10589] [RFC1195]
extensions to support TRILL. These data formats and code points may extensions to support TRILL. These data formats and code points may
also be used by technologies other than TRILL. also be used by technologies other than TRILL.
This document obsoletes [RFC6326], which generally corresponded to This document obsoletes [RFC6326], which generally corresponded to
the base TRILL protocol as the TRILL Working Group passed it up to the base TRILL protocol [RFC6325]. There has been substantial
the IESG in 2009. There has been substantial development of TRILL development of TRILL since the publication of those documents. The
since them. The main changes from [RFC6326] are summarized below and main changes from [RFC6326] are summarized below, and a full list is
a full list is given in Section 7. given in Section 7.
1. Addition of multicast group announcements by IPv4 and IPv6 1. Added multicast group announcements by IPv4 and IPv6 address.
address.
2. Addition of facilities for announcing capabilities supported. 2. Added facilities for announcing capabilities supported.
3. Addition of a tree affinity sub-TLV whereby ISs can request 3. Added a tree affinity sub-TLV whereby ISs can request
distribution tree association. distribution tree association.
4. Addition of multi-topology support. 4. Added multi-topology support.
5. Addition of control plane support for TRILL Data frame fine- 5. Added control-plane support for TRILL Data frame fine-grained
grained labels. This support is independent of the data plane labels. This support is independent of the data-plane
representation. representation.
6. Fix the reported errata [Err2869] in [RFC6326]. 6. Fixed the verified erratum [Err2869] in [RFC6326].
Changes herein to TLVs and sub-TLVs specified in [RFC6326] are Changes herein to TLVs and sub-TLVs specified in [RFC6326] are
backwards compatible. backward compatible.
1.1 Conventions Used in This Document 1.1. Conventions Used in This Document
The terminology and acronyms defined in [RFC6325] are used herein The terminology and acronyms defined in [RFC6325] are used herein
with the same meaning. with the same meaning.
Additional acronyms and phrases used in this document are: Additional acronyms and phrases used in this document are:
INTERNET-DRAFT TRILL Use of IS-IS BVL - Bit Vector Length
BVL - Bit Vector Length BVO - Bit Vector Offset
BVO - Bit Vector Offset IIH - IS-IS Hello
IIH - IS-IS Hello IS - Intermediate System. For this document, all relevant
intermediate systems are RBridges [RFC6325].
IS - Intermediate System. For this document, all relevant MAC - Media Access Control
intermediate systems are RBridges [RFC6325].
NLPID - Network Layer Protocol Identifier MT - Multi-Topology
SNPA - SubNetwork Point of Attachment (MAC Address) NLPID - Network Layer Protocol Identifier
SNPA - Subnetwork Point of Attachment (MAC Address)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
INTERNET-DRAFT TRILL Use of IS-IS
2. TLV and Sub-TLV Extensions to IS-IS for TRILL 2. TLV and Sub-TLV Extensions to IS-IS for TRILL
This section, in conjunction with [RFC6165], specifies the data This section, in conjunction with [RFC6165], specifies the data
formats and code points for the TLVs and sub-TLVs for IS-IS to formats and code points for the TLVs and sub-TLVs for IS-IS to
support the IETF TRILL protocol. Information as to the number of support the IETF TRILL protocol. Information as to the number of
occurrences allowed, such as for a TLV in a PDU or set of PDUs or for occurrences allowed, such as for a TLV in a PDU or set of PDUs or for
a sub-TLV in a TLV, is summarized in Section 5. a sub-TLV in a TLV, is summarized in Section 5.
2.1 Group Address TLV 2.1. Group Address TLV
The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an
LSP PDU and carries sub-TLVs that in turn advertise multicast group LSP PDU and carries sub-TLVs that in turn advertise multicast group
listeners. The sub-TLVs that advertises listeners are specified listeners. The sub-TLVs that advertise listeners are specified
below. The sub-TLVs under GADDR constitute a new series of sub-TLV below. The sub-TLVs under GADDR constitute a new series of sub-TLV
types (see Section 5.2). types (see Section 5.2).
GADDR has the following format: GADDR has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=GADDR-TLV | (1 byte) |Type=GADDR-TLV | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| sub-TLVs... | sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-+-+-+-+-+-+-...
o Type: TLV Type, set to GADDR-TLV 142. o Type: TLV type, set to GADDR-TLV 142.
o Length: variable depending on the sub-TLVs carried. o Length: variable depending on the sub-TLVs carried.
o sub-TLVs: The Group Address TLV value consists of sub-TLVs o sub-TLVs: The Group Address TLV value consists of sub-TLVs
formatted as described in [RFC5305]. formatted as described in [RFC5305].
2.1.1 Group MAC Address Sub-TLV 2.1.1. Group MAC Address Sub-TLV
The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1 The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1
within the GADDR TLV. In TRILL, it is used to advertise multicast within the GADDR TLV. In TRILL, it is used to advertise multicast
listeners by MAC address as specified in Section 4.5.5 of [RFC6325]. listeners by MAC address as specified in Section 4.5.5 of [RFC6325].
It has the following format: It has the following format:
INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+
|Type=GMAC-ADDR | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=GMAC-ADDR | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (1 byte) | RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes) | RESV | VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | VLAN ID | (2 bytes) |Num Group Recs | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) | GROUP RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (1) | | GROUP RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (2) | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each group record is of the following form with k=6: where each group record is of the following form with k=6:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Num of Sources| (1 byte) | Num of Sources| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (k bytes) | | Group Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) | | Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) | | Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... | | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) | | Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR). o Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).
o Length: 5 + m + k*n = 5 + m + 6*n where m is the number of group o Length: 5 + m + k*n = 5 + m + 6*n, where m is the number of group
records and n is the sum of the number of group and source records and n is the sum of the number of group and source
addresses. addresses.
o RESV: Reserved. 4-bit fields that MUST be sent as zero and o RESV: Reserved. 4-bit fields that MUST be sent as zero and
ignored on receipt. ignored on receipt.
o Topology-ID: This field carries a topology ID [RFC5120] or zero if o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use. topologies are not in use.
o VLAN ID: This carries the 12-bit VLAN identifier for all o VLAN ID: This carries the 12-bit VLAN identifier for all
subsequent MAC addresses in this sub-TLV, or the value zero if no subsequent MAC addresses in this sub-TLV, or the value zero if no
INTERNET-DRAFT TRILL Use of IS-IS
VLAN is specified. VLAN is specified.
o Number of Group Records: A 1-byte unsigned integer that is the o Num Group Recs: A 1-byte unsigned integer that is the number of
number of group records in this sub-TLV. group records in this sub-TLV.
o Group Record: Each group record carries the number of sources. If o GROUP RECORDS: Each group record carries the number of sources.
this field is zero, it indicates a listener for (*,G), that is, a If this field is zero, it indicates a listener for (*,G), that is,
listener not restricted by source. It then has a 6-byte (48-bit) a listener not restricted by source. It then has a 6-byte
multicast MAC address followed by 6-byte source MAC addresses. If (48-bit) multicast MAC address followed by 6-byte source MAC
the sources do not fit in a single sub-TLV, the same group address addresses. If the sources do not fit in a single sub-TLV, the
may be repeated with different source addresses in another sub-TLV same group address may be repeated with different source addresses
of another instance of the Group Address TLV. in another sub-TLV of another instance of the Group Address TLV.
The GMAC-ADDR sub-TLV is carried only within a GADDR TLV. The GMAC-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.2 Group IPv4 Address Sub-TLV 2.1.2. Group IPv4 Address Sub-TLV
The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type TBDa The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2
[2 suggested] within the GADDR TLV. It has the same format as the within the GADDR TLV. It has the same format as the Group MAC
Group MAC Address sub-TLV described in Section 2.1.1 except that k=4. Address sub-TLV described in Section 2.1.1 except that k=4. The
The fields are as follows: fields are as follows:
o Type: sub-TLV Type, set to TBDa [2 suggested] (GIP-ADDR). o Type: sub-TLV type, set to 2 (GIP-ADDR).
o Length: 5 + m + k*n = 5 + m + 4*n where m is the number of group o Length: 5 + m + k*n = 5 + m + 4*n, where m is the number of group
records and n is the sum of the number of group and source records and n is the sum of the number of group and source
addresses. addresses.
o Topology-Id: This field carries a topology ID [RFC5120] or zero if o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use. topologies are not in use.
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 addresses in this sub-TLV, or the value zero if no all subsequent addresses in this sub-TLV, or the value zero if no
VLAN is specified. VLAN is specified.
o Number of Group Records: This is of length 1 byte and lists the o Num Group Recs: A 1-byte unsigned integer that is the number of
number of group records in this sub-TLV. group records in this sub-TLV.
o Group Record: Each group record carries the number of sources. If
this field is zero, it indicates a listener for (*,G), that is, a
listener not restricted by source. It then has a 4-byte (32-bit)
IPv4 Group Address followed by 4-byte source IPv4 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 different
source addresses in another sub-TLV of another instance of the
INTERNET-DRAFT TRILL Use of IS-IS
Group Address TLV. o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 4-byte
(32-bit) IPv4 Group Address followed by 4-byte source IPv4
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
different source addresses in another sub-TLV of another instance
of the Group Address TLV.
The GIP-ADDR sub-TLV is carried only within a GADDR TLV. The GIP-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.3 Group IPv6 Address Sub-TLV 2.1.3. Group IPv6 Address Sub-TLV
The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3
TBDb [3 suggested] within the GADDR TLV. It has the same format as within the GADDR TLV. It has the same format as the Group MAC
the Group MAC Address sub-TLV described in Section 2.1.1 except that Address sub-TLV described in Section 2.1.1 except that k=16. The
k=16. The fields are as follows: fields are as follows:
o Type: sub-TLV Type, set to TBDb [3 suggested] (GIPV6-ADDR). o Type: sub-TLV type, set to 3 (GIPV6-ADDR).
o Length: 5 + m + k*n = 5 + m + 16*n where m is the number of group o Length: 5 + m + k*n = 5 + m + 16*n, where m is the number of group
records and n is the sum of the number of group and source records and n is the sum of the number of group and source
addresses. addresses.
o Topology-Id: This field carries a topology ID [RFC5120] or zero if o Topology-Id: This field carries a topology ID [RFC5120] or zero if
topologies are not in use. topologies are not in use.
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 addresses in this sub-TLV, or the value zero if no all subsequent addresses in this sub-TLV, or the value zero if no
VLAN is specified. VLAN is specified.
o Number of Group Records: This is of length 1 byte and lists the o Num Group Recs: A 1-byte unsigned integer that is the number of
number of group records in this sub-TLV. group records in this sub-TLV.
o Group Record: Each group record carries the number of sources. If o GROUP RECORDS: Each group record carries the number of sources.
this field is zero, it indicates a listener for (*,G), that is, a If this field is zero, it indicates a listener for (*,G), that is,
listener not restricted by source. It then has a 16-byte (128-bit) a listener not restricted by source. It then has a 16-byte
IPv6 Group Address followed by 16-byte source IPv6 addresses. If (128-bit) IPv6 Group Address followed by 16-byte source IPv6
the number of sources do not fit in a single sub-TLV, it is addresses. If the number of sources do not fit in a single sub-
permitted to have the same group address repeated with different TLV, it is permitted to have the same group address repeated with
source addresses in another sub-TLV of another instance of the different source addresses in another sub-TLV of another instance
Group Address TLV. of the Group Address TLV.
The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV. The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.4 Group Labeled MAC Address Sub-TLV 2.1.4. Group Labeled MAC Address Sub-TLV
The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in
Section 2.1.1 provides for a VLAN-ID. The Group Labeled MAC Address Section 2.1.1 provides for a VLAN ID. The Group Labeled MAC Address
sub-TLV, below, extends this to a fine-grained label. sub-TLV, below, extends this to a fine-grained label.
INTERNET-DRAFT TRILL Use of IS-IS
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=GLMAC-ADDR| (1 byte) |Type=GLMAC-ADDR| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology-ID | (2 bytes) | RESV | Topology-ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fine-Grained Label | (3 bytes) | Fine-Grained Label | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Num Group Recs | (1 byte) |Num Group Recs | (1 byte)
skipping to change at page 9, line 43 skipping to change at page 9, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 1 Address (k bytes) | | Source 1 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source 2 Address (k bytes) | | Source 2 Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..... | | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source M Address (k bytes) | | Source M Address (k bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: GADDR sub-TLV Type, set to TBDc [4 suggested] (GLMAC-ADDR). o Type: GADDR sub-TLV type, set to 4 (GLMAC-ADDR).
o Length: 6 + m + k*n = 6 + m + 6*n where m is the number of group o Length: 6 + m + k*n = 6 + m + 6*n, where m is the number of group
records and n is the sum of the number of group and source records and n is the sum of the number of group and source
addresses. addresses.
o RESV: Reserved. 4-bit field that MUST be sent as zero and ignored o RESV: Reserved. 4-bit field that MUST be sent as zero and ignored
on receipt. on receipt.
o Topology-ID: This field carries a topology ID [RFC5120] or zero if o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use. topologies are not in use.
o Label: This carries the fine-grained label [RFCfgl] identifier for o Label: This carries the fine-grained label [RFC7172] identifier
all subsequent MAC addresses in this sub-TLV, or the value zero if for all subsequent MAC addresses in this sub-TLV, or the value
zero if no label is specified.
INTERNET-DRAFT TRILL Use of IS-IS
no label is specified.
o Number of Group Records: A 1-byte unsigned integer that is the o Num Group Recs: A 1-byte unsigned integer that is the number of
number of group records in this sub-TLV. group records in this sub-TLV.
o Group Record: Each group record carries the number of sources. If o GROUP RECORDS: Each group record carries the number of sources.
this field is zero, it indicates a listener for (*,G), that is, a If this field is zero, it indicates a listener for (*,G), that is,
listener not restricted by source. It then has a 6-byte (48-bit) a listener not restricted by source. It then has a 6-byte
multicast address followed by 6-byte source MAC addresses. If the (48-bit) multicast address followed by 6-byte source MAC
sources do not fit in a single sub-TLV, the same group address may addresses. If the sources do not fit in a single sub-TLV, the
be repeated with different source addresses in another sub-TLV of same group address may be repeated with different source addresses
another instance of the Group Address TLV. in another sub-TLV of another instance of the Group Address TLV.
The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV. The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.5 Group Labeled IPv4 Address Sub-TLV 2.1.5. Group Labeled IPv4 Address Sub-TLV
The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV
type TBDd [5 suggested] within the GADDR TLV. It has the same format type 5 within the GADDR TLV. It has the same format as the Group
as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 Labeled MAC Address sub-TLV described in Section 2.1.4 except that
except that k=4. The fields are as follows: k=4. The fields are as follows:
o Type: sub-TLV Type, set to TBDd [5 suggested] (GLIP-ADDR). o Type: sub-TLV type, set to 5 (GLIP-ADDR).
o Length: 6 + m + k*n = 6 + m + 4*n where m is the number of group o Length: 6 + m + k*n = 6 + m + 4*n, where m is the number of group
records and n is the sum of the number of group and source records and n is the sum of the number of group and source
addresses. addresses.
o Topology-Id: This field carries a topology ID [RFC5120] or zero if o Topology-ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use. topologies are not in use.
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 Label: This carries the fine-grained label [RFCfgl] identifier for o Label: This carries the fine-grained label [RFC7172] identifier
all subsequent IPv4 addresses in this sub-TLV, or the value zero for all subsequent IPv4 addresses in this sub-TLV, or the value
if no label is specified. zero if no label is specified.
o Number of Group Records: This is of length 1 byte and lists the
number of group records in this sub-TLV.
o Group Record: Each group record carries the number of sources. If
this field is zero, it indicates a listener for (*,G), that is, a
listener not restricted by source. It then has a 4-byte (32-bit)
IPv4 Group Address followed by 4-byte source IPv4 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 different
source addresses in another sub-TLV of another instance of the
INTERNET-DRAFT TRILL Use of IS-IS o Num Group Recs: A 1-byte unsigned integer that is the number of
group records in this sub-TLV.
Group Address TLV. o GROUP RECORDS: Each group record carries the number of sources.
If this field is zero, it indicates a listener for (*,G), that is,
a listener not restricted by source. It then has a 4-byte
(32-bit) IPv4 Group Address followed by 4-byte source IPv4
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
different source addresses in another sub-TLV of another instance
of the Group Address TLV.
The GLIP-ADDR sub-TLV is carried only within a GADDR TLV. The GLIP-ADDR sub-TLV is carried only within a GADDR TLV.
2.1.6 Group Labeled IPv6 Address Sub-TLV 2.1.6. Group Labeled IPv6 Address Sub-TLV
The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV
type TBDe [6 suggested] within the GADDR TLV. It has the same format type 6 within the GADDR TLV. It has the same format as the Group
as the Group Labeled MAC Address sub-TLV described in Section 2.1.4 Labeled MAC Address sub-TLV described in Section 2.1.4 except that
except that k=16. The fields are as follows: k=16. The fields are as follows:
o Type: sub-TLV Type, set to TBDe [6 suggested] (GLIPV6-ADDR). o Type: sub-TLV type, set to 6 (GLIPV6-ADDR).
o Length: 6 + m + k*n = 6 + m + 16*n where m is the number of group o Length: 6 + m + k*n = 6 + m + 16*n, where m is the number of group
records and n is the sum of the number of group and source records and n is the sum of the number of group and source
addresses. addresses.
o Topology-Id: This field carries a topology ID [RFC5120] or zero if o Topology-Id: This field carries a topology ID [RFC5120] or zero if
topologies are not in use. topologies are not in use.
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 Label: This carries the fine-grained label [RFCfgl] identifier for o Label: This carries the fine-grained label [RFC7172] identifier
all subsequent IPv6 addresses in this sub-TLV, or the value zero for all subsequent IPv6 addresses in this sub-TLV, or the value
if no label is specified. zero if no label is specified.
o Number of Group Records: This of length 1 byte and lists the o Num Group Recs: A 1-byte unsigned integer that is the number of
number of group records in this sub-TLV. group records in this sub-TLV.
o Group Record: Each group record carries the number of sources. If o GROUP RECORDS: Each group record carries the number of sources.
this field is zero, it indicates a listener for (*,G), that is, a If this field is zero, it indicates a listener for (*,G), that is,
listener not restricted by source. It then has a 16-byte (128-bit) a listener not restricted by source. It then has a 16-byte
IPv6 Group Address followed by 16-byte source IPv6 addresses. If (128-bit) IPv6 Group Address followed by 16-byte source IPv6
the number of sources do not fit in a single sub-TLV, it is addresses. If the number of sources do not fit in a single sub-
permitted to have the same group address repeated with different TLV, it is permitted to have the same group address repeated with
source addresses in another sub-TLV of another instance of the different source addresses in another sub-TLV of another instance
Group Address TLV. of the Group Address TLV.
The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV. The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV.
2.2 Multi-Topology-Aware Port Capability Sub-TLVs 2.2. Multi-Topology-Aware Port Capability Sub-TLVs
TRILL makes use of the Multi-Topology-Aware Port Capability (MT-PORT-
CAP) TLV as specified in [RFC6165]. The following subsections of
INTERNET-DRAFT TRILL Use of IS-IS
this Section 2.2 specify the sub-TLVs transported by the MT-PORT-CAP TRILL makes use of the Multi-Topology-Aware Port Capability TLV (MT-
TLV for TRILL. Port-Cap-TLV) as specified in [RFC6165]. The following subsections
specify the sub-TLVs transported by the MT-Port-Cap-TLV for TRILL.
2.2.1 Special VLANs and Flags Sub-TLV 2.2.1. Special VLANs and Flags Sub-TLV
In TRILL, a Special VLANs and Flags (VLAN-Flags) sub-TLV is carried In TRILL, a Special VLANs and Flags (VLAN-FLAGS) sub-TLV is carried
in every IIH PDU. It has the following format: in every IIH PDU. It has the following format:
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
| Type | (1 byte) | Type | (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)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|TR|R |R |R | Designated-VLAN | (2 bytes) |TR|R |R |R | Designated-VLAN | (2 bytes)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
o Type: sub-TLV type, set to MT-PORT-CAP VLAN-FLAGs sub-TLV 1.
o Length: 8. o Type: sub-TLV type, set to MT-Port-Cap-TLV VLAN-FLAGS sub-TLV 1.
o Port ID: An ID for the port on which the enclosing TRILL IIH o Length: 8.
PDU is being sent as specified in [RFC6325], Section 4.4.2.
o Sender Nickname: If the sending IS is holding any nicknames as o Port ID: An ID for the port on which the enclosing TRILL IIH PDU
discussed in [RFC6325], Section 3.7, one MUST be included here. is being sent as specified in [RFC6325], Section 4.4.2.
Otherwise, the field is set to zero. This field is to support
intelligent end stations that determine the egress IS (RBridge)
for unicast data through a directory service or the like and
that need a nickname for their first hop to insert as the
ingress nickname to correctly format a TRILL Data frame (see
[RFC6325], Section 4.6.2, point 8). It is also referenced in
connection with the VLANs Appointed Sub-TLV (see Section 2.2.5)
and can be used as the egress on one-hop RBridge Channel
messages [Channel], for example those use for BFD over TRILL
[RFCtrillBFD].
o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH o Sender Nickname: If the sending IS is holding any nicknames as
frame containing this sub-TLV, as specified in [RFC6325], discussed in [RFC6325], Section 3.7, one MUST be included here.
Section 4.4.5. Otherwise, the field is set to zero. This field is to support
intelligent end stations that determine the egress IS (RBridge)
for unicast data through a directory service or the like and that
need a nickname for their first hop to insert as the ingress
nickname to correctly format a TRILL Data frame (see [RFC6325],
Section 4.6.2, point 8). It is also referenced in connection with
the VLANs Appointed Sub-TLV (see Section 2.2.5) and can be used as
the egress on one-hop RBridge Channel messages [RFC7178], for
example, those use for BFD over TRILL [RFC7175].
o Designated-VLAN: The 12-bit ID of the Designated VLAN for the o Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH
link, as specified in [RFC6325], Section 4.2.4.2. frame containing this sub-TLV, as specified in [RFC6325], Section
4.4.5.
INTERNET-DRAFT TRILL Use of IS-IS o Designated-VLAN: The 12-bit ID of the Designated VLAN for the
link, as specified in [RFC6325], Section 4.2.4.2.
o AF, AC, VM, BY, and TR: These flag bits have the following o AF, AC, VM, BY, and TR: These flag bits have the following
meanings when set to one, as specified in the listed section of meanings when set to one, as specified in the listed section of
[RFC6325]: [RFC6325]:
RFC 6325 RFC 6325
Bit Section Meaning if bit is one Bit Section Meaning if bit is one
-------------------------------------- --------------------------------------
AF 4.4.2 Originating IS believes it is appointed AF 4.4.2 Originating IS believes it is Appointed
forwarder for the VLAN and port on which the Forwarder for the VLAN and port on which the
containing IIH PDU was sent. containing IIH PDU was sent.
AC 4.9.1 Originating port configured as an access port AC 4.9.1 Originating port configured as an access port
(TRILL traffic disabled). (TRILL traffic disabled).
VM 4.4.5 VLAN mapping detected on this link. VM 4.4.5 VLAN mapping detected on this link.
BY 4.4.2 Bypass pseudonode. BY 4.4.2 Bypass pseudonode.
TR 4.9.1 Originating port configured as a trunk port TR 4.9.1 Originating port configured as a trunk port
(end-station service disabled). (end-station service disabled).
o R: Reserved bit. MUST be sent as zero and ignored on receipt. o R: Reserved bit. MUST be sent as zero and ignored on receipt.
2.2.2 Enabled-VLANs Sub-TLV 2.2.2. Enabled-VLANs Sub-TLV
The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the
port of the originating IS on which the containing Hello was sent, as port of the originating IS on which the containing Hello was sent, as
specified in [RFC6325], Section 4.4.2. It has the following format: specified in [RFC6325], Section 4.4.2. It has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | (1 byte) | Type | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes) | RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map.... | VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-PORT-CAP Enabled-VLANs sub-TLV 2. o Type: sub-TLV type, set to MT-Port-Cap-TLV Enabled-VLANs sub-TLV
2.
o Length: Variable, minimum 3. o Length: Variable, minimum 3.
o RESV: 4 reserved bits that MUST be sent as zero and ignored on o RESV: 4 reserved bits that MUST be sent as zero and ignored on
receipt. receipt.
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high o Start VLAN ID: The 12-bit VLAN ID that is represented by the high-
INTERNET-DRAFT TRILL Use of IS-IS
order bit of the first byte of the VLAN bit-map. order bit of the first byte of the VLAN bit-map.
o VLAN bit-map: The highest order bit indicates the VLAN equal to o VLAN bit-map: The highest-order bit indicates the VLAN equal to
the start VLAN ID, the next highest bit indicates the VLAN equal the start VLAN ID, the next highest bit indicates the VLAN equal
to start VLAN ID + 1, continuing to the end of the VLAN bit-map to start VLAN ID + 1, continuing to the end of the VLAN bit-map
field. field.
If this sub-TLV occurs more than once in a Hello, the set of enabled If this sub-TLV occurs more than once in a Hello, the set of enabled
VLANs is the union of the sets of VLANs indicated by each of the VLANs is the union of the sets of VLANs indicated by each of the
Enabled-VLAN sub-TLVs in the Hello. Enabled-VLAN sub-TLVs in the Hello.
2.2.3 Appointed Forwarders Sub-TLV 2.2.3. Appointed Forwarders Sub-TLV
The DRB on a link uses the Appointed Forwarders sub-TLV to inform The Designated RBridge (DRB) on a link uses the Appointed Forwarders
other ISs on the link that they are the designated VLAN-x forwarder sub-TLV to inform other ISs on the link that they are the designated
for one or more ranges of VLAN IDs as specified in [RFC6439]. It has VLAN-x forwarder for one or more ranges of VLAN IDs as specified in
the following format: [RFC6439]. It has the following format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | (1 byte) | Type | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (1) | (6 bytes) | Appointment Information (1) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (2) | (6 bytes) | Appointment Information (2) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointment Information (N) | (6 bytes) | Appointment Information (N) | (6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each appointment is of the form: where each appointment is of the form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Appointee Nickname | (2 bytes) | Appointee Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start.VLAN | (2 bytes) | RESV | Start.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | End.VLAN | (2 bytes) | RESV | End.VLAN | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-Port-Cap-TLV AppointedFwrdrs sub-TLV
o Type: sub-TLV type, set to MT-PORT-CAP AppointedFwrdrs sub-TLV 3. 3.
o Length: 6*n bytes, where there are n appointments. o Length: 6*n bytes, where there are n appointments.
o Appointee Nickname: The nickname of the IS being appointed a o Appointee Nickname: The nickname of the IS being appointed a
forwarder. forwarder.
INTERNET-DRAFT TRILL Use of IS-IS
o RESV: 4 bits that MUST be sent as zero and ignored on receipt. o RESV: 4 bits that MUST be sent as zero and ignored on receipt.
o Start.VLAN, End.VLAN: This VLAN ID range is inclusive. Setting o Start.VLAN, End.VLAN: This VLAN ID range is inclusive. Setting
both VLAN.start and VLAN.end to the same value indicates a range both Start.VLAN and VLAN.end to the same value indicates a range
of one VLAN ID. If VLAN.start is not equal to VLAN.end and of one VLAN ID. If Start.VLAN is not equal to VLAN.end and
VLAN.start is 0x000, the sub-TLV is interpreted as if VLAN.start Start.VLAN is 0x000, the sub-TLV is interpreted as if Start.VLAN
was 0x001. If VLAN.start is not equal to VLAN.end and VLAN.end is was 0x001. If Start.VLAN is not equal to VLAN.end and VLAN.end is
0xFFF, the sub-TVL is interpreted as if VLAN.end was 0xFFE. If 0xFFF, the sub-TLV is interpreted as if VLAN.end was 0xFFE. If
VLAN.end is less than VLAN.start, the sub-TLV is ignored. If both VLAN.end is less than Start.VLAN, the sub-TLV is ignored. If both
VLAN.start and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV Start.VLAN and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV
is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs and is ignored. The values 0x000 or 0xFFF are not valid VLAN IDs, and
a port cannot be enabled for them. a port cannot be enabled for them.
An IS's nickname may occur as appointed forwarder for multiple VLAN An IS's nickname may occur as Appointed Forwarder for multiple VLAN
ranges by occurrences of this sub-TLV within the same or different MT ranges by occurrences of this sub-TLV within the same or different MT
Port Capability TLVs within an IIH PDU. See [RFC6439]. Port Capability TLVs within an IIH PDU. See [RFC6439].
2.2.4 Port TRILL Version Sub-TLV 2.2.4. Port TRILL Version Sub-TLV
The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum
version of the TRILL standard supported and the support of optional version of the TRILL standard supported and the support of optional
hop-by-hop capabilities. By implication, lower versions are also hop-by-hop capabilities. By implication, lower versions are also
supported. If this sub-TLV is missing from an IIH, it is assumed that supported. If this sub-TLV is missing from an IIH, it is assumed
the originating IS only supports the base version (version zero) of that the originating IS only supports the base version (version zero)
the protocol [RFC6325] and supports no optional capabilities of the protocol [RFC6325] and supports no optional capabilities
indicated by this sub-TLV. indicated by this sub-TLV.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | (1 byte) | Type | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Max-version | (1 byte) | Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes) | Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3 0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
o Type: MT-PORT-CAP sub-TLV type, set to TBDf [7 suggested] (PORT- o Type: MT-Port-Cap-TLV sub-TLV type, set to 7 (PORT-TRILL-VER).
TRILL-VER).
o Length: 5. o Length: 5.
o Max-version: A one byte unsigned integer set to maximum version o Max-version: A one-byte unsigned integer set to the maximum
supported. version supported.
o Capabilities and Header Flags Supported: A bit vector of 32 bits o Capabilities and Header Flags Supported: A bit vector of 32 bits
numbered 0 through 31 in network order. Bits 3 through 13
INTERNET-DRAFT TRILL Use of IS-IS indicate that the corresponding TRILL Header hop-by-hop extended
flags [RFC7179] are supported. Bits 0 through 2 and 14 to 31 are
numbered 0 through 31 in network order. Bits 3 through 13 indicate reserved to indicate support of optional capabilities. A one bit
that the corresponding TRILL Header hop-by-hop extended flags
[ExtendHeader] are supported. Bits 0 through 2 and 14 to 31 are
reserved to indicate support of optional capabilities. A one bit
indicates that the flag or capability is supported by the sending indicates that the flag or capability is supported by the sending
IS. Bits in this field MUST be set to zero except as permitted for IS. Bits in this field MUST be set to zero except as permitted
a capability being advertised or if a hop-by-hop extended header for a capability being advertised or if a hop-by-hop extended
flag is supported. header flag is supported.
This sub-TLV, if present, MUST occur in an MT-PORT-CAP TLV in a TRILL This sub-TLV, if present, MUST occur in an MT-Port-Cap-TLV in a TRILL
IIH. If there is more than one occurrence, the minimum of the IIH. If there is more than one occurrence, the minimum of the
supported versions is assumed to be correct and a capability or supported versions is assumed to be correct and a capability or
header flag is assumed to be supported only if indicated by all header flag is assumed to be supported only if indicated by all
occurrences. The flags and capabilities for which support can be occurrences. The flags and capabilities for which support can be
indicated in this sub-TLV are disjoint from those in the TRILL-VER indicated in this sub-TLV are disjoint from those in the TRILL-VER
sub-TLV (Section 2.3.1) so they cannot conflict. The flags and sub-TLV (Section 2.3.1) so they cannot conflict. The flags and
capabilities indicated in this sub-TLV relate to hop-by-hop capabilities indicated in this sub-TLV relate to hop-by-hop
processing that can differ between the ports of an IS (RBridge), and processing that can differ between the ports of an IS (RBridge) and
thus must be advertised in IIHs. For example, a capability requiring thus must be advertised in IIHs. For example, a capability requiring
cryptographic hardware assist might be supported on some ports and cryptographic hardware assist might be supported on some ports and
not others. However, the TRILL version is the same as that in the not others. However, the TRILL version is the same as that in the
PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS of PORT-TRILL-VER sub-TLV. An IS, if it is adjacent to the sending IS
TRILL version sub-TLV(s) uses the TRILL version it received in PORT- of TRILL version sub-TLV(s), uses the TRILL version it received in
TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub- PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER
TLV(s). sub-TLV(s).
2.2.5 VLANs Appointed Sub-TLV 2.2.5. VLANs Appointed Sub-TLV
The optional VLANs sub-TLV specifies, for the port of the originating The optional VLANs Appointed sub-TLV specifies, for the port of the
IS on which the containing Hello was sent, the VLANs for which it is originating IS on which the containing Hello was sent, the VLANs for
appointed forwarder. This sub-TLV has the following format: which it is Appointed Forwarder. This sub-TLV has the following
format:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | (1 byte) | Type | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Start VLAN ID | (2 bytes) | RESV | Start VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN bit-map.... | VLAN bit-map....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV type, set to MT-PORT-CAP VLANS-Appointed sub-TLV o Type: sub-TLV type, set to MT-Port-Cap-TLV VLANS-Appointed sub-TLV
TBDg [8 suggested]. 8.
o Length: Variable, minimum 3. o Length: Variable, minimum 3.
o RESV: 4 reserved bits that MUST be sent as zero and ignored on o RESV: 4 reserved bits that MUST be sent as zero and ignored on
INTERNET-DRAFT TRILL Use of IS-IS
receipt. receipt.
o Start VLAN ID: The 12-bit VLAN ID that is represented by the high o Start VLAN ID: The 12-bit VLAN ID that is represented by the high-
order bit of the first byte of the VLAN bit-map. order bit of the first byte of the VLAN bit-map.
o VLAN bit-map: The highest order bit indicates the VLAN equal to o VLAN bit-map: The highest-order bit indicates the VLAN equal to
the start VLAN ID, the next highest bit indicates the VLAN equal the start VLAN ID, the next highest bit indicates the VLAN equal
to start VLAN ID + 1, continuing to the end of the VLAN bit-map to start VLAN ID + 1, continuing to the end of the VLAN bit-map
field. field.
If this sub-TLV occurs more than once in a Hello, the originating IS If this sub-TLV occurs more than once in a Hello, the originating IS
is declaring that it believes itself to be appointed forwarder on the is declaring that it believes itself to be Appointed Forwarder on the
port on which the enclosing IIH was sent for the union of the sets of port on which the enclosing IIH was sent for the union of the sets of
VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello. VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello.
2.3 Sub-TLVs of the Router and MT Capability TLVs 2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs
The Router Capability TLV is specified in [RFC4971] and the MT The Router Capability TLV is specified in [RFC4971] and the MT-
Capability TLV in [RFC6329]. All of the sub-sections of this Section Capability TLV in [RFC6329]. All of the following sub-sections
2.3 below specify sub-TLVs that can be carried in the Router specify sub-TLVs that can be carried in the Router Capability TLV
Capability TLV (#242) and the MT (multi-topology) Capability TLV (#242) and the MT-Capability TLV (#144) with the same sub-TLV number
(#144) with the same sub-TLV number for both TLVs. These TLVs are in for both TLVs. These TLVs are in turn carried only by LSPs.
turn carried only by LSPs.
2.3.1 TRILL Version Sub-TLV 2.3.1. TRILL Version Sub-TLV
The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version The TRILL Version (TRILL-VER) sub-TLV indicates the maximum version
of the TRILL standard supported and the support of optional of the TRILL standard supported and the support of optional
capabilities by the originating IS. By implication, lower versions capabilities by the originating IS. By implication, lower versions
are also supported. If this sub-TLV is missing, it is assumed that are also supported. If this sub-TLV is missing, it is assumed that
the originating IS only supports the base version (version zero) of the originating IS only supports the base version (version zero) of
the protocol [RFC6325] and no optional capabilities indicated by this the protocol [RFC6325], and no optional capabilities indicated by
sub-TLV are supported. this sub-TLV are supported.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | (1 byte) | Type | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Max-version | (1 byte) | Max-version | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
| Capabilities and Header Flags Supported | (4 bytes) | Capabilities and Header Flags Supported | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
0 1 3 0 1 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 0 1
INTERNET-DRAFT TRILL Use of IS-IS
o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER). o Type: Router Capability sub-TLV type, set to 13 (TRILL-VER).
o Length: 5. o Length: 5.
o Max-version: A one byte unsigned integer set to maximum version o Max-version: A one-byte unsigned integer set to the maximum
supported. version supported.
o Capabilities and Header Flags Supported: A bit vector of 32 bits o Capabilities and Header Flags Supported: A bit vector of 32 bits
numbered 0 through 31 in network order. Bits 14 through 31 numbered 0 through 31 in network order. Bits 14 through 31
indicate that the corresponding TRILL Header extended flags indicate that the corresponding TRILL Header extended flags
[ExtendHeader] are supported. Bits 0 through 13 are reserved to [RFC7179] are supported. Bits 0 through 13 are reserved to
indicate support of optional capabilities. A one bit indicates indicate support of optional capabilities. A one bit indicates
that the originating IS supports the flag or capability. For that the originating IS supports the flag or capability. For
example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in example, support of multi-level TRILL IS-IS [MultiLevel]. Bits in
this field MUST be set to zero except as permitted for a this field MUST be set to zero except as permitted for a
capability being advertised or an extended header flag supported. capability being advertised or an extended header flag supported.
This sub-TLV, if present in a Router Capabilities TLV, MUST occur in This sub-TLV, if present in a Router Capability TLV, MUST occur in
the LSP number zero for the originating IS. If found in a Router the LSP number zero for the originating IS. If found in a Router
Capabilities TLV in other fragments, it is ignored. If there is more Capability TLV in other fragments, it is ignored. If there is more
than one occurrence in LSP number zero, the minimum of the supported than one occurrence in LSP number zero, the minimum of the supported
versions is assumed to be correct and an extended header flag or versions is assumed to be correct, and an extended header flag or
capability is assumed to be supported only if indicated by all capability is assumed to be supported only if indicated by all
occurrences. The flags and capabilities supported bits in this sub- occurrences. The flags and capabilities for which support can be
TLV are disjoint from those in the PORT-TRILL-VER sub-TLV (Section indicated in this sub-TLV are disjoint from those in the PORT-TRILL-
2.2.4) so they cannot conflict. However, the TRILL version is the VER sub-TLV (Section 2.2.4) so they cannot conflict. However, the
same as that in the PORT-TRILL-VER sub-TLV and an IS that is adjacent TRILL version is the same as that in the PORT-TRILL-VER sub-TLV, and
to the originating IS of TRILL-VER sub-TLV(s) uses the TRILL version an IS that is adjacent to the originating IS of TRILL-VER sub-TLV(s)
it received in PORT-TRILL-VER sub-TLV(s) in preference to that uses the TRILL version it received in PORT-TRILL-VER sub-TLV(s) in
received in TRILL-VER sub-TLV(s). preference to that received in TRILL-VER sub-TLV(s).
For multi-topology aware TRILL switches, the TRILL version and For multi-topology-aware TRILL Switches, the TRILL version and
capabilities announced for the base topology are assumed to apply to capabilities announced for the base topology are assumed to apply to
all topologies for which a separate TRILL version announcement does all topologies for which a separate TRILL version announcement does
not occur in an MT Capabilities TLV. Such announcements for non-zero not occur in an MT-Capability TLV. Such announcements for non-zero
topologies need not occur in fragment zero. topologies need not occur in fragment zero.
2.3.2 Nickname Sub-TLV 2.3.2. Nickname Sub-TLV
The Nickname (NICKNAME) Router Capability sub-TLV carries information The Nickname (NICKNAME) Router Capability sub-TLV carries information
about the nicknames of the originating IS, along with information about the nicknames of the originating IS, along with information
about its priority to hold those nicknames and the priority for each about its priority to hold those nicknames and the priority for each
nickname to be a tree root as specified in [RFC6325] Section 3.7.3. nickname to be a tree root as specified in [RFC6325], Section 3.7.3.
Multiple instances of this sub-TLV may occur. Multiple instances of this sub-TLV may occur.
INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = NICKNAME| (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | (1 byte) | NICKNAME RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (1) | | NICKNAME RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (2) | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NICKNAME RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where each nickname record is of the form: where each nickname record is of the form:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Nickname.Pri | (1 byte) | Nickname.Pri | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Root Priority | (2 byte) | Tree Root Priority | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes) | Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router and MT Capability sub-TLV type, set to 6 (NICKNAME). o Type: Router Capability and MT-Capability 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.Pri: An 8-bit unsigned integer priority to hold a o Nickname.Pri: An 8-bit unsigned integer priority to hold a
nickname as specified in Section 3.7.3 of [RFC6325]. nickname as specified in Section 3.7.3 of [RFC6325].
o Tree Root Priority: This is an unsigned 16-bit integer priority to o Tree Root Priority: This is an unsigned 16-bit integer priority to
be a tree root as specified in Section 4.5 of [RFC6325]. be a tree root as specified in Section 4.5 of [RFC6325].
o Nickname: This is an unsigned 16-bit integer as specified in o Nickname: This is an unsigned 16-bit integer as specified in
Section 3.7 of [RFC6325]. Section 3.7 of [RFC6325].
2.3.3 Trees Sub-TLV 2.3.3. Trees Sub-TLV
Each IS providing TRILL service uses the TREES sub-TLV to announce Each IS providing TRILL service uses the TREES sub-TLV to announce
three numbers related to the computation of distribution trees as three numbers related to the computation of distribution trees as
specified in Section 4.5 of [RFC6325]. Its format is as follows: specified in Section 4.5 of [RFC6325]. Its format is as follows:
INTERNET-DRAFT TRILL Use of IS-IS
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = TREES | (1 byte) |Type = TREES | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to compute | (2 byte) | Number of trees to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum trees able to compute | (2 byte) | Maximum trees able to compute | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of trees to use | (2 byte) | Number of trees to use | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router and MT Capability sub-TLV type, set to 7 (TREES). o Type: Router Capability and MT-Capability sub-TLV type, set to 7
(TREES).
o Length: 6. o Length: 6.
o Number of trees to compute: An unsigned 16-bit integer as o Number of trees to compute: An unsigned 16-bit integer as
specified in Section 4.5 of [RFC6325]. specified in Section 4.5 of [RFC6325].
o Maximum trees able to compute: An unsigned 16-bit integer as o Maximum trees able to compute: An unsigned 16-bit integer as
specified in Section 4.5 of [RFC6325]. specified in Section 4.5 of [RFC6325].
o Number of trees to use: An unsigned 16-bit integer as specified in o Number of trees to use: An unsigned 16-bit integer as specified in
Section 4.5 of [RFC6325]. Section 4.5 of [RFC6325].
2.3.4 Tree Identifiers Sub-TLV 2.3.4. Tree Identifiers Sub-TLV
The tree identifiers (TREE-RT-IDs) sub-TLV is an ordered list of The Tree Identifiers (TREE-RT-IDs) sub-TLV is an ordered list of
nicknames. When originated by the IS that has the highest priority to nicknames. When originated by the IS that has the highest priority
be a tree root, it lists the distribution trees that the other ISs to be a tree root, it lists the distribution trees that the other ISs
are required to compute as specified in Section 4.5 of [RFC6325]. If are required to compute as specified in Section 4.5 of [RFC6325]. If
this information is spread across multiple sub-TLVs, the starting this information is spread across multiple sub-TLVs, the starting
tree number is used to allow the ordered lists to be correctly tree number is used to allow the ordered lists to be correctly
concatenated. The sub-TLV format is as follows: concatenated. The sub-TLV format is as follows:
+-+-+-+-+-+-+-+-+
|Type=TREE-RT-IDs| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+
|Type=TREE-RT-IDs| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Starting Tree Number | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K-th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (K+1 - th root) | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname (...) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router and MT Capability sub-TLV type, set to 8 (TREE-RT- o Type: Router Capability and MT-Capability sub-TLV type, set to 8
IDs). (TREE-RT-IDs).
o Length: 2 + 2*n, where n is the number of nicknames listed. o Length: 2 + 2*n, where n is the number of nicknames listed.
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 sub-TLV containing the first list. Other Tree-Identifiers sub- the sub-TLV containing the first list. Other Tree-Identifiers
TLVs will have the number of the starting list they contain. In sub-TLVs will have the number of the starting list they contain.
the event the same tree identifier can be computed from two such In the event the same tree identifier can be computed from two
sub-TLVs and they are different, then it is assumed that this is a such sub-TLVs and they are different, then it is assumed that this
transient condition that will get cleared. During this transient is a transient condition that will get cleared. During this
time, such a tree SHOULD NOT be computed unless such computation transient time, such a tree SHOULD NOT be computed unless such
is indicated by all relevant sub-TLVs present. computation is indicated by all relevant sub-TLVs present.
o Nickname: The nickname at which a distribution tree is rooted. o Nickname: The nickname at which a distribution tree is rooted.
2.3.5 Trees Used Identifiers Sub-TLV 2.3.5. Trees Used Identifiers Sub-TLV
This Router Capability sub-TLV has the same structure as the Tree This Router Capability sub-TLV has the same structure as the Tree
Identifiers sub-TLV specified in Section 2.3.4. The only difference Identifiers sub-TLV specified in Section 2.3.4. The only difference
is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees is that its sub-TLV type is set to 9 (TREE-USE-IDs), and the trees
listed are those that the originating IS wishes to use as specified listed are those that the originating IS wishes to use as specified
in [RFC6325], Section 4.5. in [RFC6325], Section 4.5.
2.3.6 Interested VLANs and Spanning Tree Roots Sub-TLV 2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV
The value of this sub-TLV consists of a VLAN range and information in The value of this sub-TLV consists of a VLAN range and information in
common to all of the VLANs in the range for the originating IS. This common to all of the VLANs in the range for the originating IS. This
information consists of flags, a variable length list of spanning information consists of flags, a variable length list of spanning
tree root bridge IDs, and an appointed forwarder status lost counter, tree root bridge IDs, and an Appointed Forwarder status lost counter,
all as specified in the sections of [RFC6325] listed with the all as specified in the sections of [RFC6325] listed with the
respective information items below. respective information items below.
In the set of LSPs originated by an IS, the union of the VLAN ranges In the set of LSPs originated by an IS, the union of the VLAN ranges
in all occurrences of this sub-TLV MUST be the set of VLANs for which in all occurrences of this sub-TLV MUST be the set of VLANs for which
the originating IS is appointed forwarder on at least one port, and the originating IS is Appointed Forwarder on at least one port, and
the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap the VLAN ranges in multiple VLANs sub-TLVs for an IS MUST NOT overlap
unless the information provided about a VLAN is the same in every unless the information provided about a VLAN is the same in every
instance. However, as a transient state these conditions may be instance. However, as a transient state, these conditions may be
violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS, violated. If a VLAN is not listed in any INT-VLAN sub-TLV for an IS,
that IS is assumed to be uninterested in receiving traffic for that that IS is assumed to be uninterested in receiving traffic for that
VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS VLAN. If a VLAN appears in more than one INT-VLAN sub-TLV for an IS
with different information in the different instances, the following with different information in the different instances, the following
apply: apply:
INTERNET-DRAFT TRILL Use of IS-IS
- If those sub-TLVs provide different nicknames, it is unspecified - If those sub-TLVs provide different nicknames, it is unspecified
which nickname takes precedence. which nickname takes precedence.
- The largest appointed forwarder status lost counter, using serial - The largest Appointed Forwarder status lost counter, using serial
number arithmetic [RFC1982], is used. number arithmetic [RFC1982], is used.
- The originating IS is assumed to be attached to a multicast IPv4 - The originating IS is assumed to be attached to a multicast IPv4
router for that VLAN if any of the INT-VLAN sub-TLVs assert that router for that VLAN if any of the INT-VLAN sub-TLVs assert that
it is so connected and similarly for IPv6 multicast router it is so connected and similarly for IPv6 multicast router
attachment. attachment.
- The root bridge lists from all of the instances of the VLAN for - The root bridge lists from all of the instances of the VLAN for
the originating IS are merged. the originating IS are merged.
To minimize such occurrences, wherever possible, an implementation To minimize such occurrences, wherever possible, an implementation
SHOULD advertise the update to an interested VLAN and Spanning Tree SHOULD advertise the update to an interested VLAN and Spanning Tree
Roots sub-TLV in the same LSP fragment as the advertisement that it Roots sub-TLV in the same LSP fragment as the advertisement that it
replaces. Where this is not possible, the two affected LSP fragments replaces. Where this is not possible, the two affected LSP fragments
should be flooded as an atomic action. An IS that receives an update should be flooded as an atomic action. An IS that receives an update
to an existing interested VLAN and Spanning Tree Roots sub-TLV can to an existing interested VLAN and Spanning Tree Roots sub-TLV can
minimize the potential disruption associated with the update by minimize the potential disruption associated with the update by
employing a hold-down timer prior to processing the update so as to employing a hold-down timer prior to processing the update so as to
allow for the receipt of multiple LSP fragments associated with the allow for the receipt of multiple LSP fragments associated with the
same update prior to beginning processing. same update prior to beginning processing.
The sub-TLV layout is as follows: The sub-TLV layout is as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type = INT-VLAN| (1 byte) |Type = INT-VLAN| (1 byte)
skipping to change at page 22, line 45 skipping to change at page 23, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes) | Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Interested VLANS | (4 bytes) | Interested VLANS | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes) | Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+
| Root Bridges | (6*n bytes) | Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router and MT Capability sub-TLV type, set to 10 (INT-VLAN). o Type: Router Capability and MT-Capability sub-TLV type, set to 10
(INT-VLAN).
o Length: 10 + 6*n, where n is the number of root bridge IDs. o Length: 10 + 6*n, where n is the number of root bridge IDs.
o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field o Nickname: As specified in [RFC6325], Section 4.2.4.4, this field
may be used to associate a nickname held by the originating IS may be used to associate a nickname held by the originating IS
with the VLAN range indicated. When not used in this way, it is with the VLAN range indicated. When not used in this way, it is
set to zero. set to zero.
o Interested VLANS: The Interested VLANs field is formatted as shown o Interested VLANS: The Interested VLANs field is formatted as shown
below. below.
INTERNET-DRAFT TRILL Use of IS-IS 0 1 2 3 4 - 15 16 - 19 20 - 31
+----+----+----+----+------------+----------+------------+
0 1 2 3 4 - 15 16 - 19 20 - 31 | M4 | M6 | R | R | VLAN.start | RESV | VLAN.end |
+----+----+----+----+------------+----------+------------+ +----+----+----+----+------------+----------+------------+
| M4 | M6 | R | R | VLAN.start | RESV | VLAN.end |
+----+----+----+----+------------+----------+------------+
- M4, M6: These bits indicate, respectively, that there is an - M4, M6: These bits indicate, respectively, that there is an
IPv4 or IPv6 multicast router on a link for which the IPv4 or IPv6 multicast router on a link for which the
originating IS is appointed forwarder for every VLAN in the originating IS is Appointed Forwarder for every VLAN in the
indicated range as specified in [RFC6325], Section 4.2.4.4, indicated range as specified in [RFC6325], Section 4.2.4.4,
item 5.1. item 5.1.
- R, RESV: These reserved bits MUST be sent as zero and are - R, RESV: These reserved bits MUST be sent as zero and are
ignored on receipt. ignored on receipt.
- VLAN.start and VLAN.end: This VLAN ID range is inclusive. - VLAN.start and VLAN.end: This VLAN ID range is inclusive.
Setting both VLAN.start and VLAN.end to the same value Setting both VLAN.start and VLAN.end to the same value
indicates a range of one VLAN ID. If VLAN.start is not equal to indicates a range of one VLAN ID. If VLAN.start is not equal
VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted as to VLAN.end and VLAN.start is 0x000, the sub-TLV is interpreted
if VLAN.start was 0x001. If VLAN.start is not equal to VLAN.end as if VLAN.start was 0x001. If VLAN.start is not equal to
and VLAN.end is 0xFFF, the sub-TVL is interpreted as if VLAN.end and VLAN.end is 0xFFF, the sub-TLV is interpreted as
VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start, the if VLAN.end was 0xFFE. If VLAN.end is less than VLAN.start,
sub-TLV is ignored. If both VLAN.start and VLAN.end are 0x000 the sub-TLV is ignored. If both VLAN.start and VLAN.end are
or both are 0xFFF, the sub-TLV is ignored. The values 0x000 or 0x000 or both are 0xFFF, the sub-TLV is ignored. The values
0xFFF are not valid VLAN IDs and a port cannot be enabled for 0x000 or 0xFFF are not valid VLAN IDs, and a port cannot be
them. enabled for them.
o Appointed Forwarder Status Lost Counter: This is a count of how o Appointed Forwarder Status Lost Counter: This is a count of how
many times a port that was appointed forwarder for the VLANs in many times a port that was Appointed Forwarder for the VLANs in
the range given has lost the status of being an appointed the range given has lost the status of being an Appointed
forwarder for some port as discussed in Section 4.8.3 of Forwarder for some port as discussed in Section 4.8.3 of
[RFC6325]. It is initialized to zero at an IS when the zeroth LSP [RFC6325]. It is initialized to zero at an IS when the zeroth LSP
sequence number is initialized. No special action need be taken at sequence number is initialized. No special action need be taken
rollover; the counter just wraps around. at rollover; the counter just wraps around.
o Root Bridges: The list of zero or more spanning tree root bridge o Root Bridges: The list of zero or more spanning tree root bridge
IDs is the set of root bridge IDs seen for all ports for which the IDs is the set of root bridge IDs seen for all ports for which the
IS is appointed forwarder for the VLANs in the specified range as IS is Appointed Forwarder for the VLANs in the specified range as
discussed in [RFC6325], Section 4.9.3.2. While, of course, at most discussed in [RFC6325], Section 4.9.3.2. While, of course, at
one spanning tree root could be seen on any particular port, there most one spanning tree root could be seen on any particular port,
may be multiple ports in the same VLANs connected to different there may be multiple ports in the same VLANs connected to
bridged LANs with different spanning tree roots. different bridged LANs with different spanning tree roots.
An INT-VLAN sub-TLV asserts that the information provided (multicast An INT-VLAN sub-TLV asserts that the information provided (multicast
router attachment, appointed forwarder status lost counter, and root router attachment, Appointed Forwarder status lost counter, and root
bridges) is the same for all VLANs in the range specified. If this is bridges) is the same for all VLANs in the range specified. If this
not the case, the range MUST be split into subranges meeting this is not the case, the range MUST be split into subranges meeting this
criteria. It is always safe to use sub-TLVs with a "range" of one criteria. It is always safe to use sub-TLVs with a "range" of one
VLAN ID, but this may be too verbose. VLAN ID, but this may be too verbose.
INTERNET-DRAFT TRILL Use of IS-IS 2.3.7. VLAN Group Sub-TLV
2.3.7 VLAN Group Sub-TLV
The VLAN Group sub-TLV consists of two or more VLAN IDs as specified The VLAN Group sub-TLV consists of two or more VLAN IDs as specified
in [RFC6325], Section 4.8.4. This sub-TLV indicates that shared VLAN in [RFC6325], Section 4.8.4. This sub-TLV indicates that shared VLAN
learning is occurring at the originating IS between the listed VLANs. learning is occurring at the originating IS between the listed VLANs.
It is structured as follows: It is structured as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=VLAN-GROUP| (1 byte) |Type=VLAN-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Primary VLAN ID | (2 bytes) | RESV | Primary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Secondary VLAN ID | (2 bytes) | RESV | Secondary VLAN ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary VLAN IDs ... (2 bytes each) | more Secondary VLAN IDs ... (2 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 14
o Type: Router and MT Capability sub-TLV type, set to 14 (VLAN- (VLAN-GROUP).
GROUP).
o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields o Length: 4 + 2*n, where n is the number of secondary VLAN ID fields
beyond the first. n MAY be zero. beyond the first. n MAY be zero.
o RESV: a 4-bit field that MUST be sent as zero and ignored on o RESV: a 4-bit field that MUST be sent as zero and ignored on
receipt. receipt.
o Primary VLAN ID: This identifies the primary VLAN ID. o Primary VLAN ID: This identifies the primary VLAN ID.
o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN o Secondary VLAN ID: This identifies a secondary VLAN in the VLAN
Group. Group.
o more Secondary VLAN IDs: zero or more byte pairs, each with the o more Secondary VLAN IDs: zero or more byte pairs, each with the
top 4 bits as a RESV field and the low 12 bits as a VLAN ID. top 4 bits as a RESV field and the low 12 bits as a VLAN ID.
2.3.8 Interested Labels and Spanning Tree Roots Sub-TLV 2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV
An IS that can handle fine-grained labeling [RFCfgl] announces its An IS that can handle fine-grained labeling [RFC7172] announces its
fine-grained label connectivity and related information in the fine-grained label connectivity and related information in the
"Interested Labels and Bridge Spanning Tree Roots sub-TLV" (INT- Interested Labels and Spanning Tree Roots sub-TLV (INT-LABEL). It is
LABEL) which is a variation of the "Interested VLANs and Spanning a variation of the Interested VLANs and Spanning Tree Roots sub-TLV
Tree Roots sub-TLV" (INT-VLAN) structured as below. (INT-VLAN) and is structured as follows.
INTERNET-DRAFT TRILL Use of IS-IS
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type= INT-LABEL| (1 byte) |Type=INT-LABEL | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname | (2 bytes) | Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Interested Labels | (7 bytes) | Interested Labels | (7 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+
| Appointed Forwarder Status Lost Counter | (4 bytes) | Appointed Forwarder Status Lost Counter | (4 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
| Root Bridges | (6*n bytes) | Root Bridges | (6*n bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+
o Type: Router and MT Capability sub-TLV Type, set to TBDh [15 o Type: Router Capability and MT-Capability sub-TLV type, set to 15
suggested] (INT-LABEL). (INT-LABEL).
o Length: 11 + 6*n where n is the number of root bridge IDs. o Length: 11 + 6*n, where n is the number of root bridge IDs.
o Nickname: This field may be used to associate a nickname held by o Nickname: This field may be used to associate a nickname held by
the originating IS with the Labels indicated. When not used in the originating IS with the Interested Labels indicated. When not
this way, it is set to zero. used in this way, it is set to zero.
o Interested Labels: The Interested Labels field is seven bytes long o Interested Labels: The Interested Labels field is seven bytes long
and formatted as shown below. and formatted as shown below.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
|M4|M6|BM| R| R| R| R| R| . . |M4|M6|BM| R| R| R| R| R| . .
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.start - 24 bits | | Label.start - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label.end or Bit Map - 24 bits | | Label.end or bit-map - 24 bits |
+--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +--+--+--+--+--+--+--+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
- M4, M6: These bits indicate, respectively, that there is an - M4, M6: These bits indicate, respectively, that there is an
IPv4 or IPv6 multicast router on a link to which the IPv4 or IPv6 multicast router on a link to which the
originating IS is appointed forwarder for the VLAN originating IS is Appointed Forwarder for the VLAN
corresponding to every label in the indicated range. corresponding to every label in the indicated range.
- BM: If the BM (Bit Map) bit is zero, the last three bytes of - BM: If the BM (bit-map) bit is zero, the last three bytes of
the Interested Labels is a Label.end label number. If the BM the Interested Labels is a Label.end label number. If the BM
bit is one, those bytes are a bit map as described below. bit is one, those bytes are a bit-map as described below.
- R: These reserved bits MUST be sent as zero and are ignored on - R: These reserved bits MUST be sent as zero and are ignored on
receipt. receipt.
INTERNET-DRAFT TRILL Use of IS-IS - Label.start and Label.end: If the BM bit is zero, this fine-
grained label [RFC7172] ID range is inclusive. These fields
- Label.start and Label.end: If the BM bit is zero: This fine- are treated as unsigned integers. Setting them both to the
grained label [RFCfgl] ID range is inclusive. These fields are same label ID value indicates a range of one label ID. If
treated as unsigned integers. Setting them both to that same Label.end is less than Label.start, the sub-TLV is ignored.
label ID value indicates a range of one label ID. If Label.end
is less than Label.start, the sub-TLV is ignored.
- Label.start and Bit Map: If the BM bit is one: The fine-grained - Label.start and bit-map: If the BM bit is one, the fine-grained
labels that the IS is interested in are indicated by a 24-bit labels that the IS is interested in are indicated by a 24-bit
bit map. The interested labels are the Label.start number plus bit-map. The interested labels are the Label.start number plus
the bit number of each one bit in the bit map. So, if bit zero the bit number of each one bit in the bit-map. So, if bit zero
of the bit map is a one, the IS in interested in the label with of the bit-map is a one, the IS is interested in the label with
value Label.start and if bit 23 of the bit map is a one, the IS value Label.start, and if bit 23 of the bit-map is a one, the
is interested in the label with value Label.start+23. IS is interested in the label with value Label.start+23.
o Appointed Forwarder Status Lost Counter: This is a count of how o Appointed Forwarder Status Lost Counter: This is a count of how
many times a port that was appointed forwarder for a VLAN mapping many times a port that was Appointed Forwarder for a VLAN mapping
to the fine-grained label in the range or bit map given has lost to the fine-grained label in the range or bit-map given has lost
the status of being an appointed forwarder as discussed in Section the status of being an Appointed Forwarder as discussed in Section
4.8.3 of [RFC6325]. It is initialized to zero at an IS when the 4.8.3 of [RFC6325]. It is initialized to zero at an IS when the
zeroth LSP sequence number is initialized. No special action need zeroth LSP sequence number is initialized. No special action need
be taken at rollover; the counter just wraps around. be taken at rollover; the counter just wraps around.
o Root Bridges: The list of zero or more spanning tree root bridge o Root Bridges: The list of zero or more spanning tree root bridge
IDs is the set of root bridge IDs seen for all ports for which the IDs is the set of root bridge IDs seen for all ports for which the
IS is appointed forwarder for a VLAN mapping to the fine-grained IS is Appointed Forwarder for a VLAN mapping to the fine-grained
label in the specified range or bit map. (See [RFC6325], Section label in the specified range or bit-map. (See [RFC6325], Section
4.9.3.2.) While, of course, at most one spanning tree root could 4.9.3.2.) While, of course, at most one spanning tree root could
be seen on any particular port, there may be multiple relevant be seen on any particular port, there may be multiple relevant
ports connected to different bridged LANs with different spanning ports connected to different bridged LANs with different spanning
tree roots. tree roots.
An INT-LABEL sub-TLV asserts that the information provided (multicast An INT-LABEL sub-TLV asserts that the information provided (multicast
router attachment, appointed forwarder status lost counter, and root router attachment, Appointed Forwarder status lost counter, and root
bridges) is the same for all labels specified. If this is not the bridges) is the same for all labels specified. If this is not the
case, the sub-TLV MUST be split into subranges and/or separate bit case, the sub-TLV MUST be split into subranges and/or separate bit
maps meeting this criteria. It is always safe to use sub-TLVs with a maps meeting this criteria. It is always safe to use sub-TLVs with a
"range" of one VLAN ID, but this may be too verbose. "range" of one VLAN ID, but this may be too verbose.
2.3.9 RBridge Channel Protocols Sub-TLV 2.3.9. RBridge Channel Protocols Sub-TLV
An IS announces the RBridge Channel protocols [Channel] it supports An IS announces the RBridge Channel protocols [RFC7178] it supports
through use of this sub-TLV. through use of this sub-TLV.
INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+
|Type=RBCHANNELS| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Type=RBCHANNELS| (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Length | (1 byte) | Zero or more bit vectors (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-...
| Zero or more bit vectors (variable)
+-+-+-+-...
o Type: Router and MT Capabilities RBridge Channel Protocols sub- o Type: Router Capability and MT-Capability RBridge Channel
TLV, set to TBDi [16 suggested] (RBCHANNELS). Protocols sub-TLV, set to 16 (RBCHANNELS).
o Length: variable. o Length: variable.
o Bit Vectors: Zero or more byte-aligned bit vectors where a one bit o Bit Vectors: Zero or more byte-aligned bit vectors where a one bit
indicates support of a particular RBridge Channel protocol. Each indicates support of a particular RBridge Channel protocol. Each
byte-aligned bit vector is formatted as follows: byte-aligned bit vector is formatted as follows:
| 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15| | 0 1 2 3 4 5 6 7| 8 9 10 11 12 13 14 15|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Bit Vector Length | Bit Vector Offset | | Bit Vector Length | Bit Vector Offset |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| bits | bits
+--+--+--... +--+--+--...
The bit vector length (BVL) is a seven bit unsigned integer field
giving the number of bytes of bit vector. The bit vector offset (BVO)
is a nine bit unsigned integer field.
The bits in each bit vector are numbered in network order, the high
order bit of the first byte of bits being bit 0 + 8*BVO, the low
order bit of that byte being 7 + 8*BVO, the high order bit of the
second byte being 8 + 8*BVO, and so on for BVL bytes. An RBridge
Channel protocols-supported bit vector MUST NOT extend beyond the end
of the value in the sub-TLV in which it occurs. If it does, it is
ignored. If multiple byte-aligned bit vectors are present in one such
sub-TLV, their representations are contiguous, the BVL field for the
next starting immediately after the last byte of bits for the
previous bit vector. The one or more bit vectors present MUST exactly
fill the sub-TLV value. If there are one or two bytes of value left
over, they are ignored; if more than two, an attempt is made to parse
them as one or more bit vectors.
If different bit vectors overlap in the protocol number space they The Bit Vector Length (BVL) is a seven-bit unsigned integer field
refer to and they have inconsistent bit values for a channel giving the number of bytes of bit vector. The Bit Vector Offset
protocol, support for the protocol is assumed if any of these bit (BVO) is a nine-bit unsigned integer field.
vectors has a 1 for that protocol.
The absence of any occurrences of this sub-TLV in the LSP for an IS The bits in each bit vector are numbered in network order, the
implies that that IS does not support the RBridge Channel facility. high-order bit of the first byte of bits being bit 0 + 8*BVO, the
low-order bit of that byte being 7 + 8*BVO, the high order bit of
the second byte being 8 + 8*BVO, and so on for BVL bytes. A bit
vector of RBridge Channel protocols supported MUST NOT extend
beyond the end of the value in the sub-TLV in which it occurs. If
it does, it is ignored. If multiple byte-aligned bit vectors are
present in one such sub-TLV, their representations are contiguous,
the BVL field for the next starting immediately after the last
byte of bits for the previous bit vector. The one or more bit
vectors present MUST exactly fill the sub-TLV value. If there are
one or two bytes of value left over, they are ignored; if more
than two, an attempt is made to parse them as one or more bit
vectors.
INTERNET-DRAFT TRILL Use of IS-IS If different bit vectors overlap in the protocol number space they
refer to and they have inconsistent bit values for a channel
protocol, support for the protocol is assumed if any of these bit
vectors has a 1 for that protocol.
To avoid wasted space, trailing bit vector zero bytes SHOULD be The absence of any occurrences of this sub-TLV in the LSP for an
eliminated by reducing BVL, any null bit vectors (ones with BVL equal IS implies that the IS does not support the RBridge Channel
to zero) eliminated, and generally the most compact encoding used. facility. To avoid wasted space, trailing bit vector zero bytes
For example, support for channel protocols 1 and 32 could be encoded SHOULD be eliminated by reducing BVL, any null bit vectors (ones
as with BVL equal to zero) eliminated, and generally the most compact
encoding used. For example, support for channel protocols 1 and
32 could be encoded as
BVL = 5 BVL = 5
BVO = 0 BVO = 0
0b01000000 0b01000000
0b00000000 0b00000000
0b00000000 0b00000000
0b00000000 0b00000000
0b10000000 0b10000000
or as or as
BVL = 1 BVL = 1
BVO = 0 BVO = 0
0b01000000 0b01000000
BLV = 1 BLV = 1
BVO = 4 BVO = 4
0b1000000 0b1000000
The first takes 7 bytes while the second takes only 6 and thus the The first takes 7 bytes while the second takes only 6; thus, the
second would be preferred. second would be preferred.
In multi-topology aware RBridges, RBridge channel protocols for which In multi-topology-aware RBridges, RBridge Channel protocols for which
support is announced in the base topology are assumed to be supported support is announced in the base topology are assumed to be supported
in all topologies for which there is no separate RBridge channel in all topologies for which there is no separate announcement for
protocol support announcement. RBridge Channel protocol support.
2.3.10 Affinity Sub-TLV 2.3.10. Affinity Sub-TLV
Association of an IS to a multi-destination distribution tree through Association of an IS to a multi-destination distribution tree through
a specific path is accomplished by using the tree Affinity sub-TLV. a specific path is accomplished by using the Affinity sub-TLV. The
The announcement of an Affinity sub-TLV by RB1 with the nickname of announcement of an Affinity sub-TLV by RB1 with the nickname of RB2
RB2 as the first part of an Affinity Record in the sub-TLV value is a as the first part of an Affinity Record in the sub-TLV value is a
request by RB1 that all ISes in the campus connect RB2 as a child of request by RB1 that all ISs in the campus connect RB2 as a child of
RB1 when calculating any of the trees listed in that Affinity Record. RB1 when calculating any of the trees listed in that Affinity Record.
Examples of use include [Affinity] and [Resilient]. Examples of use include [Affinity] and [Resilient].
The structure of the AFFINITY sub-TLV is shown below. The structure of the Affinity sub-TLV is shown below.
INTERNET-DRAFT TRILL Use of IS-IS
+-+-+-+-+-+-+-+-+
| Type=AFFINITY | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where each AFFINITY RECORD is structured as follows: +-+-+-+-+-+-+-+-+
| Type=AFFINITY | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ..........
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFFINITY RECORD N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each AFFINITY RECORD is structured as follows:
| Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Affinity Flags | (1 byte)
+-+-+-+-+-+-+-+-+
|Number of trees| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 1st root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 2nd root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of Nth root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router and MT Capability sub-TLV type, set to TBDj [17 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
suggested] (AFFINITY). | Nickname | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Affinity Flags | (1 byte)
+-+-+-+-+-+-+-+-+
|Number of trees| (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 1st root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of 2nd root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .......... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree-num of Nth root | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router Capability and MT-Capability sub-TLV type, set to 17
(AFFINITY).
o Length: 1 + size of all Affinity Records included, where an o Length: size of all Affinity Records included, where an Affinity
Affinity Record listing n tree roots is 3+2*n bytes long. Record listing n tree roots is 4+2*n bytes long.
o Nickname: 16-bit nickname of the IS whose associations to the o Nickname: 16-bit nickname of the IS whose associations to the
multi-destination trees listed in the Affinity Record are through multi-destination trees listed in the Affinity Record are through
the originating IS. the originating IS.
o Affinity Flags: 8 bits reserved for future needs to provide o Affinity Flags: 8 bits reserved for future needs to provide
additional information about the affinity being announced. MUST be additional information about the affinity being announced. MUST
sent as zero and ignored on receipt. be sent as zero and ignored on receipt.
o Number of trees: A one byte unsigned integer giving the number of o Number of trees: A one-byte unsigned integer giving the number of
trees for which affinity is being announced by this Affinity trees for which affinity is being announced by this Affinity
Record. Record.
INTERNET-DRAFT TRILL Use of IS-IS
o Tree-num of roots: The tree numbers of the distribution trees this o Tree-num of roots: The tree numbers of the distribution trees this
Affinity Record is announcing. Affinity Record is announcing.
There is no need for a field giving the number of Affinity Records as There is no need for a field giving the number of Affinity Records as
this can be determined by processing those records. this can be determined by processing those records.
2.3.11 Label Group Sub-TLV 2.3.11 Label Group Sub-TLV
The Label Group sub-TLV consists of two or more fine-grained label The Label Group sub-TLV consists of two or more fine-grained label
[RFCfgl] IDs. This sub-TLV indicates that shared Label MAC address [RFC7172] IDs. This sub-TLV indicates that shared label MAC address
learning is occurring at the announcing IS between the listed Labels. learning is occurring at the announcing IS between the listed labels.
It is structured as follows: It is structured as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Typ=LABEL-GROUP| (1 byte) |Typ=LABEL-GROUP| (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Primary Label ID | (3 bytes) | Primary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Secondary Label ID | (3 bytes) | Secondary Label ID | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| more Secondary Label IDs ... (3 bytes each) | more Secondary Label IDs ... (3 bytes each)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Router and MT Capability sub-TLV type, set to TBDk [18 o Type: Router Capability and MT-Capability sub-TLV type, set to 18
suggested] (LABEL-GROUP). (LABEL-GROUP).
o Length: 6 + 3*n, where n is the number of secondary VLAN ID fields o Length: 6 + 3*n, where n is the number of secondary VLAN ID fields
beyond the first. n MAY be zero. beyond the first. n MAY be zero.
o Primary Label ID: This identifies the primary Label ID. o Primary Label ID: This identifies the primary Label ID.
o Secondary Label ID: This identifies a secondary Label in the Label o Secondary Label ID: This identifies a secondary Label ID in the
Group. Label Group.
o more Secondary Label IDs: zero or more byte triples, each with a o more Secondary Label IDs: zero or more byte triples, each with a
Label ID. Label ID.
2.4 MTU Sub-TLV for Ext. Reachability and MT ISN TLVs 2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs
The MTU sub-TLV is used to optionally announce the MTU of a link as The MTU sub-TLV is used to optionally announce the MTU of a link as
specified in [RFC6325] Section 4.2.4.4. It occurs within the Extended specified in [RFC6325], Section 4.2.4.4. It occurs within the
Reachability (#22) and MT (multi-topology) ISN (Intermediate System Extended Reachability (#22) and MT-ISN (Intermediate System
Neighbors) (#222) TLVs. Neighbors) (#222) TLVs.
INTERNET-DRAFT TRILL Use of IS-IS +-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = MTU | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) |F| RESV | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| RESV | (1 byte) | MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: Extended Reachability and MT IS sub-TLV type, set to MTU o Type: Extended Reachability and MT-ISN sub-TLV type, set to MTU
sub-TLV 28. sub-TLV 28.
o Length: 3. o Length: 3.
o F: Failed. This bit is a one if MTU testing failed on this link at o F: Failed. This bit is a one if MTU testing failed on this link
the required campus-wide MTU. at the required campus-wide MTU.
o RESV: 7 bits that MUST be sent as zero and ignored on receipt. o RESV: 7 bits that MUST be sent as zero and ignored on receipt.
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, as specified in for this link or zero if it has not been tested, as specified in
Section 4.3.2 of [RFC6325]. Section 4.3.2 of [RFC6325].
2.5 TRILL Neighbor TLV 2.5. TRILL Neighbor TLV
The TRILL Neighbor TLV is used in TRILL broadcast link IIH PDUs (see The TRILL Neighbor TLV is used in TRILL broadcast link IIH PDUs (see
Section 4.1 below) in place of the IS Neighbor TLV, as specified in Section 4.1 below) in place of the IS Neighbor TLV, as specified in
Section 4.4.2.1 of [RFC6325] and in [RFC6327]. The structure of the Section 4.4.2.1 of [RFC6325] and in [RFC7177]. The structure of the
TRILL Neighbor TLV is as follows: TRILL Neighbor TLV is as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type | (1 byte) | Type | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Length | (1 byte) | Length | (1 byte)
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|S|L|R| SIZE | (1 byte) |S|L|R| SIZE | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (1) | | Neighbor RECORDS (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (2) | | Neighbor RECORDS (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................. | | ................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor RECORDS (N) | | Neighbor RECORDS (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
INTERNET-DRAFT TRILL Use of IS-IS
The information present for each neighbor is as follows: The information present for each neighbor is as follows:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F|O| RESV | (1 bytes) |F|O| RESV | (1 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | (2 bytes) | MTU | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
| SNPA (MAC Address) | (SIZE bytes) | SNPA (MAC Address) | (SIZE bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+-+-+-+
o Type: TLV Type, set to TRILL Neighbor TLV 145. o Type: TLV type, set to TRILL Neighbor TLV 145.
o Length: 1 + (SIZE+3)*n, where n is the number of neighbor records, o Length: 1 + (SIZE+3)*n, where n is the number of neighbor records,
which may be zero. which may be zero.
o S: Smallest flag. If this bit is a one, then the list of neighbors o S: Smallest flag. If this bit is a one, then the list of
includes the neighbor with the smallest MAC address considered as neighbors includes the neighbor with the smallest MAC address
an unsigned integer. considered as an unsigned integer.
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 considered as includes the neighbor with the largest MAC address considered as
an unsigned integer. an unsigned integer.
o R, RESV: These bits are reserved and MUST be sent as zero and o R, RESV: These bits are reserved and MUST be sent as zero and
ignored on receipt. ignored on receipt.
o SIZE: The SNPA size as an unsigned integer in bytes except that 6 o SIZE: The SNPA size as an unsigned integer in bytes except that 6
is encoded as zero. An actual size of zero is meaningless and is encoded as zero. An actual size of zero is meaningless and
cannot be encoded. The meaning of the value 6 in this field is cannot be encoded. The meaning of the value 6 in this field is
reserved and TRILL Neighbor TLVs received with a SIZE of 6 are reserved, and TRILL Neighbor TLVs received with a SIZE of 6 are
ignored. The SIZE is inherent to the technology of a link and is ignored. The SIZE is inherent to the technology of a link and is
fixed for all TRILL Neighbor TLVs on that link but may vary fixed for all TRILL Neighbor TLVs on that link but may vary
between different links in the campus if those links are different between different links in the campus if those links are different
technologies. For example, 6 for EUI-48 SNPAs or 8 for EUI-64 technologies, for example, 6 for EUI-48 SNPAs or 8 for EUI-64
SNPAs [RFC7042]. (The SNPA size on the various links in a TRILL SNPAs [RFC7042]. (The SNPA size on the various links in a TRILL
campus is independent of the System ID size.) campus is independent of the System ID size.)
o F: failed. This bit is a one if MTU testing to this neighbor o F: Failed. This bit is a one if MTU testing to this neighbor
failed at the required campus-wide MTU (see [RFC6325], Section failed at the required campus-wide MTU (see [RFC6325], Section
4.3.1). 4.3.1).
o O: OOMF. This bit is a one if the IS sending the enclosing TRILL o O: OOMF. This bit is a one if the IS sending the enclosing TRILL
Neighbor TLV is willing to offer the Overload Originated Multi- Neighbor TLV is willing to offer the Overload Originated Multi-
destination Frame (OOMF) service [ClearCorrect] to the IS whose destination Frame (OOMF) service [RFC7180] to the IS whose port
port has the SNPA in the enclosing Neighbor RECORD. has the SNPA in the enclosing Neighbor RECORD.
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 to zero if it has not been tested. for this neighbor or to zero if it has not been tested.
o SNPA: Sub-Network Point of Attachment (MAC address) of the o SNPA (MAC Address): Subnetwork Point of Attachment of the
INTERNET-DRAFT TRILL Use of IS-IS
neighbor. neighbor.
As specified in [RFC6327] and Section 4.4.2.1 of [RFC6325], all MAC As specified in [RFC7177] and Section 4.4.2.1 of [RFC6325], all MAC
addresses may fit into one TLV, in which case both the S and L flags addresses may fit into one TLV, in which case both the S and L flags
would be set to one in that TLV. If the MAC addresses don't fit into would be set to one in that TLV. If the MAC addresses don't fit into
one TLV, the highest MAC address in a TRILL Neighbor TLV with the L one TLV, the highest MAC address in a TRILL Neighbor TLV with the L
flag zero MUST also appear as a MAC address in some other TRILL flag zero MUST also appear as a MAC address in some other TRILL
Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the Neighbor TLV (possibly in a different TRILL IIH PDU). Also, the
lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST lowest MAC address in a TRILL Neighbor TLV with the S flag zero MUST
also appear in some other TRILL Neighbor TLV (possibly in a different also appear in some other TRILL Neighbor TLV (possibly in a different
TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send a TRILL IIH PDU). If an IS believes it has no neighbors, it MUST send
TRILL Neighbor TLV with an empty list of neighbor RECORDS, which will a TRILL Neighbor TLV with an empty list of neighbor RECORDS, which
have both the S and L bits on. will have both the S and L bits on.
INTERNET-DRAFT TRILL Use of IS-IS
3. MTU PDUs 3. MTU PDUs
The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine The IS-IS MTU-probe and MTU-ack PDUs are used to optionally determine
the MTU on a link between ISs as specified in Section 4.3.2 of the MTU on a link between ISs as specified in Section 4.3.2 of
[RFC6325] and in [RFC6327]. [RFC6325] and in [RFC7177].
The MTU PDUs have the IS-IS PDU common header (up through the Maximum The MTU PDUs have the IS-IS PDU common header (up through the Maximum
Area Addresses byte) with PDU Type numbers as indicated in Section 5. Area Addresses byte) with PDU Type numbers as indicated in Section 5.
They also have a common fixed MTU PDU header as shown below that is 8 They also have a common fixed MTU PDU header as shown below that is 8
+ 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes + 2*(ID Length) bytes long, 20 bytes in the case of the usual 6-bytes
System IDs. System IDs.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU Length | (2 bytes) | PDU Length | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe ID (6 bytes) | | Probe ID (6 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Probe Source ID (ID Length bytes) | | Probe Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
| Ack Source ID (ID Length bytes) | | Ack Source ID (ID Length bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....+-+-+
As with other IS-IS PDUs, the PDU length gives the length of the As with other IS-IS PDUs, the PDU Length gives the length of the
entire IS-IS packet starting with and including the IS-IS common entire IS-IS packet starting with and including the IS-IS common
header. header.
The Probe ID field is an opaque 48-bit quantity set by the IS issuing The Probe ID field is an opaque 48-bit quantity set by the IS issuing
an MTU-probe and copied by the responding IS into the corresponding an MTU-probe and copied by the responding IS into the corresponding
MTU-ack. For example, an IS creating an MTU-probe could compose this MTU-ack. For example, an IS creating an MTU-probe could compose this
quantity from a port identifier and probe sequence number relative to quantity from a port identifier and probe sequence number relative to
that port. that port.
The Probe Source ID is set by an IS issuing an MTU-probe to its The Probe Source ID is set by an IS issuing an MTU-probe to its
System ID and copied by the responding IS into the corresponding MTU- System ID and copied by the responding IS into the corresponding MTU-
ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored ack. The Ack Source ID is set to zero in MTU-probe PDUs and ignored
on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to on receipt. An IS issuing an MTU-ack sets the Ack Source ID field to
its System ID. The System ID length is usually 6 bytes but could be a its System ID. The System ID length is usually 6 bytes but could be
different value as indicated by the ID Length field in the IS-IS PDU a different value as indicated by the ID Length field in the IS-IS
Header. PDU Header.
The TLV area follows the MTU PDU header area. This area MAY contain The TLV area follows the MTU PDU header area. This area MAY contain
an Authentication TLV and MUST be padded with the Padding TLV to the an Authentication TLV and MUST be padded with the Padding TLV to the
exact size being tested. Since the minimum size of the Padding TLV is exact size being tested. Since the minimum size of the Padding TLV
2 bytes, it would be impossible to pad to exact size if the total is 2 bytes, it would be impossible to pad to exact size if the total
length of the required information bearing fixed fields and TLVs length of the required information-bearing fixed fields and TLVs
added up to 1 byte less than the desired length. However, the length added up to 1 byte less than the desired length. However, the length
of the fixed fields and substantive TLVs for MTU PDUs is expected to of the fixed fields and substantive TLVs for MTU PDUs is expected to
be quite small compared with their minimum length (minimum 1470-byte be quite small compared with their minimum length (minimum 1470-byte
MTU on an IEEE 802.3 link, for example), so this should not be a MTU on an IEEE 802.3 link, for example), so this should not be a
problem. problem.
INTERNET-DRAFT TRILL Use of IS-IS 4. Use of Existing PDUs and TLVs
4. Use of Existing PDUs and TLVs
The sub-sections below provide details of TRILL use of existing PDUs The sub-sections below provide details of TRILL use of existing PDUs
and TLVs. and TLVs.
4.1 TRILL IIH PDUs 4.1. TRILL IIH PDUs
The TRILL IIH PDU is the variation of the IIH PDU used by the TRILL The TRILL IIH PDU is the variation of the IIH PDU used by the TRILL
protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC6327] protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC7177]
specify the contents of the TRILL IIH and how its use in TRILL specify the contents of the TRILL IIH and how its use in TRILL
differs from Layer 3 LAN IIH PDU use. The adjacency state machinery differs from Layer 3 LAN IIH PDU use. The adjacency state machinery
for TRILL neighbors is specified in detail in [RFC6327]. for TRILL neighbors is specified in detail in [RFC7177].
In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header In a TRILL IIH PDU, the IS-IS common header and the fixed PDU Header
are the same as a Level 1 IIH PDU. are the same as a Level 1 IIH PDU.
The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored The IS-IS Neighbor TLV (6) is not used in a TRILL IIH and is ignored
if it appears there. Instead, TRILL LAN IIH PDUs use the TRILL if it appears there. Instead, TRILL LAN IIH PDUs use the TRILL
Neighbor TLV (see Section 2.5). Neighbor TLV (see Section 2.5).
4.2 Area Address 4.2. Area Address
TRILL uses a fixed zero Area Address as specified in [RFC6325], TRILL uses a fixed zero Area Address as specified in [RFC6325],
Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1) Section 4.2.3. This is encoded in a 4-byte Area Address TLV (TLV #1)
as follows: as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Area Address Type | (1 byte) | 0x01, Area Address Type | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02, Length of Value | (1 byte) | 0x02, Length of Value | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01, Length of Address | (1 byte) | 0x01, Length of Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00, zero Area Address | (1 byte) | 0x00, zero Area Address | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 Protocols Supported 4.3. Protocols Supported
NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL NLPID (Network Layer Protocol ID) 0xC0 has been assigned to TRILL
[RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including that [RFC6328]. A Protocols Supported TLV (#129, [RFC1195]) including
value appears in TRILL IIH PDUs and LSP number zero PDUs. that value appears in TRILL IIH PDUs and LSP number zero PDUs.
INTERNET-DRAFT TRILL Use of IS-IS
4.4 Link State PDUs (LSPs) 4.4. Link State PDUs (LSPs)
A number zero LSP MUST NOT be originated larger than 1470 bytes but a An LSP number zero MUST NOT be originated larger than 1470 bytes, but
larger number zero LSP successfully received MUST be processed and a larger LSP number zero successfully received MUST be processed and
forwarded normally. forwarded normally.
4.5 Originating LSP Buffer Size 4.5. Originating LSP Buffer Size
The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero; The originatingLSPBufferSize TLV (#14) MUST be in LSP number zero;
however, if found in other LSP fragments, it is processed normally. however, if found in other LSP fragments, it is processed normally.
Should there be more than one originatingLSPBufferSize TLV for an IS, Should there be more than one originatingLSPBufferSize TLV for an IS,
the minimum size, but not less than 1470, is used. the minimum size, but not less than 1470, is used.
INTERNET-DRAFT TRILL Use of IS-IS 5. IANA Considerations
5. IANA Considerations
This section gives IANA Considerations for the TLVs, sub-TLVs, and This section gives IANA considerations for the TLVs, sub-TLVs, and
PDUs specified herein. A number of new code points are assigned and PDUs specified herein. A number of new code points are assigned, and
those that were assigned by [RFC6326] are included here for those that were assigned by [RFC6326] are included here for
convenience. IANA is requested to replace all [RFC6326] references convenience. IANA has replaced all [RFC6326] references in the IANA
in the IANA Registries with references to this document. registries with references to this document.
5.1 TLVs 5.1. TLVs
This document specifies two IS-IS TLV types -- namely, the Group This document specifies two IS-IS TLV types -- namely, the Group
Address TLV (GADDR-TLV, type 142) and the TRILL Neighbor TLV (type Address TLV (GADDR-TLV; type 142) and the TRILL Neighbor TLV (type
145). The PDUs in which these TLVs are permitted for TRILL are shown 145). The PDUs in which these TLVs are permitted for TRILL are shown
in the table below along with the section of this document where they in the table below along with the section of this document where they
are discussed. The final "NUMBER" column indicates the permitted are discussed. The final "NUMBER" column indicates the permitted
number of occurrences of the TLV in their PDU, or set of PDUs in the number of occurrences of the TLV in their PDU, or set of PDUs in the
case of LSP, which in these two cases is "*" indicating that the TLV case of LSPs, which in these two cases is "*" indicating that the TLV
MAY occur 0, 1, or more times. MAY occur 0, 1, or more times.
IANA has registered these two code points in the IANA IS-IS TLV IANA has registered these two code points in the IANA IS-IS TLV
registry (ignoring the "Section" and "NUMBER" columns, which are registry (ignoring the "Section" and "NUMBER" columns, which are
irrelevant to that registry). irrelevant to that registry).
Section TLV IIH LSP SNP Purge NUMBER Section TLV IIH LSP SNP Purge NUMBER
======= === === === === ===== ====== ======= === === === === ===== ======
GADDR-TLV 2.1 142 - X - - * GADDR-TLV 2.1 142 n y n n *
TRILL Neighbor TLV 2.5 145 X - - - * TRILL Neighbor TLV 2.5 145 y n n n *
5.2 sub-TLVs
This document specifies a number of sub-TLVs. The TLVs in which these 5.2. Sub-TLVs
sub-TLVs occur are shown in the second table below along with the
section of this document where they are discussed. The TLVs within
which these sub-TLVs can occur are determined by the presence of an
"X" in the relevant column and the column header as shown in the
first table below. In some cases, the column header corresponds to
two different TLVs in which the sub-TLV can occur.
Column Head TLV RFCref TLV Name This document specifies a number of sub-TLVs. The TLVs in which
=========== ===== ======== ============== these sub-TLVs occur are shown in the second table below along with
Grp. Adr. 142 This doc Group Address the section of this document where they are discussed. The TLVs
within which these sub-TLVs can occur are determined by the presence
of an "X" in the relevant column; the column headers are described in
the first table below. In some cases, the column header corresponds
to two different TLVs in which the sub-TLV can occur.
MT Port 143 6165 MT-PORT-CAP Column Head TLV RFC TLV Name
=========== ===== ======== ==============
Grp. Adr. 142 7176 Group Address
MT Cap. 242 4971 Router CAPABILITY MT Port 143 6165 MT-Port-Cap-TLV
144 6329 MT-Capability
INTERNET-DRAFT TRILL Use of IS-IS MT Cap. 242 4971 Router CAPABILITY
144 6329 MT-Capability
Ext. Reach 22 5305 Extended IS Reachability Ext. Reach 22 5305 Extended IS Reachability
222 5120 MT ISN 222 5120 MT-ISN
The final "NUMBER" column below indicates the permitted number of The final "NUMBER" column below indicates the permitted number of
occurrences of the sub-TLV cumulatively within all occurrences of occurrences of the sub-TLV cumulatively within all occurrences of
their TLV(s) in those TLVs' carrying PDU (or set of PDUs in the case their TLV(s) in those TLVs' carrying a PDU (or set of PDUs in the
of LSP), as follows: case of LSPs), as follows:
0-1 = MAY occur zero or one times. 0-1 = MAY occur zero or one times.
1 = MUST occur exactly once. If absent, the PDU is ignored. If it 1 = MUST occur exactly once. If absent, the PDU is ignored. If it
occurs more than once, results are unspecified. occurs more than once, results are unspecified.
* = MAY occur 0, 1, or more times. * = MAY occur 0, 1, or more times.
The values in the "Section" and "NUMBER" columns are irrelevant to The values in the "Section" and "NUMBER" columns are irrelevant to
the IANA sub-registries. The numbers in square brackets are suggested the IANA sub-registries.
values.
sub- Grp. MT MT Ext. sub- Grp. MT MT Ext.
Name Section TLV# Adr. Port Cap. Reach NUMBER Name Section TLV# Adr. Port Cap. Reach NUMBER
================================================================= =================================================================
GMAC-ADDR 2.1.1 1 X - - - * GMAC-ADDR 2.1.1 1 X - - - *
GIP-ADDR 2.1.2 TBDa[2] X - - - * GIP-ADDR 2.1.2 2 X - - - *
GIPV6-ADDR 2.1.3 TBDb[3] X - - - * GIPV6-ADDR 2.1.3 3 X - - - *
GLMAC-ADDR 2.1.4 TBDc[4] X - - - * GLMAC-ADDR 2.1.4 4 X - - - *
GLIP-ADDR 2.1.5 TBDd[5] X - - - * GLIP-ADDR 2.1.5 5 X - - - *
GLIPV6-ADDR 2.1.6 TBDe[6] X - - - * GLIPV6-ADDR 2.1.6 6 X - - - *
VLAN-FLAGS 2.2.1 1 - X - - 1 VLAN-FLAGS 2.2.1 1 - X - - 1
Enabled-VLANs 2.2.2 2 - X - - * Enabled-VLANs 2.2.2 2 - X - - *
AppointedFwrdrs 2.2.3 3 - X - - * AppointedFwrdrs 2.2.3 3 - X - - *
PORT-TRILL-VER 2.2.4 TBDf[7] - X - - 0-1 PORT-TRILL-VER 2.2.4 7 - X - - 0-1
VLANs-Appointed 2.2.5 TBDg[8] - X - - * VLANs-Appointed 2.2.5 8 - X - - *
NICKNAME 2.3.2 6 - - X - * NICKNAME 2.3.2 6 - - X - *
TREES 2.3.3 7 - - X - 0-1 TREES 2.3.3 7 - - X - 0-1
TREE-RT-IDs 2.3.4 8 - - X - * TREE-RT-IDs 2.3.4 8 - - X - *
TREE-USE-IDs 2.3.5 9 - - X - * TREE-USE-IDs 2.3.5 9 - - X - *
INT-VLAN 2.3.6 10 - - X - * INT-VLAN 2.3.6 10 - - X - *
TRILL-VER 2.3.1 13 - - X - 0-1 TRILL-VER 2.3.1 13 - - X - 0-1
VLAN-GROUP 2.3.7 14 - - X - * VLAN-GROUP 2.3.7 14 - - X - *
INT-LABEL 2.3.8 TBDh[15] - - X - * INT-LABEL 2.3.8 15 - - X - *
RBCHANNELS 2.3.9 TBDi[16] - - X - * RBCHANNELS 2.3.9 16 - - X - *
AFFINITY 2.3.10 TBDj[17] - - X - * AFFINITY 2.3.10 17 - - X - *
LABEL-GROUP 2.3.11 TBDk[18] - - X - * LABEL-GROUP 2.3.11 18 - - X - *
MTU 2.4 28 - - - X 0-1 MTU 2.4 28 - - - X 0-1
================================================================= =================================================================
Name Section sub- Grp. MT MT Ext. NUMBER Name Section sub- Grp. MT MT Ext. NUMBER
TLV# Adr. Port Cap. Reach TLV# Adr. Port Cap. Reach
IANA is requested to enter the newly assigned sub-TLV numbers in the IANA has entered the newly assigned sub-TLV numbers in the above
above table in the one or two relevant existing sub-TLV registries, table in the relevant existing sub-TLV registries, as determined by
which column has an X for that sub-TLV. For the sub-TLVs from
INTERNET-DRAFT TRILL Use of IS-IS NICKNAME through and including VLAN-GROUP, which previously existed
only in the registry of sub-TLVs under TLV 242, IANA has added each
as determined by which column has an X opposite that sub-TLV. For the sub-TLV with the same sub-TLV number to the existing registry for
sub-TLVs from NICKNAME through and including VLAN-GROUP, which sub-TLVs under TLV 144.
currently exist only in the registry of sub-TLVs under TLV 242, IANA
is requested to add each sub-TLV with the same sub-TLV number to the
existing registry for sub-TLVs under TLV 144.
5.3 PDUs 5.3. PDUs
The IS-IS PDUs registry remains as established in [RFC6326] except The IS-IS PDUs registry remains as established in [RFC6326] except
that the references to [RFC6326] are updated to reference this that the references to [RFC6326] are updated to reference this
document. document.
5.4 Reserved and Capability Bits 5.4. Reserved and Capability Bits
Any reserved bits (R) or bits in reserved fields (RESV) or the Any reserved bits (R), bits in reserved fields (RESV), or
capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which capabilities bits in the PORT-TRILL-VER and TRILL-VER sub-TLVs, which
are specified herein as "MUST be sent as zero and ignored on receipt" are specified herein as "MUST be sent as zero and ignored on receipt"
or the like, are allocated based on IETF Review [RFC5226]. or the like, are allocated based on IETF Review [RFC5226].
Two sub-registries are created within the TRILL Parameters Registry Two sub-registries have been created within the TRILL Parameters
as follows: Registry as follows:
Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags Sub-Registry Name: TRILL-VER Sub-TLV Capability Flags
Registration Procedures: IETF Review Registration Procedures: IETF Review
Reference: (This document) Reference: (This document)
Bit Description Reference Bit Description Reference
===== ============= =========== ===== ============= ===========
0 Affinity sub-TLV support. [Affinity] 0 Affinity sub-TLV support. [Affinity]
1-13 Unassigned 1 FGL-safe [RFC7172]
14-31 Extended header flag support. [ExtendHeader] 2-13 Unassigned
14-31 Extended header flag support. [RFC7179]
Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags Sub-Registry Name: PORT-TRILL-VER Sub-TLV Capability Flags
Registration Procedures: IETF Review Registration Procedures: IETF Review
Reference: (This document) Reference: (This document)
Bit Description Reference Bit Description Reference
===== ============= =========== ===== ============= ===========
0 Hello reduction support. [ClearCorrect] 0 Hello reduction support. [RFC7180]
1-2 Unassigned 1-2 Unassigned
3-13 Hop-by-hop extended flag support. [ExtendHeader] 3-13 Hop-by-hop extended flag support. [RFC7179]
14-31 Unassigned 14-31 Unassigned
INTERNET-DRAFT TRILL Use of IS-IS
5.5 TRILL Neighbor Record Flags 5.5. TRILL Neighbor Record Flags
A sub-registry is created within the TRILL Parameters Registry as A sub-registry has been created within the TRILL Parameters Registry
follows: as follows:
Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags Sub-Registry Name: TRILL Neighbor TLV NEIGHBOR RECORD Flags
Registration Procedures: Standards Action Registration Procedures: Standards Action
Reference: (This document) Reference: (This document)
Bit Short Name Description Reference Bit Short Name Description Reference
============== ============= =========== ============== ============= ===========================
0 Fail Failed MTU test [RFC6325] 0 Fail Failed MTU test [RFC6325][RFC7176][RFC7177]
1 OOMF Offering OOMF service [ClearCorrect] 1 OOMF Offering OOMF service [RFC7180]
2-7 - Unassigned 2-7 - Unassigned
INTERNET-DRAFT TRILL Use of IS-IS
6. Security Considerations 6. Security Considerations
For general TRILL protocol security considerations, see the TRILL For general TRILL protocol security considerations, see the TRILL
base protocol standard [RFC6325]. base protocol standard [RFC6325].
This document raises no new security issues for IS-IS. IS-IS security This document raises no new security issues for IS-IS. IS-IS
may be used to secure the IS-IS messages discussed here. See security may be used to secure the IS-IS messages discussed here.
[RFC5304] and [RFC5310]. Even when IS-IS authentication is used, See [RFC5304] and [RFC5310]. Even when IS-IS authentication is used,
replays of Hello packets can create denial-of-service conditions; see replays of Hello packets can create denial-of-service conditions; see
[RFC6039] for details. These issues are similar in scope to those [RFC6039] for details. These issues are similar in scope to those
discussed in Section 6.2 of [RFC6325], and the same mitigations may discussed in Section 6.2 of [RFC6325], and the same mitigations may
apply. apply.
INTERNET-DRAFT TRILL Use of IS-IS 7. Changes from RFC 6326
7. Change from RFC 6326
Non-editorial changes from [RFC6326] are summarized in the list Non-editorial changes from [RFC6326] are summarized in the list
below: below:
1. Additional of five sub-TLVs under the Group Address (GADDR) TLV 1. Added five sub-TLVs under the Group Address (GADDR) TLV covering
covering VLAN labeled IPv4 and IPv6 addresses and fine-grained VLAN-labeled IPv4 and IPv6 addresses and fine-grained-labeled
labeled MAC, IPv4, and IPv6 addresses. (Sections 2.1.2, 2.1.3, MAC, IPv4, and IPv6 addresses (Sections 2.1.2, 2.1.3, 2.1.4,
2.1.4, 2.1.5, and 2.1.6). 2.1.5, and 2.1.6).
2. Addition of the PORT-TRILL-VER sub-TLV. (Section 2.2.4) 2. Added the PORT-TRILL-VER sub-TLV (Section 2.2.4).
3. Addition of the VLANs-Appointed sub-TLV. (Section 2.2.5) 3. Added the VLANs-Appointed sub-TLV (Section 2.2.5).
4. Change the TRILL-VER sub-TLV as listed below. 4. Changed the TRILL-VER sub-TLV as listed below.
4.a Addition of 4 bytes of TRILL Header extended flags and a. Added 4 bytes of TRILL Header extended flags and capabilities
capabilities supported information. supported information.
4.b Require that the TRILL-VER sub-TLV appear in LSP number zero. b. Required that the TRILL-VER sub-TLV appear in LSP number
zero.
The above changes to TRILL-VER are backwards compatible because The above changes to TRILL-VER are backward compatible because
the [RFC6326] conformant implementations of TRILL thus far have the [RFC6326]-conformant implementations of TRILL thus far have
only supported version zero and not supported any optional only supported version zero and not supported any optional
capabilities or extended flags, the level of support indicated by capabilities or extended flags, the level of support indicated by
the absence of the TRILL-VER sub-TLV. Thus, if an [RFC6326] the absence of the TRILL-VER sub-TLV. Thus, if an
conformant implementation of TRILL rejects this sub-TLV due to [RFC6326]-conformant implementation of TRILL rejects this sub-TLV
the changes specified in this document, it will, at worst, decide due to the changes specified in this document, it will, at worst,
that support of version zero and no extended flags or decide that support of version zero and no extended flags or
capabilities is indicated, which is the best an [RFC6326] capabilities is indicated, which is the best an
conformant implementation of TRILL can do anyway. Similarly, a [RFC6326]-conformant implementation of TRILL can do anyway.
TRILL implementation that supports TRILL-VER as specified herein Similarly, a TRILL implementation that supports TRILL-VER as
and rejects TRILL-VER sub-TLVs in an [RFC6326] conformant TRILL specified herein and rejects TRILL-VER sub-TLVs in an
implementation because they are not in LSP number zero will [RFC6326]-conformant TRILL implementation because they are not in
decide that that implementation supports only version zero with LSP number zero will decide that the implementation supports only
no extended flag or capabilities support, which will be correct. version zero with no extended flag or capabilities support, which
(Section 2.3.1) will be correct (Section 2.3.1).
5. Clarification of the use of invalid VLAN IDs (0x000 and 0xFFF) in 5. Clarified the use of invalid VLAN IDs (0x000 and 0xFFF) in the
the Appointed Forwarders sub-TLV and the Interested VLANs and Appointed Forwarders sub-TLV and the Interested VLANs and
Spanning Tree Roots sub-TLV. (Sections 2.2.3 and 2.3.6) Spanning Tree Roots sub-TLV (Sections 2.2.3 and 2.3.6).
6. Addition of the Interested Labels and Spanning Tree Roots sub-TLV 6. Added the Interested Labels and Spanning Tree Roots sub-TLV to
to indicate attachment of an IS to a fine-grained label [RFCfgl] indicate attachment of an IS to a fine-grained label [RFC7172]
analogous to the existing Interested VLANs and Spanning Tree analogous to the existing Interested VLANs and Spanning Tree
Roots sub-TLV for VLANs. (Section 2.3.8) Roots sub-TLV for VLANs (Section 2.3.8).
7. Addition of the RBridge Channel Protocols sub-TLV so ISs can
announce the RBridge Channel protocols they support. (Section
2.3.9)
INTERNET-DRAFT TRILL Use of IS-IS 7. Added the RBridge Channel Protocols sub-TLV so ISs can announce
the RBridge Channel protocols they support (Section 2.3.9).
8. Permit specification of the length of the link SNPA field in 8. Permitted specification of the length of the link SNPA field in
TRILL Neighbor TLVs. This change is backwards compatible because TRILL Neighbor TLVs. This change is backward compatible because
the size of 6 bytes is specially encoded as zero, the previous the size of 6 bytes is specially encoded as zero, the previous
value of the bits in the new SIZE field. (Section 2.5) value of the bits in the new SIZE field (Section 2.5).
9. Make the size of the MTU PDU Header Probe Source ID and Ack 9. Made the size of the MTU PDU Header Probe Source ID and Ack
Source ID fields be the ID Length from the IS-IS PDU Header Source ID fields be the ID Length from the IS-IS PDU Header
rather than the fixed value 6. (Section 3) rather than the fixed value 6 (Section 3).
10. For robustness, require LSP number zero PDUs be originated as no 10. For robustness, required that LSP number zero PDUs be originated
larger than 1470 bytes but processed regardless of size. (Section as no larger than 1470 bytes but processed regardless of size
4.4) (Section 4.4).
11. Require that the originatingLSPBufferSize TLV, if present, appear 11. Required that the originatingLSPBufferSize TLV, if present,
in LSP number zero. (Section 4.5) appear in LSP number zero (Section 4.5).
12. Create sub-registries for and specify the IANA Considerations 12. Created sub-registries for and specified the IANA Considerations
policy for reserved and capability bits in the TRILL version sub- policy for reserved and capability bits in the TRILL version sub-
TLVs. (Section 5.4) TLVs (Section 5.4).
13. Addition of the distribution tree Affinity sub-TLV so ISs can 13. Added the distribution tree Affinity sub-TLV so ISs can request
request distribution tree attachments. (Section 2.3.10) distribution tree attachments (Section 2.3.10).
14. Add LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV. 14. Added the LABEL-GROUP sub-TLV analogous to the VLAN-GROUP sub-TLV
(Section 2.3.11) (Section 2.3.11).
15. Add multi-topology: permit sub-TLVs previously only in Router 15. Added multi-topology to permit sub-TLVs previously only in the
Capabilities TLV to also appear in MT Capabilities TLV; permit Router Capability TLV to also appear in the MT-Capability TLV and
MTU sub-TLV previously limited to Extended Reachability TLV to to permit the MTU sub-TLV previously limited to the Extended
also appear in MT ISN TLV. Reachability TLV to also appear in the MT-ISN TLV.
16. Addition of a sub-registry for Neighbor TLV Neighbor RECORD flag 16. Added a sub-registry for Neighbor TLV Neighbor RECORD flag bits
bits. (Section 5.5) (Section 5.5).
17. Explicitly state that if the number of sources in a GADDR-TLV 17. Explicitly stated that if the number of sources in a GADDR-TLV
sub-TLV is zero, it indicates a listener for (*,G), that is, a sub-TLV is zero, it indicates a listener for (*,G), that is, a
listener not restricted by source. (Section 2.1) listener not restricted by source (Section 2.1).
INTERNET-DRAFT TRILL Use of IS-IS
8. Normative References
[ISO-10589] - ISO/IEC 10589:2002, Second Edition, "Intermediate
System to Intermediate System Intra-Domain Routing Exchange
Protocol for use in Conjunction with the Protocol for Providing
the Connectionless-mode Network Service (ISO 8473)", 2002.
[RFC1195] - Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", 1990.
[RFC1982] - Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
1982, August 1996.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4971] - Vasseur, JP. and N. Shen, "Intermediate System to
Intermediate System (IS-IS) Extensions for Advertising Router
Information", 2007.
[RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Intermediate
Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 8. References
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
2008.
[RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 8.1. Normative References
Engineering", 2008.
[RFC6165] - Banerjee, A. and D. Ward, "Extensions to IS-IS for [ISO-10589]
Layer-2 Systems", RFC 6165, April 2011. International Organization for Standardization,
"Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", Second
Edition, November 2002.
[RFC6325] - Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
Ghanwani, "RBridges: Base Protocol Specification", RFC 6325, dual environments", RFC 1195, December 1990.
June 2011.
[RFC6327] - Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
Manral, "RBridges: Adjacency", RFC 6327, July 2011. August 1996.
[RFC6328] - Eastlake, D., "IANA Considerations for Network Layer [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Protocol Identifiers", RFC 6328, June 2011. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6329] - Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq "Intermediate System to Intermediate System (IS-IS)
Shortest Path Bridging", RFC 6329, April 2012. Extensions for Advertising Router Information", RFC 4971,
July 2007.
[RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
INTERNET-DRAFT TRILL Use of IS-IS [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
6439, November 2011. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[Channel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward, [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2
draft-ietf-trill-rbridge-channel, in RFC Editor's queue. Systems", RFC 6165, April 2011.
[ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A. [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Banerjee, draft-ietf-trill-clear-correct, in RFC Editor's Ghanwani, "Routing Bridges (RBridges): Base Protocol
queue. Specification", RFC 6325, July 2011.
[ExtendHeader] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. [RFC6328] Eastlake 3rd, D., "IANA Considerations for Network Layer
Bestler, draft-ietf-trill-rbridge-extension, in RFC Editor's Protocol Identifiers", BCP 164, RFC 6328, July 2011.
queue.
[RFCfgl] - Eastlake, D., M. Zhang, P. Agarwal, R. Perlman, D. Dutt, [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg,
"TRILL (Transparent Interconnection of Lots of Links): Fine- A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE
Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 802.1aq Shortest Path Bridging", RFC 6329, April 2012.
Ediotr's queue.
9. Informative References [RFC6439] Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
Hu, "Routing Bridges (RBridges): Appointed Forwarders",
RFC 6439, November 2011.
[Err2869] - RFC Errata, Errata ID 2869, RFC 6326, http://www.rfc- [RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
editor.org. D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, May 2014.
[RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic [RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, Y., and
Authentication", RFC 5304, October 2008. V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014.
[RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC7178] Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC Ward, "Transparent Interconnection of Lots of Links
5310, February 2009. (TRILL): RBridge Channel Support", RFC 7178, May 2014.
[RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White, [RFC7179] Eastlake 3rd, D., Ghanwani, A., Manral, V., Li, Y., and C.
"Issues with Existing Cryptographic Protection Methods for Bestler, "Transparent Interconnection of Lots of Links
Routing Protocols", RFC 6039, October 2010. (TRILL): Header Extension", RFC 7179, May 2014.
[RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. [RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) A. Banerjee, "Transparent Interconnection of Lots of
Use of IS-IS", RFC 6326, July 2011. Links (TRILL): Clarifications, Corrections, and Updates",
RFC 7180, May 2014.
[RFC7042] - Eastlake 3rd, D. and J. Abley, "IANA Considerations and 8.2. Informative References
IETF Protocol and Documentation Usage for IEEE 802 Parameters",
BCP 141, RFC 7042, October 2013.
[RFCtrillBFD] - V. Manral, D, Eastlake, D. Ward, A. Banerjee, draft- [Err2869] RFC Errata, Errata ID 2869, RFC 6326,
ietf-trill-rbridge-bfd-07.txt, in RFC Editor's queue. <http://www.rfc-editor.org>.
[Affinity] - draft-ietf-trill-cmt, work in progress. [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
INTERNET-DRAFT TRILL Use of IS-IS [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
progress. with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010.
[Resilient] - draft-zhang-trill-resilient-trees, work in progress. [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "Transparent Interconnection of Lots of Links
(TRILL) Use of IS-IS", RFC 6326, July 2011.
INTERNET-DRAFT TRILL Use of IS-IS [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and
IETF Protocol and Documentation Usage for IEEE 802
Parameters", BCP 141, RFC 7042, October 2013.
Acknowledgements [RFC7175] Manral, V., Eastlake 3rd, D., Ward, D., and A. Banerjee,
"Transparent Interconnection of Lots of Links (TRILL):
Bidirectional Forwarding Detection (BFD) Support", RFC
7175, May 2014.
The authors gratefully acknowledge the contributions and review by [Affinity] Senevirathne, T., Pathangi, J., and J. Hudson,
the following: "Coordinated Multicast Trees (CMT) for TRILL", Work in
Progress, April 2014.
Ross Callon, Spencer Dawkins, Adrian Farrel, Alexey Melnikov, [MultiLevel]
Radia Perlman, Carlos Pignataro, Joe Touch. Perlman, R., Eastlake 3rd, D., Ghanwani, A., and H. Zhai,
"Flexible Multilevel TRILL (Transparent Interconnection of
Lots of Links)", Work in Progress, January 2014.
And the contributions by the following to [RFC6326]: [Resilient]
Zhang, M. Senevirathne, T., Pathangi, J., Banerjee, A.,
and A. Ghanwani, "TRILL Resilient Distribution Trees",
Work in Progress, December 2013.
Mike Shand, Stewart Bryant, Dino Farinacci, Les Ginsberg, Sam 9. Acknowledgements
Hartman, Dan Romascanu, Dave Ward, and Russ White. In particular,
thanks to Mike Shand for the detailed and helpful comments.
This document was produced with raw nroff. All macros used were The authors gratefully acknowledge the contributions and reviews by
defined in the source files. the following individuals: Ross Callon, Spencer Dawkins, Adrian
Farrel, Alexey Melnikov, Radia Perlman, Carlos Pignataro, and Joe
Touch.
INTERNET-DRAFT TRILL Use of IS-IS The authors also acknowledge the contributions to [RFC6326] by the
following individuals: Mike Shand, Stewart Bryant, Dino Farinacci,
Les Ginsberg, Sam Hartman, Dan Romascanu, Dave Ward, and Russ White.
In particular, thanks to Mike Shand for his detailed and helpful
comments.
Authors' Addresses Authors' Addresses
Donald Eastlake Donald Eastlake 3rd
Huawei Technologies Huawei Technologies
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757
USA
Phone: +1-508-333-2270 Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com EMail: d3e3e3@gmail.com
Tissa Senevirathne Tissa Senevirathne
Cisco Systems Cisco Systems
375 East Tasman Drive, 375 East Tasman Drive,
San Jose, CA 95134 San Jose, CA 95134
USA
Phone: +1-408-853-2291 Phone: +1-408-853-2291
EMail: tsenevir@cisco.com EMail: tsenevir@cisco.com
Anoop Ghanwani Anoop Ghanwani
Dell Dell
350 Holger Way 5450 Great America Parkway
San Jose, CA 95134 USA Santa Clara, CA 95054
USA
Phone: +1-408-571-3500
EMail: anoop@alumni.duke.edu EMail: anoop@alumni.duke.edu
Dinesh Dutt Dinesh Dutt
Cumulus Networks Cumulus Networks
1089 West Evelyn Avenue 1089 West Evelyn Avenue
Sunnyvale, CA 94086 USA Sunnyvale, CA 94086
USA
EMail: ddutt.ietf@hobbesdutt.com EMail: ddutt.ietf@hobbesdutt.com
Ayan Banerjee Ayan Banerjee
Insieme Networks Insieme Networks
210 West Tasman Drive 210 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134
USA
Email: ayabaner@gmail.com
INTERNET-DRAFT TRILL Use of IS-IS
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal EMail: ayabaner@gmail.com
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
 End of changes. 386 change blocks. 
1187 lines changed or deleted 1096 lines changed or added

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