draft-ietf-lsr-isis-spine-leaf-ext-00.txt   draft-ietf-lsr-isis-spine-leaf-ext-01.txt 
Networking Working Group N. Shen Networking Working Group N. Shen
Internet-Draft L. Ginsberg Internet-Draft L. Ginsberg
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: June 21, 2019 S. Thyamagundalu Expires: September 9, 2019 S. Thyamagundalu
December 18, 2018 March 8, 2019
IS-IS Routing for Spine-Leaf Topology IS-IS Routing for Spine-Leaf Topology
draft-ietf-lsr-isis-spine-leaf-ext-00 draft-ietf-lsr-isis-spine-leaf-ext-01
Abstract Abstract
This document describes a mechanism for routers and switches in a This document describes a mechanism for routers and switches in a
Spine-Leaf type topology to have non-reciprocal Intermediate System Spine-Leaf type topology to have non-reciprocal Intermediate System
to Intermediate System (IS-IS) routing relationships between the to Intermediate System (IS-IS) routing relationships between the
leafs and spines. The leaf nodes do not need to have the topology leafs and spines. The leaf nodes do not need to have the topology
information of other nodes and exact prefixes in the network. This information of other nodes and exact prefixes in the network. This
extension also has application in the Internet of Things (IoT). extension also has application in the Internet of Things (IoT).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Spine-Leaf (SL) Extension . . . . . . . . . . . . . . . . . . 4 3. Spine-Leaf (SL) Extension . . . . . . . . . . . . . . . . . . 4
3.1. Topology Examples . . . . . . . . . . . . . . . . . . . . 4 3.1. Topology Examples . . . . . . . . . . . . . . . . . . . . 4
3.2. Applicability Statement . . . . . . . . . . . . . . . . . 5 3.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
3.3. Spine-Leaf TLV . . . . . . . . . . . . . . . . . . . . . 6 3.3. Spine-Leaf TLVs . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Spine-Leaf Sub-TLVs . . . . . . . . . . . . . . . . . 7 3.3.1. Spine-Leaf TLV . . . . . . . . . . . . . . . . . . . 6
3.3.1.1. Leaf-Set Sub-TLV . . . . . . . . . . . . . . . . 7 3.3.2. Leaf-Set TLV . . . . . . . . . . . . . . . . . . . . 7
3.3.1.2. Info-Req Sub-TLV . . . . . . . . . . . . . . . . 8 3.3.2.1. Leaf-Set Sub-TLVs . . . . . . . . . . . . . . . . 7
3.3.2. Advertising IPv4/IPv6 Reachability . . . . . . . . . 8 3.3.3. Advertising IPv4/IPv6 Reachability . . . . . . . . . 8
3.3.3. Advertising Connection to RF-Leaf Node . . . . . . . 8 3.3.4. Advertising Connection to RF-Leaf Node . . . . . . . 8
3.4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Pure CLOS Topology . . . . . . . . . . . . . . . . . 10 3.4.1. Pure CLOS Topology . . . . . . . . . . . . . . . . . 10
3.5. Implementation and Operation . . . . . . . . . . . . . . 11 3.5. Implementation and Operation . . . . . . . . . . . . . . 11
3.5.1. CSNP PDU . . . . . . . . . . . . . . . . . . . . . . 11 3.5.1. CSNP PDU . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2. Overload Bit . . . . . . . . . . . . . . . . . . . . 11 3.5.2. Leaf to Leaf connection . . . . . . . . . . . . . . . 12
3.5.3. Spine Node Hostname . . . . . . . . . . . . . . . . . 11 3.5.2.1. Local traffic only . . . . . . . . . . . . . . . 12
3.5.4. IS-IS Reverse Metric . . . . . . . . . . . . . . . . 11 3.5.2.2. Transit traffic allowed . . . . . . . . . . . . . 12
3.5.5. Spine-Leaf Traffic Engineering . . . . . . . . . . . 12 3.5.3. Spine Node Hostname . . . . . . . . . . . . . . . . . 13
3.5.6. Other End-to-End Services . . . . . . . . . . . . . . 12 3.5.4. IS-IS Reverse Metric . . . . . . . . . . . . . . . . 13
3.5.7. Address Family and Topology . . . . . . . . . . . . . 12 3.5.5. Spine-Leaf Traffic Engineering . . . . . . . . . . . 13
3.5.8. Migration . . . . . . . . . . . . . . . . . . . . . . 13 3.5.6. Other End-to-End Services . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 3.5.7. Address Family and Topology . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 3.5.8. Migration . . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 14 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The IS-IS routing protocol defined by [ISO10589] has been widely The IS-IS routing protocol defined by [ISO10589] has been widely
deployed in provider networks, data centers and enterprise campus deployed in provider networks, data centers and enterprise campus
environments. In the data center and enterprise switching networks, environments. In the data center and enterprise switching networks,
a Spine-Leaf topology is commonly used. This document describes a a Spine-Leaf topology is commonly used. This document describes a
mechanism where IS-IS routing can be optimized for a Spine-Leaf mechanism where IS-IS routing can be optimized for a Spine-Leaf
topology. topology.
skipping to change at page 4, line 34 skipping to change at page 4, line 37
| | +--|-|-|--------+-|-|-----------------+ | | | | | +--|-|-|--------+-|-|-----------------+ | | |
| | | | | | +---+ | | | | | | | | | | | +---+ | | | | |
| | | | | | | +--|-|-------------------+ | | | | | | | | | +--|-|-------------------+ | |
| | | | | | | | | | +------+ +----+ | | | | | | | | | | +------+ +----+
| | | | | | | | | +--------------|----------+ | | | | | | | | | | +--------------|----------+ |
| | | | | | | | +-------------+ | | | | | | | | | | | +-------------+ | | |
| | | | | +----|--|----------------|--|--------+ | | | | | | | +----|--|----------------|--|--------+ | |
| | | | +------|--|--------------+ | | | | | | | | | +------|--|--------------+ | | | | |
| | | +------+ | | | | | | | | | | | +------+ | | | | | | | |
++--+--++ +-+-+--++ ++-+--+-+ ++-+--+-+ ++--+--++ +-+-+--++ ++-+--+-+ ++-+--+-+
| Leaf1 | | Leaf2 | ........ | LeafX | | LeafY | | Leaf1 |~~~~~~| Leaf2 | ........ | LeafX | | LeafY |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
Figure 1: A Spine-Leaf Topology Figure 1: A Spine-Leaf Topology
+---------+ +--------+ +---------+ +--------+
| Spine1 | | Spine2 | | Spine1 | | Spine2 |
+-+-+-+-+-+ +-+-+-+-++ +-+-+-+-+-+ +-+-+-+-++
| | | | | | | | | | | | | | | |
| | | +-----------------|-|-|-|-+ | | | +-----------------|-|-|-|-+
| | +------------+ | | | | | | | +------------+ | | | | |
skipping to change at page 6, line 14 skipping to change at page 6, line 14
extension and will have the complete topology and routing information extension and will have the complete topology and routing information
just like the spine nodes. To make the network even more scalable, just like the spine nodes. To make the network even more scalable,
the Core layer can operate as a level-2 IS-IS sub-domain while the the Core layer can operate as a level-2 IS-IS sub-domain while the
Spine and Leaf layers operate as stays at the level-1 IS-IS domain. Spine and Leaf layers operate as stays at the level-1 IS-IS domain.
This extension assumes the link between the spine and leaf nodes are This extension assumes the link between the spine and leaf nodes are
point-to-point, or point-to-point over LAN [RFC5309]. The links point-to-point, or point-to-point over LAN [RFC5309]. The links
connecting among the spine nodes or the links between the leaf nodes connecting among the spine nodes or the links between the leaf nodes
can be any type. can be any type.
3.3. Spine-Leaf TLV 3.3. Spine-Leaf TLVs
This extension introduces a new TLV, the Spine-Leaf TLV, which may be This extension introduces two new TLVs, the Spine-Leaf TLV and the
advertised in IS-IS Hello (IIH) PDUs, LSPs, or in Circuit Scoped Link Leaf-Set TLV. The Spine-Leaf TLV may be advertised in IS-IS Hello
State PDUs (CS-LSP) [RFC7356]. It is used by both spine and leaf (IIH) PDUs; the Leaf-Set TLV may be advertised in IS-IS Circuit
nodes in this Spine-Leaf mechanism. Scoped Link State PDUs (CS-LSP) [RFC7356]. They are used by both
spine and leaf nodes in this Spine-Leaf mechanism.
3.3.1. Spine-Leaf TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | SL Flag | | Type | Length | SL Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .. Optional Sub-TLVs
+-+-+-+-+-+-+-+-+-....
The fields of this TLV are defined as follows: The fields of this TLV are defined as follows:
Type: 1 octet Suggested value 150 (to be assigned by IANA) Type: 1 octet Suggested value 151 (to be assigned by IANA)
Length: 1 octet (2 + length of sub-TLVs). Length: 1 octet (2 + length of sub-TLVs).
SL Flags: 16 bits SL Flags: 16 bits
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tier | Reserved |T|R|L| | Tier | Reserved |T|R|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 16 skipping to change at page 7, line 18
set in the SL flag, the node indicates it is in 'Leaf- set in the SL flag, the node indicates it is in 'Leaf-
Mode'. Mode'.
R bit (0x02): Only Spine node sets this bit. If the R bit is R bit (0x02): Only Spine node sets this bit. If the R bit is
set, the node indicates to the leaf neighbor that it set, the node indicates to the leaf neighbor that it
can be used as the default route gateway. can be used as the default route gateway.
T bit (0x04): If set, the value in the "Tier" field (see T bit (0x04): If set, the value in the "Tier" field (see
above) is valid. above) is valid.
Optional Sub-TLV: Not defined in this document, for future 3.3.2. Leaf-Set TLV
extension
sub-TLVs MAY be included when the TLV is in a CS-LSP. 0 1 2 3
sub-TLVs MUST NOT be included when the TLV is in an IIH 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | .. Optional Sub-TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+....
3.3.1. Spine-Leaf Sub-TLVs The Type is suggested value of 152 (to be assigned by IANA). This
TLV and associated Sub-TLVs MAY appear in CS-LSP PDUs. Multiple TLVs
MAY be sent.
3.3.2.1. Leaf-Set Sub-TLVs
If the data center topology is a pure CLOS or Fat Tree, there are no If the data center topology is a pure CLOS or Fat Tree, there are no
link connections among the spine nodes. If we also assume there is link connections among the spine nodes. If we also assume there is
not another Core layer on top of the aggregation layer, then the not another Core layer on top of the aggregation layer, then the
traffic from one leaf node to another may have a problem if there is traffic from one leaf node to another may have a problem if there is
a link outage between a spine node and a leaf node. For instance, in a link outage between a spine node and a leaf node. For instance, in
the diagram of Figure 2, if Leaf1 sends data traffic to Leaf3 through the diagram of Figure 2, if Leaf1 sends data traffic to Leaf3 through
Spine1 node, and the Spine1-Leaf3 link is down, the data traffic will Spine1 node, and the Spine1-Leaf3 link is down, the data traffic will
be dropped on the Spine1 node. be dropped on the Spine1 node.
To address this issue spine and leaf nodes may send/request specific To address this issue spine and leaf nodes may use the sub-TLVs
reachability information via the sub-TLVs defined below. defined below to obtain more specific reachability information.
Two Spine-Leaf sub-TLVs are defined. The Leaf-Set sub-TLV and the Two Leaf-Set sub-TLVs are defined. The Leaf-Neighbors sub-TLV and
Info-Req sub-TLV. the Reachability-Req sub-TLV.
3.3.1.1. Leaf-Set Sub-TLV 3.3.2.1.1. Leaf-Neighbors Sub-TLV
This sub-TLV is used by spine nodes to optionally advertise Leaf This sub-TLV is used by spine nodes to advertise the current set of
neighbors to other Leaf nodes. The fields of this sub-TLV are Leaf neighbors to Leaf nodes. The fields of this sub-TLV are defined
defined as follows: as follows:
Type: 1 octet Suggested value 1 (to be assigned by IANA) Type: 1 octet Suggested value 1 (to be assigned by IANA)
Length: 1 octet MUST be a multiple of 6 octets. Length: 1 octet MUST be a multiple of 6 octets.
Leaf-Set: A list of IS-IS System-ID of the leaf node neighbors of Leaf-Neighbors A list of IS-IS System-IDs of the leaf node
this spine node. neighbors of this spine node.
3.3.1.2. Info-Req Sub-TLV 3.3.2.1.2. Reachability-Req Sub-TLV
This sub-TLV is used by leaf nodes to request the advertisement of This sub-TLV is used by leaf nodes to request the advertisement of
more specific prefix information from a selected spine node. The more specific prefix information from one or more selected spine
list of leaf nodes in this sub-TLV reflects the current set of leaf- node(s). The list of leaf nodes in this sub-TLV reflects the current
nodes for which not all spine node neighbors have indicated the set of leaf-nodes for which not all spine node neighbors have
presence of connectivity in the Leaf-Set sub-TLV (See indicated the presence of connectivity in the Leaf-Neighbors sub-TLV
Section 3.3.1.1). The fields of this sub-TLV are defined as follows: (See Section 3.3.2.1.1). The fields of this sub-TLV are defined as
follows:
Type: 1 octet Suggested value 2 (to be assigned by IANA) Type: 1 octet Suggested value 2 (to be assigned by IANA)
Length: 1 octet. It MUST be a multiple of 6 octets. Length: 1 octet. It MUST be a multiple of 6 octets.
Info-Req: List of IS-IS System-IDs of leaf nodes for which Leaf Nodes List of IS-IS System-IDs of leaf nodes for which
connectivity information is being requested. reachability information is being requested.
3.3.2. Advertising IPv4/IPv6 Reachability 3.3.3. Advertising IPv4/IPv6 Reachability
In cases where connectivity between a leaf node and a spine node is In cases where connectivity between a leaf node and a spine node is
down, the leaf node MAY request reachability information from a spine down, the leaf node MAY request reachability information from a spine
node as described in Section 3.3.1.2. The spine node utilizes TLVs node as described in Section 3.3.2.1.2. The spine node utilizes TLVs
135 [RFC5305] and TLVs 236 [RFC5308] to advertise this information. 135 [RFC5305] and TLVs 236 [RFC5308] to advertise this information.
These TLVs MAY be included either in IIHs or CS-LSPs [RFC7356] sent These TLVs MAY be included in CS-LSPs [RFC7356] sent from the spine
from the spine to the requesting leaf node. Sending such information to the requesting leaf node.
in IIHs has limited scale - all reachability information MUST fit
within a single IIH. It is therefore recommended that CS-LSPs be
used.
3.3.3. Advertising Connection to RF-Leaf Node 3.3.4. Advertising Connection to RF-Leaf Node
For links between Spine and Leaf Nodes on which the Spine Node has For links between Spine and Leaf Nodes on which the Spine Node has
set the R-bit and the Leaf node has set the L-bit in their respective set the R-bit and the Leaf node has set the L-bit in their respective
Spine-Leaf TLVs, spine nodes may advertise the link with a bit in the Spine-Leaf TLVs, spine nodes MAY advertise the link with a bit in the
"link-attribute" sub-TLV [RFC5029] to express this link is not used "link-attribute" sub-TLV [RFC5029] to indicate that this link is not
for LSP flooding. This information can be used by nodes computing a used for LSP flooding. This bit is named the Connect-to-RF-Leaf Node
flooding topology e.g., [DYNAMIC-FLOODING], to exclude the RF-Leaf bit. This information can be used by nodes computing a flooding
nodes from the computed flooding topology. topology e.g., [DYNAMIC-FLOODING], to exclude the RF-Leaf nodes from
the computed flooding topology.
For links between Spine and Leaf Nodes on which the Spine Node has
set the R-bit and the Leaf node has set the L-bit in their respective
Spine-Leaf TLVs, leaf nodes MAY advertise the link with a bit in the
"link-attribute" sub-TLV [RFC5029] to indicate that this link is to a
Spine Node neighbor. This bit is named the Connect-to-RF-Spine Node
bit. This information can be used by leaf nodes when deciding
whether a leaf to leaf link can be used as an alternate default path
when a leaf node has no connectivity to any spines. See
Section 3.5.2.
3.4. Mechanism 3.4. Mechanism
Leaf nodes in a spine-leaf application using this extension are Leaf nodes in a spine-leaf application using this extension are
provisioned with two attributes: provisioned with two attributes:
1)Tier level of 0. This indicates the node is a Leaf Node. The 1)Tier level of 0. This indicates the node is a Leaf Node. The
value 0 is advertised in the Tier field of Spine-Leaf TLV defined value 0 is advertised in the Tier field of Spine-Leaf TLV defined
above. above.
skipping to change at page 9, line 32 skipping to change at page 9, line 48
There is no change to the IS-IS adjacency bring-up mechanism for There is no change to the IS-IS adjacency bring-up mechanism for
Spine-Leaf peers. Spine-Leaf peers.
A spine node blocks LSP flooding to RF-Leaf adjacencies, except for A spine node blocks LSP flooding to RF-Leaf adjacencies, except for
the LSP PDUs in which the IS-IS System-ID matches the System-ID of the LSP PDUs in which the IS-IS System-ID matches the System-ID of
the RF-Leaf neighbor. This exception is needed since when the leaf the RF-Leaf neighbor. This exception is needed since when the leaf
node reboots, the spine node needs to forward to the leaf node non- node reboots, the spine node needs to forward to the leaf node non-
purged LSPs from the RF-Leaf's previous incarnation. purged LSPs from the RF-Leaf's previous incarnation.
Leaf nodes will perform IS-IS LSP flooding as normal over all of its Leaf nodes will perform IS-IS LSP flooding as normal to send the LSPs
IS-IS adjacencies, but in the case of RF-Leafs only self-originated over all of its IS-IS adjacencies. In the case of RF-Leafs only
LSPs will exist in its LSP database. self-originated LSPs will exist in its LSP database, and in the case
of leaf-leaf connections, there will be neighbor leaf nodes LSPs in
the LSP database in addition to the self-originated LSPs.
Spine nodes will receive all the LSP PDUs in the network, including Spine nodes will receive all the LSP PDUs in the network, including
all the spine nodes and leaf nodes. It will perform Shortest Path all the spine nodes and leaf nodes. It will perform Shortest Path
First (SPF) as a normal IS-IS node does. There is no change to the First (SPF) as a normal IS-IS node does. There is no change to the
route calculation and forwarding on the spine nodes. route calculation and forwarding on the spine nodes.
The LSPs of a node only floods north bound towards the upper layer The LSPs of a node only floods north bound towards the upper layer
spine nodes. The default route is generated with loadsharing also spine nodes. The default route is generated with loadsharing also
towards the upper layer spine nodes. towards the upper layer spine nodes.
RF-Leaf nodes do not have any LSP in the network except for its own. RF-Leaf nodes do not have any LSP in the network except for its own.
Therefore there is no need to perform SPF calculation on the RF-Leaf Therefore there is no need to perform SPF calculation on the RF-Leaf
node. It only needs to download the default route with the nexthops node. It only needs to download the default route with the nexthops
of those Spine Neighbors which have the 'R' bit set in the Spine-Leaf of those Spine Neighbors which have the 'R' bit set in the Spine-Leaf
TLV in IIH PDUs. IS-IS can perform equal cost or unequal cost load TLV in IIH PDUs. IS-IS can perform equal cost or unequal cost load
sharing while using the spine nodes as nexthops. The aggregated sharing while using the spine nodes as nexthops. The aggregated
metric of the outbound interface and the 'Reverse Metric' metric of the outbound interface and the 'Reverse Metric' [RFC8500]
[REVERSE-METRIC] can be used for this purpose. can be used for this purpose.
3.4.1. Pure CLOS Topology 3.4.1. Pure CLOS Topology
In a data center where the topology is pure CLOS or Fat Tree, there In a data center where the topology is pure CLOS or Fat Tree, there
is no interconnection among the spine nodes, and there is not another is no interconnection among the spine nodes, and there is not another
Core layer above the aggregation layer with reachability to the leaf Core layer above the aggregation layer with reachability to the leaf
nodes. When flooding reduction to RF-Leafs is in use, if the link nodes. When flooding reduction to RF-Leafs is in use, if the link
between a spine and a leaf goes down, there is then a possibility of between a spine and a leaf goes down, there is then a possibility of
black holing the data traffic in the network. black holing the data traffic in the network.
skipping to change at page 11, line 16 skipping to change at page 11, line 37
This negative routing is more useful between tier 0 and tier 1 spine- This negative routing is more useful between tier 0 and tier 1 spine-
leaf levels in a multi-level spine-leaf topology when the reduced leaf levels in a multi-level spine-leaf topology when the reduced
flooding extension is in use. Nodes in tiers 1 or greater may have flooding extension is in use. Nodes in tiers 1 or greater may have
much richer topology information and alternative paths. much richer topology information and alternative paths.
3.5. Implementation and Operation 3.5. Implementation and Operation
3.5.1. CSNP PDU 3.5.1. CSNP PDU
In Spine-Leaf extension, Complete Sequence Number PDU (CSNP) does not In Spine-Leaf extension, Complete Sequence Number PDUs (CSNP) do not
need to be transmitted over the Spine-Leaf link to an RF-Leaf. Some need to be transmitted over the Spine-Leaf link to an RF-Leaf. Some
IS-IS implementations send periodic CSNPs after the initial adjacency IS-IS implementations send periodic CSNPs after the initial adjacency
bring-up over a point-to-point interface. There is no need for this bring-up over a point-to-point interface. There is no need for this
optimization here since the RF-Leaf does not need to receive any optimization here since the RF-Leaf does not need to receive any
other LSPs from the network, and the only LSPs transmitted across the other LSPs from the network, and the only LSPs transmitted across the
Spine-Leaf link is the leaf node LSP. Spine-Leaf link are the leaf node LSPs.
Also in the graceful restart case[RFC5306], for the same reason, Also in the graceful restart case[RFC5306], for the same reason,
there is no need to send the CSNPs over the Spine-Leaf interface to there is no need to send the CSNPs over the Spine-Leaf interface to
an RF-Leaf. Spine nodes only need to set the SRMflag on the LSPs an RF-Leaf. Spine nodes only need to set the SRMflag on the LSPs
belonging to the RF-Leaf. belonging to the RF-Leaf that has restarted.
3.5.2. Overload Bit 3.5.2. Leaf to Leaf connection
The leaf node SHOULD set the 'overload' bit on its LSP PDU, since if Leaf to leaf node links are useful in host redundancy cases in
the spine nodes were to forward traffic not meant for the local node, switching networks. There are no flooding extensions required in
the leaf node does not have the topology information to prevent a this case. Leaf node LSPs will be exchanged over this link using the
routing/forwarding loop. normal operation of the IS-IS Update process. In the example diagram
Figure 1, Leaf1 will receive Leaf2's LSPs and Leaf2 will receive
Leaf1's LSPs. Each of the Leaf nodes will in turn flood the LSPs
they receive from their leaf node neighbor to their spine neighbors.
Prefix reachability advertisements received from the leaf neighbor
will result in the installation of more specific routes using this
local Leaf-Leaf link. SPF will be performed in this case just like
when the entire network only involves with those two IS-IS nodes.
This does not affect the normal Spine-Leaf mechanism they perform
toward the spine nodes.
Leaf to leaf connections SHOULD be limited to a single leaf neighbor.
Two modes of operation for the Leaf-Leaf link are possible and are
described in the following sub-sections.
3.5.2.1. Local traffic only
The leaf node sets the 'overload' bit in its LSP PDU so that spine
nodes will not send traffic destined for the neighboring leaf node
via its leaf node neighbor. The Leaf-Leaf link will then be used
solely for local traffic between the two Leaf Nodes.
3.5.2.2. Transit traffic allowed
If a leaf node becomes disconnected from all spine nodes, it is
possible for spine nodes to route traffic destined for the
disconnected leaf node via its leaf node neighbor. However the leaf
to leaf link SHOULD be the link of last resort. To support this mode
the leaf nodes do NOT set the overload bit in their LSPs and they
advertise a high metric for the leaf to leaf link((2^24 - 2) is
recommended). This signals to the Spine Nodes that the leaf to leaf
link may be used for transit traffic, but also insures that it will
not be used unless the spine node has no other path to a given leaf
node.
When the leaf node is disconnected from all spine nodes it MAY
install a default route towards its leaf-node neighbor in support of
return traffic to the spine nodes. When doing so the leaf should
validate that its leaf neighbor has at least one spine neighbor.
This can be done by looking for the Connect-to-RF-Spine Node bit in
the Link Attributes sub-TLVs [RFC5029] advertised in the LSPs of its
leaf node neighbor.
3.5.3. Spine Node Hostname 3.5.3. Spine Node Hostname
This extension creates a non-reciprocal relationship between the This extension creates a non-reciprocal relationship between the
spine node and leaf node. The spine node will receive leaf's LSP and spine node and leaf node. The spine node will receive leaf's LSP and
will know the leaf's hostname, but the leaf does not have spine's will know the leaf's hostname, but the leaf does not have spine's
LSP. This extension allows the Dynamic Hostname TLV [RFC5301] to be LSP. This extension allows the Dynamic Hostname TLV [RFC5301] to be
optionally included in spine's IIH PDU when sending to a 'Leaf-Peer'. optionally included in spine's IIH PDU when sending to a 'Leaf-Peer'.
This is useful in troubleshooting cases. This is useful in troubleshooting cases.
3.5.4. IS-IS Reverse Metric 3.5.4. IS-IS Reverse Metric
This metric is part of the aggregated metric for leaf's default route This metric is part of the aggregated metric for leaf's default route
installation with load sharing among the spine nodes. When a spine installation with load sharing among the spine nodes. When a spine
node is in 'overload' condition, it should use the IS-IS Reverse node is in 'overload' condition, it should use the IS-IS Reverse
Metric TLV in IIH [REVERSE-METRIC] to set this metric to maximum to Metric TLV in IIH [RFC8500] to set this metric to maximum to
discourage the leaf using it as part of the loadsharing. discourage the leaf using it as part of the loadsharing.
In some cases, certain spine nodes may have less bandwidth in link In some cases, certain spine nodes may have less bandwidth in link
provisioning or in real-time condition, and it can use this metric to provisioning or in real-time condition, and it can use this metric to
signal to the leaf nodes dynamically. signal to the leaf nodes dynamically.
In other cases, such as when the spine node loses a link to a In other cases, such as when the spine node loses a link to a
particular leaf node, although it can redirect the traffic to other particular leaf node, although it can redirect the traffic to other
spine nodes to reach that destination leaf node, but it MAY want to spine nodes to reach that destination leaf node, but it MAY want to
increase this metric value if the inter-spine connection becomes over increase this metric value if the inter-spine connection becomes over
utilized, or the latency becomes an issue. utilized, or the latency becomes an issue.
In the leaf-leaf link as a backup gateway use case, the 'Reverse
Metric' SHOULD always be set to very high value.
3.5.5. Spine-Leaf Traffic Engineering 3.5.5. Spine-Leaf Traffic Engineering
Besides using the IS-IS Reverse Metric by the spine nodes to affect Besides using the IS-IS Reverse Metric by the spine nodes to affect
the traffic pattern for leaf default gateway towards multiple spine the traffic pattern for leaf default gateway towards multiple spine
nodes, the IPv6/IPv4 Info-Advertise sub-TLVs can be selectively used nodes, the IPv6/IPv4 Info-Advertise sub-TLVs can be selectively used
by traffic engineering controllers to move data traffic around the by traffic engineering controllers to move data traffic around the
data center fabric to alleviate congestion and to reduce the latency data center fabric to alleviate congestion and to reduce the latency
of a certain class of traffic pairs. By injecting more specific leaf of a certain class of traffic pairs. By injecting more specific leaf
node prefixes, it will allow the spine nodes to attract more traffic node prefixes, it will allow the spine nodes to attract more traffic
on some underutilized links. on some underutilized links.
skipping to change at page 13, line 16 skipping to change at page 14, line 27
For this extension to be deployed in existing networks, a simple For this extension to be deployed in existing networks, a simple
migration scheme is needed. To support any leaf node in the network, migration scheme is needed. To support any leaf node in the network,
all the involved spine nodes have to be upgraded first. So the first all the involved spine nodes have to be upgraded first. So the first
step is to migrate all the involved spine nodes to support this step is to migrate all the involved spine nodes to support this
extension, then the leaf nodes can be enabled with 'Leaf-Mode' one by extension, then the leaf nodes can be enabled with 'Leaf-Mode' one by
one. No flag day is needed for the extension migration. one. No flag day is needed for the extension migration.
4. IANA Considerations 4. IANA Considerations
A new TLV codepoint is defined in this document and needs to be Two new TLV codepoint is defined in this document and needs to be
assigned by IANA from the "IS-IS TLV Codepoints" registry. It is assigned by IANA from the "IS-IS TLV Codepoints" registry. They are
referred to as the Spine-Leaf TLV and the suggested value is 150. referred to as the Spine-Leaf TLV and the suggested value is 151, and
This TLV is only to be optionally inserted either in the IIH PDU or Leaf-Set TLV and suggested value is 152. The Spine-Leaf TLV is only
in the Circuit Flooding Scoped LSP PDU. IANA is also requested to to be optionally inserted in the IIH PDU, and the Leaf-Set TLV is
maintain the SL-flag bit values in this TLV, and 0x01, 0x02 and 0x04 only to be optionally inserted in Circuit Flooding Scoped LSP PDU.
bits are defined in this document. IANA is also requested to maintain the SL-flag bit values in the
Spine-Leaf TLV, and 0x01, 0x02 and 0x04 bits are defined in this
document.
Value Name IIH LSP SNP Purge CS-LSP Value Name IIH LSP SNP Purge CS-LSP
----- --------------------- --- --- --- ----- ------- ----- --------------------- --- --- --- ----- -------
150 Spine-Leaf y y n n y 151 Spine-Leaf y n n n n
152 Leaf-Set n n n n y
This extension also proposes to have the Dynamic Hostname TLV, This document also proposes to have the Dynamic Hostname TLV, already
already assigned as code 137, to be allowed in IIH PDU. assigned as code 137, to be allowed in IIH PDU.
Value Name IIH LSP SNP Purge Value Name IIH LSP SNP Purge
----- --------------------- --- --- --- ----- ----- --------------------- --- --- --- -----
137 Dynamic Name y y n y 137 Dynamic Name y y n y
Two new sub-TLVs are defined in this document and needs to be added This documents requests IANA to create a new registry under the IS-IS
assigned by IANA from the "IS-IS TLV Codepoints". They are referred TLV Codepoints registry. The suggested name of the registry is "Sub-
to in this document as the Leaf-Set sub-TLV and the Info-Req sub-TLV. TLVs for TLV 152 (Leaf-Set TLV)". Initial contents of the new
It is suggested to have the values 1 and 2 respectively. registry is defined below:
Value Name
----- ---------------------
0 Reserved
1 Leaf Neighbors
2 Reachability Req
3-255 Unassigned
This document also requests that IANA allocate from the registry of This document also requests that IANA allocate from the registry of
link-attribute bit values for sub-TLV 19 of TLV 22 (Extended IS link-attribute two new bit values for sub-TLV 19 of TLV 22 (Extended
reachability TLV). This new bit is referred to as the "Connect to IS reachability TLV).
RF-Leaf Node" bit.
Value Name Reference Value Name Reference
----- ----- ---------- ----- ----- ----------
0x3 Connect to RF-Leaf Node This document 0x4 Connect to RF-Leaf Node This document
0x8 Connect to RF-Spine Node This document
5. Security Considerations 5. Security Considerations
Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], Security concerns for IS-IS are addressed in [ISO10589], [RFC5304],
[RFC5310], and [RFC7602]. This extension does not raise additional [RFC5310], and [RFC7602]. This extension does not raise additional
security issues. security issues.
6. Acknowledgments 6. Acknowledgments
The authors would like to thank Tony Przygienda for his discussion The authors would like to thank Tony Przygienda and Lukas Krattiger
and contributions. The authors also would like to thank Acee Lindem, for their discussion and contributions. The authors also would like
Russ White, Christian Hopps and Aijun Wang for their review and to thank Acee Lindem, Russ White, Christian Hopps and Aijun Wang for
comments of this document. their review and comments of this document.
7. References 7. References
7.1. Normative References 7.1. Normative References
[ISO10589] [ISO10589]
ISO "International Organization for Standardization", ISO "International Organization for Standardization",
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473), ISO/IEC connectionless-mode Network Service (ISO 8473), ISO/IEC
10589:2002, Second Edition.", Nov 2002. 10589:2002, Second Edition.", Nov 2002.
[REVERSE-METRIC]
Shen, N., Amante, S., and M. Abrahamsson, "IS-IS Routing
with Reverse Metric", draft-ietf-isis-reverse-metric-07
(work in progress), 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link
Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029,
September 2007, <https://www.rfc-editor.org/info/rfc5029>. September 2007, <https://www.rfc-editor.org/info/rfc5029>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008, <https://www.rfc- DOI 10.17487/RFC5120, February 2008,
editor.org/info/rfc5120>. <https://www.rfc-editor.org/info/rfc5120>.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
October 2008, <https://www.rfc-editor.org/info/rfc5301>. October 2008, <https://www.rfc-editor.org/info/rfc5301>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>. 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS", [RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
RFC 5306, DOI 10.17487/RFC5306, October 2008, RFC 5306, DOI 10.17487/RFC5306, October 2008,
<https://www.rfc-editor.org/info/rfc5306>. <https://www.rfc-editor.org/info/rfc5306>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, <https://www.rfc- DOI 10.17487/RFC5308, October 2008,
editor.org/info/rfc5308>. <https://www.rfc-editor.org/info/rfc5308>.
[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 and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>. 2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356, Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014, <https://www.rfc- DOI 10.17487/RFC7356, September 2014,
editor.org/info/rfc7356>. <https://www.rfc-editor.org/info/rfc7356>.
[RFC7602] Chunduri, U., Lu, W., Tian, A., and N. Shen, "IS-IS [RFC7602] Chunduri, U., Lu, W., Tian, A., and N. Shen, "IS-IS
Extended Sequence Number TLV", RFC 7602, Extended Sequence Number TLV", RFC 7602,
DOI 10.17487/RFC7602, July 2015, <https://www.rfc- DOI 10.17487/RFC7602, July 2015,
editor.org/info/rfc7602>. <https://www.rfc-editor.org/info/rfc7602>.
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS
Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June
2017, <https://www.rfc-editor.org/info/rfc8202>. 2017, <https://www.rfc-editor.org/info/rfc8202>.
[RFC8500] Shen, N., Amante, S., and M. Abrahamsson, "IS-IS Routing
with Reverse Metric", RFC 8500, DOI 10.17487/RFC8500,
February 2019, <https://www.rfc-editor.org/info/rfc8500>.
7.2. Informative References 7.2. Informative References
[DYNAMIC-FLOODING] [DYNAMIC-FLOODING]
Li, T., "Dynamic Flooding on Dense Graphs", draft-li- Li, T., "Dynamic Flooding on Dense Graphs", draft-li-
dynamic-flooding (work in progress), 2018. dynamic-flooding (work in progress), 2018.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, <https://www.rfc- DOI 10.17487/RFC4655, August 2006,
editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation
over LAN in Link State Routing Protocols", RFC 5309, over LAN in Link State Routing Protocols", RFC 5309,
DOI 10.17487/RFC5309, October 2008, <https://www.rfc- DOI 10.17487/RFC5309, October 2008,
editor.org/info/rfc5309>. <https://www.rfc-editor.org/info/rfc5309>.
Authors' Addresses Authors' Addresses
Naiming Shen Naiming Shen
Cisco Systems Cisco Systems
560 McCarthy Blvd. 560 McCarthy Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
US US
Email: naiming@cisco.com Email: naiming@cisco.com
 End of changes. 54 change blocks. 
131 lines changed or deleted 199 lines changed or added

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