IS-IS Extended HierarchyArista Networks5453 Great America ParkwaySanta ClaraCalifornia95054United States of Americatony.li@tony.liCisco SystemsUnited States of Americaginsberg@cisco.comCisco SystemsUnited States of Americapauwells@cisco.com
Routing
Internet Engineering Task ForceIS-IS multi-level hierarchical link-state routingThe IS-IS routing protocol was originally defined with a two level
hierarchical structure. This was adequate for the networks at the time.
As we continue to expand the scale of our networks, it is apparent that
additional hierarchy would be a welcome degree of flexibility in network
design.This document defines IS-IS Levels 3 through 8.The IS-IS routing protocol IS-IS
currently supports a two level hierarchy of abstraction. The fundamental
unit of abstraction is the 'area', which is a (hopefully) connected set
of systems running IS-IS at the same level. Level 1, the lowest level,
is abstracted by routers that participate in both Level 1 and Level
2.Practical considerations, such as the size of an area's link state
database, cause network designers to restrict the number of routers in
any given area. Concurrently, the dominance of scale-out architectures
based around small routers has created a situation where the scalability
limits of the protocol are going to become critical in the foreseeable
future.The goal of this document is to enable additional hierarchy within
IS-IS. Each additional level of hierarchy has a multiplicative effect on
scale, so the addition of six levels should be a significant
improvement. While all six levels may not be needed in the short term,
it is apparent that the original designers of IS-IS reserved enough
space for these levels, and defining six additional levels is only
slightly harder than adding a single level, so it makes sense to expand
the design for the future.The modifications described herein are designed to be fully backward
compatible and have no effect on existing networks. The modifications
are also designed to have no effect whatsoever on networks that only use
Level 1 and/or Level 2.Section references in this document are references to sections of
IS-IS.Note that uses a bit encoding convention
where bit numbers are 1 based and Bit 1 is the Least Significant Bit
(LSB) of the datatype. Traditionally IETF documents have used a bit
encoding convention where bit numbers are 0 based and Bit 0 is the Most
Significant Bit (MSB) of the datatype. This document uses conventions throughout.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 when, and only
when, they appear in all capitals, as shown here.In this section, we enumerate all of the redefinitions of protocol
header fields necessary to add additional levels.In the fixed header of some IS-IS PDUs, a field is named
'Reserved/Circuit Type' (Section 9.5). The high order six bits are
reserved, with the low order two bits indicating Level 1 (bit 1) and
Level 2 (bit 2).This field is renamed to be 'Circuit Type'. The bits are redefined
as follows: Level 1Level 2Level 3Level 4Level 5Level 6Level 7Level 8 The value of zero (no bits set) is reserved. PDUs with a
Circuit Type of zero SHALL be ignored.The set bits of the Circuit Type MUST be contiguous. If bit n and
bit m are set in the Circuit Type, then all bits in the interval [n:m]
must be set.The fixed header of IS-IS PDUs contains an octet with three
reserved bits and the 'PDU Type' field. The three reserved bits are
transmitted as zero and ignored on receipt. (Section 9.5)To allow for additional PDU space, this entire octet is renamed the
'PDU Type' field.The 'Level n LAN IS to IS hello PDU' (Ln-LAN-HELLO-PDU) is
identical in format to the 'Level 2 LAN IS to IS hello PDU' (Section
9.6), except that the PDU Types are defined as follows: Level 3 (L3-LAN-HELLO-PDU): 33 (Suggested - to be assigned by
IANA)Level 4 (L4-LAN-HELLO-PDU): 34 (Suggested - to be assigned by
IANA)Level 5 (L5-LAN-HELLO-PDU): 35 (Suggested - to be assigned by
IANA)Level 6 (L6-LAN-HELLO-PDU): 36 (Suggested - to be assigned by
IANA)Level 7 (L7-LAN-HELLO-PDU): 37 (Suggested - to be assigned by
IANA)Level 8 (L8-LAN-HELLO-PDU): 38 (Suggested - to be assigned by
IANA)The Circuit Type field MUST be set to indicate all levels supported
on that circuit - not just the level associated with the containing
PDU type.The 'Point-to-point IS to IS hello PDU' (Section 9.7) is used on
Level 1 and Level 2 circuits. Legacy systems will not expect the
circuit type field to indicate other levels, so a new PDU is used if
the circuit supports other levels. The additional PDU is the 'Level n
Point-to-point IS to IS hello PDU' (Ln-P2P-HELLO-PDU) and has PDU Type
39 (Suggested - to be assigned by IANA). The format of this PDU is
identical to the existing Point-to-Point IS to IS hello PDU. Both PDUs
may be used on the same circuit. defines an Area Address to uniquely
identify a Level-1 area. A given area may have multiple synonymous area
addresses - which is useful in support of hitless merging or splitting
of areas. Area address matching is part of the adjacency formation rules
defined in Section 8 which determine whether a given adjacency supports
Level-1, Level-2, or both. Area addresses are advertised in IIHs and
LSPs using the Area Address TLV.With the extensions defined in this document, there is a need to
define an equivalent identifier for Levels 2-8. The Level Specific Area
Identifier (LSAI) is a 16 bit value and is advertised using the new Area
Hierarchy TLV defined in . There is no
relationship between a Level-1 Area Address and an LSAI.Just as with Area Addresses, multiple synonomous LSAIs may be
assigned to a given level. This supports hitless merging or splitting of
the level specific area. Although it is legal to do so, it is generally
not useful to define more than two Area Identifiers for a given
level.A node MAY support any set of contiguous levels. Support for
non-contiguous levels is undefined.The Area Hierarchy TLV specifies the set of LSAIs which comprise
the branch of the network hierarchy to which the advertising node is
connected. The TLV MUST include at least one LSAI for Levels 2-N,
where N is >= 2 and N represents the highest level supported in the
IS-IS domain. It is RECOMMENDED that N == 8 even when not all 8 levels
are currently in use, but in cases where a network does not support
higher levels a number less than 8 MAY be used.Note that the levels advertised MAY include levels which are not
supported by the advertising node.The Area Hierarchy TLV has the following format:The Area Hierarchy TLV MUST appear in all new IIH PDUs defined in
. It MAY appear in P2P-HELLO-PDUs,
L1-LAN-HELLO-PDUs, or L2-LAN-HELLO-PDUs.The Area Hierarchy TLV MUST appear in LSP #0 of non-pseudo-node
Level 3-8 Flooding Scoped LSPs defined in . It
MAY appear in L1 or L2 LSP #0. It MUST NOT be present in any LSP with
non-zero LSP number. If present in an LSP with non-zero LSP number it
MUST be ignored on receipt.Multiple Area Hierarchy TLVs MUST NOT be sent. In the event
multiple Area Hierarchy TLVs are received, the first such TLV in the
PDU is used. Subsequent TLVs in the same PDU MUST be ignored.Adjacency formation rules for Levels 1 and 2 are defined in and are not altered by these extensions except
where noted below.Adjacency Formation rules for Levels 3 and above are defined to
insure that adjacency support for a given level is only enabled when
there is a matching Area Identifier. Adjacency formation rules also
are defined so as to prevent interconnection of neighbors which will
connect to different areas at levels above any supported level.The checks discussed below need to be performed on receipt of an
IIH.The Area Hierarchy TLV MUST be present in a Level N
Point-to-point IS to IS hello PDU or a Level N LAN IS to IS Hello
PDU and the TLV content MUST adhere to the definition in . Beginning with the lowest level supported by the
receiving node on this circuit and including all higher levels for
which the receiver has an assigned LSAI regardless as to whether the
higher levels are supported on this circuit, the set of LSAIs
defined on the receiving node is compared against the set of LSAIs
advertised in the received TLV. A matching LSAI MUST be found for
each level.If all of the checks pass then a new adjacency is formed or an
existing adjacency is maintained.NOTE: The absence of the advertisement of an LSAI for a given
level is considered as a failure to find a matching LSAI.On a Point-to-Point circuit, a single adjacency is formed which
supports all of the levels supported by both nodes on this
circuit.On a LAN circuit, an adjacency is formed supporting only the
level specified by the PDU type.Note that (as previously specified) the set of levels advertised
MUST be contiguous.The Area Hierarchy TLV MAY appear in a Point-to-point IS to IS
hello PDU, Level 1 LAN IS to IS Hello PDU, or Level 2 LAN IS to IS
Hello PDU (PDUs specified in ). In such a
case, the neighbor may or may not support the Area Hierarchy TLV.
The following sub-sections define modified adjacency formation rules
for point-to-point and LAN circuits.If the Area Hierarchy TLV is present, then in addition to the
checks specified in the checks specified
in MUST be performed for all levels
for which the receiver has an assigned LSAI beginning with Level
2. If those checks fail an adjacency MUST NOT be formed and any
existing matching adjacency MUST transition to DOWN state.Adjacency formation MUST follow the rules defined in . If the Area Hierarchy TLV is present in the
Level 1 or Level 2 LAN IS to IS Hello PDU then the checks
specified in SHOULD be performed for
all levels for which the receiver has an assigned LSAI beginning
with Level 2. If those checks fail an error SHOULD be reported,
but the level specific adjacency is still allowed. This prevents
violation of the assumption of transitivity on the LAN in the
presence of systems which do not support the extensions defined in
this document.When forming adjacencies at Level-1 and/or Level-2, it is
possible to have a mixture of legacy nodes (which do NOT support
the extensions defined in this document) and new nodes which do
support the extensions.In Point-to-Point mode, legacy nodes will not advertise the new
Area Hierarchy TLV and will not have an assigned LSAI for Level-2.
It then becomes possible for new nodes with mismatched Area
Hierarchies to form adjacencies with legacy nodes and form an L1
or L2 area where not all new nodes have a matching Area Hierarchy.
This cannot be detected when forming adjacencies if the new nodes
are not directly connected - but it can be detected after the
adjacencies have been formed by inspecting the set of Area
Hierarchy TLVs in the level specific LSPs of all routers in the
area.Similarly in LAN mode, the transitivity requirement means that
new nodes MUST form adjacencies with all nodes connected to the
LAN even when the Area Hierarchy TLV mismatch check fails (see
). This can occur both at Level-1 and
Level-2.New nodes MUST report these inconsistencies.For levels 3-8, all link state information, PSNPs, and CSNPs are
relayed in conformance with . Additional
flooding scopes are defined for each new level, for both circuit
flooding scope and level flooding scope. Level flooding scopes are
defined for both Standard and Extended TLV formats. The list of
additional flooding scopes is:The final octet of the header of a Flooding Scoped LSP as defined in
contains Reserved/LSPDBOL/IS Type information.
This field is redefined for the new flooding scopes defined in this
document as follows:Note that the levels supported (analogous to the IS-type
information in L1 and L2 LSPs) can be obtained from the Area Hierarchy
TLV advertised in the associated LSP #0.Note that the definition of the ATT bit specified above also applies
to L2 LSPs. Previously this bit would have no meaning as does not define support for Level 3.On a broadcast network, PDUs are currently sent to the AllL1Iss or
AllL2Iss MAC addresses. We will need additional MAC addresses for Levels
3-8. AllL3ISs: MAC3AllL4ISs: MAC4AllL5ISs: MAC5AllL6ISs: MAC6AllL7ISs: MAC7AllL8ISs: MAC8When operating in Point-to-Point mode on a broadcast network
, a Level N Point-to-Point Hello PDU will be
sent. Any of the above MAC addresses could be used in this case, but it
is recommended to use the AllL3ISs MAC address.All existing Level 2 TLVs may be used in the corresponding Level 3
through Level 8 PDUs. When used in a Level 3 through Level 8 PDU, the
semantics of these TLVs will be applied to the Level of the containing
PDU. If the original semantics of the PDU was carrying a reference to
Level 1 in a Level 2 TLV, then the semantics of the TLV at level N will
be a reference to level N-1. The intent is to retain the original
semantics of the TLV at the higher level.The behavior of Level n is analogous to the behavior of Level 2.The relationship between Level n and Level n-1 is analogous to the
relationship between Level 2 and Level 1.An area at Level n has at most one parent at Level n+1.The authors would like to thank Dinesh Dutt for inspiring this
document and Huaimo Chen for his comments. The authors would also like
to thank Tony Pryzienda for his careful review and excellent
suggestions.This document makes many requests to IANA, as follows:The existing IS-IS PDU registry currently supports values 0-31.
This should be expanded to support the values 0-255. The existing
value assignments should be retained. Value 255 should be
reserved.IANA is requested to allocate values from the IS-IS PDU registry
for the following: L3-LAN-HELLO-PDU: 33 (Suggested - to be assigned by IANA)L4-LAN-HELLO-PDU: 34 (Suggested - to be assigned by IANA)L5-LAN-HELLO-PDU: 35 (Suggested - to be assigned by IANA)L6-LAN-HELLO-PDU: 36 (Suggested - to be assigned by IANA)L7-LAN-HELLO-PDU: 37 (Suggested - to be assigned by IANA)L8-LAN-HELLO-PDU: 38 (Suggested - to be assigned by IANA)Ln-P2P-HELLO-PDU: 39 (Suggested - to be assigned by IANA)IANA is requested to allocate values from the IS-IS TLV registry
for the following: Area Hierarchy: ZZZIANA is requested to allocate the following values from the IS-IS
Flooding Scope Identifier Registry.IANA is requested to allocate values from the IANA Multicast 48-bit
MAC Addresses block for the following: AllL3Iss: MAC3AllL4Iss: MAC4AllL5Iss: MAC5AllL6Iss: MAC6AllL7Iss: MAC7AllL8Iss: MAC8This document introduces no new security issues. Security of routing
within a domain is already addressed as part of the routing protocols
themselves. This document proposes no changes to those security
architectures.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)International Organization for
StandardizationThe use of additional levels requires careful interconnection of
routers which support multiple levels. Consistent association of LSAIs
is required not only for validating the connections between routers in a
level specific area but also for all levels above a given level to which
any of the routers may be connected (directly or indirectly). Failure to
do so can result in interconnecting different branches of a tree leading
to interarea loops. This leads to the requirement that all routers
advertise an LSAI for all levels regardless of whether a given router is
configured to participate in a given level or not.At first glance it may seem that it would be sufficient for each
router to advertise LSAIs only for the levels that the router is
configured to support. However, the following simple example illustrates
why this is problematic.Since Router B does not support Level 4, it chose not to
advertise any Area for Level 4. This means that neither Router A nor
Router C can tell by inspecting hellos that not all routers in Level 3
area 30 have been configured to support the same Level 4 area. It is
possible for Rtr A and Rtr C to discover the LSAIs advertised by all
routers by inspecting the Level 3 LSPs - however this requires that
Level 3 adjacencies be formed and maintained even when routing cannot be
safely performed via all adjacencies in a given area. It then needs to
be decided how routing over existing adjacencies should be limited. A
number of possibilities exist:Treat the area as if it were two partitions. In the example
Router A would be in one partition and Router C would be in another
partition. But Router B could belong to either partition.Select a winning Level 4 Area among the set of Level 4 areas
advertised in L3 LSPs and only allow leaking of routes to/from that
levelBut either of these options introduce the possibility that a
previously fully connected hierarchy becomes partially disconnected as a
result of a single configuration change on a single router and/or the
bringup of a new router.The choice made was then to require all routers suppporting the
extensions in this document to advertise an LSAI for all levels
regardless of what specific levels an individual router is configured to
support. This guarantees that any inconsistency between the intended
connectivity of a router at all levels - direct and indirect - can be
detected during exchange of hellos and therefore adjacency bringup can
always be blocked when necessary.It is desirable to be able to introduce support for a new level
without disruption. This section discusses ways to do this.Initial deployment may require only the support of one additional
level (Level 3). However, in the future increased network scale may make
introduction of an additional level (Level 4) desirable. It is suggested
that all routers be configured to advertise a single candidate LSAI for
Level 4 - for the purposes of the example let's use LSAI 44. When ready
to deploy Level 4, it is then only necessary to enable Level 4 on those
routers who will be participating in the additional level.However, perhaps at the time of deploying Level 3 the administrator
has no idea what LSAI will be used for Level 4 in the future. In such a
case a "dummy" LSAI should be configured for Level 4 on all routers -
let's use "0" in this example. In this case, what needs to be done when
ready to enable Level 4 is to go to every router (regardless of whether
it will actively participate in the new level) and configure the
intended LSAI for Level 4. If LSAI 45 is the intended Level 4 area, then
LSAI 45 is configured on each router. Each router is then advertising
two LSAIs for Level 4: (0, 45). Once this is completed, go to every
router and remove the "dummy" Level 4 LSAI (0) and the network is now
ready to have this Level 4 area enabled.In the event that support for a new level needs to be introduced and
no LSAI was ever advertised for that level, the introduction of LSAI for
the new level will cause temporary adjacency flaps as the advertisement
of the LSAI for the new level is introduced. To avoid this,
implementations would need to introduce support for temporary
disablement of the LSAI check for the new level until the configuration
of the new LSAI is complete on all nodes. Support for this transition
mode is outside the scope of this document. The need for a transition
mode can be avoided if an LSAI is configured for levels 2-8 from day
one.