draft-ietf-isis-rfc6326bis-00.txt   draft-ietf-isis-rfc6326bis-01.txt 
Network Working Group Donald Eastlake Network Working Group Donald Eastlake
INTERNET-DRAFT Huawei INTERNET-DRAFT Huawei
Intended status: Proposed Standard Tissa Senevirathne Intended status: Proposed Standard Tissa Senevirathne
Obsoletes: 6326 Cisco Obsoletes: 6326 Cisco
Anoop Ghanwani Anoop Ghanwani
Dell Dell
Dinesh Dutt Dinesh Dutt
Ayan Banerjee
Cumulus Networks Cumulus Networks
Expires: April 11, 2013 October 12, 2012 Ayan Banerjee
Insieme Networks
Expires: October 7, 2013 April 8, 2013
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-00.txt> <draft-ietf-isis-rfc6326bis-01.txt>
Abstract Abstract
The IETF TRILL (Transparent Interconnection of Lots of Links) The IETF TRILL (Transparent Interconnection of Lots of Links)
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, and support for multipathing of both unicast and
multicast traffic. This document specifies the data formats and code multicast traffic. This document specifies the data formats and code
points for the IS-IS extensions to support TRILL. These data formats points for the IS-IS extensions to support TRILL. These data formats
and code points may also be used by technologies other than TRILL. and code points may also be used by technologies other than TRILL.
skipping to change at page 2, line 54 skipping to change at page 2, line 54
4.4 Link State PDUs (LSPs)..............................36 4.4 Link State PDUs (LSPs)..............................36
4.5 Originating LSP Buffer Size.........................36 4.5 Originating LSP Buffer Size.........................36
5. IANA Considerations....................................37 5. IANA Considerations....................................37
5.1 TLVs................................................37 5.1 TLVs................................................37
5.2 sub-TLVs............................................37 5.2 sub-TLVs............................................37
5.3 PDUs................................................39 5.3 PDUs................................................39
5.4 Reserved and Capability Bits........................39 5.4 Reserved and Capability Bits........................39
5.5 TRILL Neighbor Record Flags.........................39 5.5 TRILL Neighbor Record Flags.........................39
6. Security Considerations................................41 6. Security Considerations................................41
7. Change from RFC 6326...................................42 7. Change from RFC 6326...................................42
8. Normative References...................................44 8. Normative References...................................44
9. Informative References.................................45 9. Informative References.................................45
Acknowledgements..........................................47 Acknowledgements..........................................46
Authors' Addresses........................................47
INTERNET-DRAFT TRILL Use of IS-IS INTERNET-DRAFT TRILL Use of IS-IS
1. Introduction 1. Introduction
The IETF TRILL (Transparent Interconnection of Lots of Links) The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol [RFC6325] [RFC6327] provides transparent forwarding in protocol [RFC6325] [RFC6327] provides transparent forwarding in
multi-hop networks with arbitrary topology and link technologies multi-hop networks with arbitrary topology and link technologies
using encapsulation 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 RBridges (Routing
Bridges) or TRILL Switches. Bridges) 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.
skipping to change at page 12, line 44 skipping to change at page 12, line 44
PDU is being sent as specified in [RFC6325], Section 4.4.2. 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 Sender Nickname: If the sending IS is holding any nicknames as
discussed in [RFC6325], Section 3.7, one MUST be included here. discussed in [RFC6325], Section 3.7, one MUST be included here.
Otherwise, the field is set to zero. This field is to support Otherwise, the field is set to zero. This field is to support
intelligent end stations that determine the egress IS (RBridge) intelligent end stations that determine the egress IS (RBridge)
for unicast data through a directory service or the like and for unicast data through a directory service or the like and
that need a nickname for their first hop to insert as the that need a nickname for their first hop to insert as the
ingress nickname to correctly format a TRILL Data frame (see ingress nickname to correctly format a TRILL Data frame (see
[RFC6325], Section 4.6.2, point 8). It is also referenced in [RFC6325], Section 4.6.2, point 8). It is also referenced in
connection with the VLANs Appointed Sub-TLV (see Section connection with the VLANs Appointed Sub-TLV (see Section 2.2.5)
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 Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH
frame containing this sub-TLV, as specified in [RFC6325], frame containing this sub-TLV, as specified in [RFC6325],
Section 4.4.5. Section 4.4.5.
o Desig.VLAN: The 12-bit ID of the Designated VLAN for the link, o Desig.VLAN: The 12-bit ID of the Designated VLAN for the link,
as specified in [RFC6325], Section 4.2.4.2. as specified in [RFC6325], Section 4.2.4.2.
INTERNET-DRAFT TRILL Use of IS-IS INTERNET-DRAFT TRILL Use of IS-IS
skipping to change at page 16, line 32 skipping to change at page 16, line 32
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 of
TRILL version sub-TLV(s) uses the TRILL version it received in PORT- TRILL version sub-TLV(s) uses the TRILL version it received in PORT-
TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub- TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub-
TLV(s). TLV(s).
2.2.5 VLANs Appointed Sub-TLV 2.2.5 VLANs Appointed Sub-TLV
The optional VLANs sub-TLV specifies the VLANs for which the port of The optional VLANs sub-TLV specifies, for the port of the originating
the originating IS on which the containing Hello was sent is IS on which the containing Hello was sent, the VLANs for which it is
appointed forwarder. It has the following format: 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....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 15 skipping to change at page 17, line 15
INTERNET-DRAFT TRILL Use of IS-IS 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 originating IS If this sub-TLV occurs more than once in a Hello, the originating IS
is declaring it believes itself to be appointed forwarder on the port is declaring that it believes itself to be appointed forwarder on the
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 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 sub-sections of this Section
2.3 below specify sub-TLVs that can be carried in the Router 2.3 below specify sub-TLVs that can be carried in the Router
Capability TLV (#242) and the MT (multi-topology) Capability TLV Capability TLV (#242) and the MT (multi-topology) Capability TLV
(#144) with the same sub-TLV number for both TLVs. These TLVs are in (#144) with the same sub-TLV number for both TLVs. These TLVs are in
turn carried only by LSPs. turn carried only by LSPs.
skipping to change at page 18, line 22 skipping to change at page 18, line 22
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 [ExtendHeader] 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, MUST occur in a Router Capabilities TLV in This sub-TLV, if present in a Router Capabilities TLV, MUST occur in
the LSP number zero for the originating IS. If found in other the LSP number zero for the originating IS. If found in a Router
fragments, it is ignored. If there is more than one occurrence in LSP Capabilities TLV in other fragments, it is ignored. If there is more
number zero, the minimum of the supported versions is assumed to be than one occurrence in LSP number zero, the minimum of the supported
correct and an extended header flag or capability is assumed to be versions is assumed to be correct and an extended header flag or
supported only if indicated by all occurrences. The flags and capability is assumed to be supported only if indicated by all
capabilities supported bits in this sub-TLV are disjoint from those occurrences. The flags and capabilities supported bits in this sub-
in the PORT-TRILL-VER sub-TLV (Section 2.2.4) so they cannot TLV are disjoint from those in the PORT-TRILL-VER sub-TLV (Section
conflict. However, the TRILL version is the same as that in the PORT- 2.2.4) so they cannot conflict. However, the TRILL version is the
TRILL-VER sub-TLV and an IS that is adjacent to the originating IS of same as that in the PORT-TRILL-VER sub-TLV and an IS that is adjacent
TRILL-VER sub-TLV(s) uses the TRILL version it received in PORT- to the originating IS of TRILL-VER sub-TLV(s) uses the TRILL version
TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER sub- it received in PORT-TRILL-VER sub-TLV(s) in preference to that
TLV(s). 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. Such announcements for non-zero topologies need not occur not occur in an MT Capabilities TLV. Such announcements for non-zero
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 as specified in [RFC6325], about its priority to hold those nicknames and the priority for each
Section 3.7.3. Multiple instances of this sub-TLV may occur. nickname to be a tree root as specified in [RFC6325] Section 3.7.3.
Multiple instances of this sub-TLV may occur.
INTERNET-DRAFT TRILL Use of IS-IS 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 15 skipping to change at page 30, line 15
INTERNET-DRAFT TRILL Use of IS-IS 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 Label IDs. This sub- The Label Group sub-TLV consists of two or more fine-grained label
TLV indicates that shared Label MAC address learning is occurring at IDs. This sub-TLV indicates that shared Label MAC address learning
the announcing IS between the listed Labels. It is structured as is occurring at the announcing IS between the listed Labels. It is
follows: 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 49 skipping to change at page 30, line 49
o Secondary Label ID: This identifies a secondary Label in the Label o Secondary Label ID: This identifies a secondary Label in the Label
Group. 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 Ext. 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 specified in [RFC6325] Section 4.2.4.4. It occurs within the Extended
Extended Reachability (#22) and MT (multi-topology) ISN (Intermediate Reachability (#22) and MT (multi-topology) ISN (Intermediate System
System Neighbors) (#222) TLVs. Neighbors) (#222) TLVs.
INTERNET-DRAFT TRILL Use of IS-IS 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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 31, line 33 skipping to change at page 31, line 33
the required campus-wide MTU. 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 IIH PDUs (see Section 4.1 The TRILL Neighbor TLV is used in TRILL broadcast link IIH PDUs (see
below) in place of the IS Neighbor TLV, as specified in Section Section 4.1 below) in place of the IS Neighbor TLV, as specified in
4.4.2.1 of [RFC6325] and in [RFC6327]. The structure of the TRILL Section 4.4.2.1 of [RFC6325] and in [RFC6327]. The structure of the
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 48 skipping to change at page 34, line 48
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 a
different value as indicated by the ID Length field in the IS-IS PDU different value as indicated by the ID Length field in the IS-IS PDU
Header. 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 to the exact size being an Authentication TLV and MUST be padded with the Padding TLV to the
tested with the Padding TLV. Since the minimum size of the Padding exact size being tested. Since the minimum size of the Padding TLV is
TLV is 2 bytes, it would be impossible to pad to exact size if the 2 bytes, it would be impossible to pad to exact size if the total
total length of the required information bearing fixed fields and length of the required information bearing fixed fields and TLVs
TLVs added up to 1 byte less than the desired length. However, the added up to 1 byte less than the desired length. However, the length
length of the fixed fields and substantive TLVs for MTU PDUs is of the fixed fields and substantive TLVs for MTU PDUs is expected to
expected to be quite small compared with their minimum length be quite small compared with their minimum length (minimum 1470-byte
(minimum 1470-byte MTU on an IEEE 802.3 link, for example), so this MTU on an IEEE 802.3 link, for example), so this should not be a
should not be a problem. problem.
INTERNET-DRAFT TRILL Use of IS-IS 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 LAN IIH PDU used by the The TRILL IIH PDU is the variation of the IIH PDU used by the TRILL
TRILL protocol. Section 4.4 of the TRILL standard [RFC6325] and protocol. Section 4.4 of the TRILL standard [RFC6325] and [RFC6327]
[RFC6327] specify the contents of the TRILL IIH and how its use in specify the contents of the TRILL IIH and how its use in TRILL
TRILL differs from Layer 3 LAN IIH PDU use. The adjacency state differs from Layer 3 LAN IIH PDU use. The adjacency state machinery
machinery for TRILL neighbors is specified in detail in [RFC6327]. for TRILL neighbors is specified in detail in [RFC6327].
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 LAN IIH PDU. The Maximum Area Addresses are the same as a Level 1 IIH PDU.
octet in the common header MUST be set to 0x01.
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 IIH PDUs use the TRILL Neighbor if it appears there. Instead, TRILL LAN IIH PDUs use the TRILL
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)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 48 skipping to change at page 35, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 that
value MUST appear in TRILL IIH PDUs and LSP number zero PDUs. value appears in TRILL IIH PDUs and LSP number zero PDUs.
INTERNET-DRAFT TRILL Use of IS-IS 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 A number zero LSP MUST NOT be originated larger than 1470 bytes but a
larger number zero LSP successfully received MUST be processed and larger number zero LSP 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 INTERNET-DRAFT TRILL Use of IS-IS
5. IANA Considerations 5. IANA Considerations
This section give IANA Considerations for the TLVs, sub-TLVs, and This section gives IANA Considerations for the TLVs, sub-TLVs, and
PDUs specified herein. PDUs specified herein.
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
skipping to change at page 42, line 45 skipping to change at page 42, line 45
that support of version zero and no extended flags or 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 [RFC6326]
conformant implementation of TRILL can do anyway. Similarly, a conformant implementation of TRILL can do anyway. Similarly, a
TRILL implementation that supports TRILL-VER as specified herein TRILL implementation that supports TRILL-VER as specified herein
and rejects TRILL-VER sub-TLVs in an [RFC6326] conformant TRILL and rejects TRILL-VER sub-TLVs in an [RFC6326] conformant TRILL
implementation because they are not in LSP number zero will implementation because they are not in LSP number zero will
decide that that implementation supports only version zero with decide that that implementation supports only version zero with
no extended flag or capabilities support, which will be correct. no extended flag or capabilities support, which will be correct.
(Section 2.3.1) (Section 2.3.1)
5. Clarification of the use of invalid VLAN IDs in the Appointed 5. Clarification of the use of invalid VLAN IDs (0x000 and 0xFFF) in
Forwarders sub-TLV and the Interested VLANs and Spanning Tree the Appointed Forwarders sub-TLV and the Interested VLANs and
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. Addition of the Interested Labels and Spanning Tree Roots sub-TLV
to indicate attachment of an IS to a fine-grained label analogous to indicate attachment of an IS to a fine-grained label analogous
to the existing Interested VLANs and Spanning Tree Roots sub-TLV to the existing Interested VLANs and Spanning Tree Roots sub-TLV
for VLANs. (Section 2.3.8) for VLANs. (Section 2.3.8)
7. Addition of the RBridge Channel Protocols sub-TLV so ISs can 7. Addition of the RBridge Channel Protocols sub-TLV so ISs can
announce the RBridge Channel protocols they support. (Section announce the RBridge Channel protocols they support. (Section
2.3.9) 2.3.9)
skipping to change at page 45, line 22 skipping to change at page 45, line 22
[ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A. [ClearCorrect] - D. Eastlake, M. Zhang, A. Ghanwani, V. Manral, A.
Banerjee, draft-ietf-trill-clear-correct, in RFC Editor's Banerjee, draft-ietf-trill-clear-correct, in RFC Editor's
queue. queue.
[ExtendHeader] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C. [ExtendHeader] - D. Eastlake, A. Ghanwani, V. Manral, Y. Li, C.
Bestler, draft-ietf-trill-rbridge-extension, in RFC Editor's Bestler, draft-ietf-trill-rbridge-extension, in RFC Editor's
queue. queue.
9. Informative References 9. Informative References
[802.1D-2004] - "IEEE Standard for Local and metropolitan area
networks / Media Access Control (MAC) Bridges", 802.1D-2004, 9
June 2004.
[802.1Q-2011] - "IEEE Standard for Local and metropolitan area
networks / Virtual Bridged Local Area Networks", 802.1Q-2011,
31 August 2011.
[Err2869] - RFC Errata, Errata ID 2869, RFC 6326, http://www.rfc- [Err2869] - RFC Errata, Errata ID 2869, RFC 6326, http://www.rfc-
editor.org. editor.org.
[RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic [RFC5304] - Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008. Authentication", RFC 5304, October 2008.
[RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] - Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC
5310, February 2009. 5310, February 2009.
skipping to change at page 45, line 52 skipping to change at page 45, line 44
2008. 2008.
[RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White, [RFC6039] - Manral, V., Bhatia, M., Jaeggli, J., and R. White,
"Issues with Existing Cryptographic Protection Methods for "Issues with Existing Cryptographic Protection Methods for
Routing Protocols", RFC 6039, October 2010. Routing Protocols", RFC 6039, October 2010.
[RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. [RFC6326] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A.
Ghanwani, "Transparent Interconnection of Lots of Links (TRILL) Ghanwani, "Transparent Interconnection of Lots of Links (TRILL)
Use of IS-IS", RFC 6326, July 2011. Use of IS-IS", RFC 6326, July 2011.
[Affinity] - draft-ietf-trill-cmt, work in progress. [RFCtrillBFD] - V. Manral, D, Eastlake, D. Ward, A. Banerjee, draft-
ietf-trill-rbridge-bfd, in RFC Editor's queue.
INTERNET-DRAFT TRILL Use of IS-IS [Affinity] - draft-ietf-trill-cmt, work in progress.
[MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in [MultiLevel] - draft-perlman-trill-rbridge-multilevel, work in
progress. progress.
[Resilient] - draft-zhang-trill-resilient-trees, work in progress. [Resilient] - draft-zhang-trill-resilient-trees, work in progress.
INTERNET-DRAFT TRILL Use of IS-IS INTERNET-DRAFT TRILL Use of IS-IS
Acknowledgements Acknowledgements
skipping to change at page 48, line 41 skipping to change at page 47, line 41
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
Cumulus Networks Insieme Networks
1089 West Evelyn Avenue 210 West Tasman Drive
Sunnyvale, CA 94086 USA San Jose, CA 95134 USA
EMail: ayabaner@gmail.com Email: ayabaner@gmail.com
INTERNET-DRAFT TRILL Use of IS-IS INTERNET-DRAFT TRILL Use of IS-IS
Copyright, Disclaimer, and Additional IPR Provisions Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
 End of changes. 28 change blocks. 
79 lines changed or deleted 75 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/