Network Working Group Z. Chen
Internet-Draft X. Xu
Intended status: Standards Track Huawei Technologies
Expires: July 10, 2017 January 6, 2017
Overheads Reduction for IS-IS Enabled Spine-Leaf Networks
draft-chen-isis-sl-overheads-reduction-00
Abstract
When a Spine-Leaf topology adopts the Intermediate System to
Intermediate System (IS-IS) routing protocol, the Leaf node receives
Link State Packets (LSPs) from all the other nodes thus having the
entire routing information of the topology. This is usually
considered unnecessary and costly. This document describes a
solution to this problem by assigning different area identifiers
(AIDs) to the Leaf nodes. The solution requires that an IS-IS router
SHOULD check a Level-1 LSP's AIDs before it advertises the LSP to its
neighbor.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 10, 2017.
Chen & Xu Expires July 10, 2017 [Page 1]
Internet-Draft IS-IS Spine-Leaf Overheads Reduction January 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Solution Description . . . . . . . . . . . . . . . . . . . . 3
2.1. Area ID Assignment . . . . . . . . . . . . . . . . . . . 3
2.2. Area ID Checking . . . . . . . . . . . . . . . . . . . . 5
2.3. Default Route Advertising . . . . . . . . . . . . . . . . 6
3. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Spine-Leaf topology (a.k.a., CLOS topology) is widely used in today's
datacenter and campus networks. When the Spine-Leaf topology runs
the Intermediate System to Intermediate System (IS-IS) routing
protocol, each Leaf node will receive Link State Packets (LSPs) from
all the other nodes and have the entire routing information of the
topology. This is usually considered to be unnecessary and costly
because the Leaf node only needs to know its default gateways (i.e.,
the Spine nodes it connects to), and the LSPs generated by the other
Leaf nodes benefit nothing for it to forward traffic.
To avoid Leaf nodes from learning the unnecessary LSPs from one
another, [IS-IS-SL-Extension] proposes a new TLV of the IS-IS Hello
(IIH) PDU to differentiate Spine/Leaf nodes and LSPs generated by
Leaf nodes will be blocked at Spine nodes. Additionally, each Leaf
node sets the Spine nodes it connects to as its default gateways.
Chen & Xu Expires July 10, 2017 [Page 2]
Internet-Draft IS-IS Spine-Leaf Overheads Reduction January 2017
This document describes another solution to this problem, which needs
not to extend the IS-IS messages. In particular, it requires that
each Leaf node SHOULD be assigned with a unique area identifier (AID)
and IS-IS L1/L2 routers MUST NOT advertise Level-1 LSPs of a given
area to Level-1 routers within another area. This prevents Leaf
nodes from receiving routing information from one another, and lets
the Leaf node set the Spine nodes as its default gateways.
2. Solution Description
2.1. Area ID Assignment
+------------+ +------------+
| Spine-A | 10.10.10.0/24 | Spine-B |
| L1/L2 +----------------------+ L1/L2 |
| Area10/20 | .1 .2 | Area10/20 |
+---+--+-----+ +---+----+---+
.1 | | .1 .2 | | .1
| | 10.10.40.0/24 | |
| | +-----------------------------+ |
10.10.20.0/24 | | | | 10.10.30.0/24
| +--|-------------------------------+ |
| | 10.10.50.0/24 | |
.2 | | .1 .2 | | .2
+---+-----+--+ +-----+--+---+
| Leaf-A | | Leaf-B |
| L1 | | L1 |
| Area10 | | Area20 |
+-----+------+ +-----+------+
| |
| |
------+------- ------+-------
192.168.10.0/24 192.168.20.0/24
Figure 1: Topology Example
This section describes how to assign AIDs in the Spine-Leaf topology,
and illustrates why IS-IS routers SHOULD check the AIDs before
advertising Level-1 LSPs. As shown in Figure 1, there are two Spine
nodes (i.e., Spine-A and Spine-B) and two Leaf nodes (i.e., Leaf-A
and Leaf-B). The System IDs of Spine-A, Spine-B, Leaf-A, and Leaf-B
are 1111.1111.1111.1111.00 to 4444.4444.4444.00, respectively.
To prevent a Leaf node from learning the routing information of the
other Leaf nodes, the following configurations are required:
Chen & Xu Expires July 10, 2017 [Page 3]
Internet-Draft IS-IS Spine-Leaf Overheads Reduction January 2017
a. Leaf nodes SHOULD be configured as L1 routers and each of them
SHOULD be assigned a unique AID.
b. Spine nodes SHOULD be configured as L1/L2 routers and SHOULD be
assigned multiple AIDs with each being that of a given Leaf node
connected to it.
As a result, Leaf-A and Leaf-B in Figure 1 are configured as L1
routers and are assigned AID 10 and AID 20, respectively. Spine-A
and Spine-B are configured as L1/L2 routers and are assigned both AID
10 and AID 20.
Level-1 Link State Database (Spine-A):
+--------------------+----------+--------+--------+------+--------+-----+
|LSPID |Seq Num |Checksum|Holdtime|Length|ATT/P/OL|Area |
+--------------------+----------+--------+--------+------+--------+-----+
|1111.1111.1111.00-00|0x0000006c|0x540b |743 |124 |0/0/0 |10/20|
+--------------------+----------+--------+--------+------+--------+-----+
|2222.2222.2222.00-00|0x0000006d|0x933b |1068 |124 |0/0/0 |10/20|
+--------------------+----------+--------+--------+------+--------+-----+
|3333.3333.3333.00-00|0x0000006b|0x1815 |402 |122 |0/0/0 |10 |
+--------------------+----------+--------+--------+------+--------+-----+
|4444.4444.4444.00-00|0x0000006a|0xf543 |431 |122 |0/0/0 |20 |
+--------------------+----------+--------+--------+------+--------+-----+
Level-2 Link State Database (Spine-A):
+--------------------+----------+--------+--------+------+--------+-----+
|LSPID |Seq Num |Checksum|Holdtime|Length|ATT/P/OL|Area |
+--------------------+----------+--------+--------+------+--------+-----+
|1111.1111.1111.00-00|0x0000006f|0x682f |743 |150 |0/0/0 |10/20|
+--------------------+----------+--------+--------+------+--------+-----+
|2222.2222.2222.00-00|0x00000063|0x30eb |1068 |150 |0/0/0 |10/20|
+--------------------+----------+--------+--------+------+--------+-----+
Figure 2: Link State Database of Spine-A
Under such configurations, Leaf-A will still receives Leaf-B's LSPs
(and vice versa) even though they are in different areas. This is
because of the IS-IS definition that all routers in a specific area
SHOULD share the same Level-1 Link State Database (LSDB).
The LSDB of Spine-A is shown in Figure 2. In particular, since
Spine-A and Leaf-B are both in area 20, Spine-A will receive the LSP
4444.4444.4444.00-00 from Leaf-B and store the LSP into its Level-1
LSDB. On the other hand, since Spine-A and Leaf-A are both in area
10, Spine-A will advertise the LSP 4444.4444.4444.00-00 to Leaf-A
although Leaf-A and Leaf-B (generator of the LSP) are in different
Chen & Xu Expires July 10, 2017 [Page 4]
Internet-Draft IS-IS Spine-Leaf Overheads Reduction January 2017
areas. As a result, Leaf-A will install the route 192.168.20.0/24
into its routing table (Figure 3), even though it is an external area
route.
Leaf-A Routing Table:
+---------------+-------+---+----+-----+----------+--------------+
|Destination |Proto |Pre|Cost|Flags|NextHop |Interface |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.10.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 |
| |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.20.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/0 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.30.0/24 |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.40.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.50.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 |
+---------------+-------+---+----+-----+----------+--------------+
|192.168.10.0/24|Direct |0 |0 |D |127.0.0.1 |GEthernet0/0/0|
+---------------+-------+---+----+-----+----------+--------------+
|192.168.20.0/24|ISIS-L1|15 |30 |D |10.10.20.1|Ethernet0/0/0 |
| |ISIS-L1|15 |30 |D |10.10.40.2|Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
|127.0.0.0/8 |Direct |0 |0 |D |127.0.0.1 |InLoopBack0 |
+---------------+-------+---+----+-----+----------+--------------+
|0.0.0.0/0 |ISIS-L1|15 |10 |D |10.10.20.1|Ethernet0/0/0 |
| |ISIS-L1|15 |10 |D |10.10.40.2|Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
Figure 3: Routing Table of Leaf-A
Therefore, to avoid Level-1 LSPs of one area from being flooded into
another area, an AID checking mechanism (see Section 2.2) is needed.
2.2. Area ID Checking
Before an IS-IS router advertises a Level-1 LSP to a Level-1
neighbor, it SHOULD compare the AIDs associated with the LSP and the
AIDs associated with the neighbor. If they have at least one AID in
common, the router SHOULD advertise the LSP to the neighbor.
Otherwise, the router MUST NOT advertise the LSP to the neighbor.
For instance, as shown in Figure 1, before Spine-A advertises the LSP
1111.1111.1111.00-00 to Leaf-A, it compares the LSP's AIDs (i.e., 10
and 20) with Leaf-A's AID (i.e., 10). Since they have an AID in
common that is AID 10, Spine-A SHOULD advertise the LSP to Leaf-A.
Chen & Xu Expires July 10, 2017 [Page 5]
Internet-Draft IS-IS Spine-Leaf Overheads Reduction January 2017
On the other hand, before Spine-A advertises the LSP
4444.4444.4444.00-00 to Leaf-A, it checks their AIDs and finds that
they have no AID in common. So Spine-A MUST NOT advertise the LSP to
Leaf-A. As a result, Leaf-A would not learn the routing information
of Leaf-B, as shown in Figure 4.
Leaf-A Routing Table:
+---------------+-------+---+----+-----+----------+--------------+
|Destination |Proto |Pre|Cost|Flags|NextHop |Interface |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.10.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 |
| |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.20.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/0 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.30.0/24 |ISIS-L1|15 |20 |D |10.10.40.2|Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.40.0/24 |Direct |0 |0 |D |127.0.0.1 |Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
|10.10.50.0/24 |ISIS-L1|15 |20 |D |10.10.20.1|Ethernet0/0/0 |
+---------------+-------+---+----+-----+----------+--------------+
|192.168.10.0/24|Direct |0 |0 |D |127.0.0.1 |GEthernet0/0/0|
+---------------+-------+---+----+-----+----------+--------------+
|127.0.0.0/8 |Direct |0 |0 |D |127.0.0.1 |InLoopBack0 |
+---------------+-------+---+----+-----+----------+--------------+
|0.0.0.0/0 |ISIS-L1|15 |10 |D |10.10.20.1|Ethernet0/0/0 |
| |ISIS-L1|15 |10 |D |10.10.40.2|Ethernet0/0/1 |
+---------------+-------+---+----+-----+----------+--------------+
Figure 4: Routing Table of Leaf-A
2.3. Default Route Advertising
As defined in [RFC 1195], a L1/L2 router will indicate in its L1 LSPs
that it is "attached" by setting the ATT bits. Therefore, each Leaf
node in the example will set the Spine nodes as its default gateways
and install the corresponding default routes into its routing table,
as shown in Figure 4.
However, a specific IS-IS implementation in this case may not let the
L1/L2 router set the ATT bits, because it may speculate that the L1/
L2 router has lost connectivity to the Level-2 backbone. To solve
this problem, operators can manually configure the L1/L2 router to
advertise a default route.
Chen & Xu Expires July 10, 2017 [Page 6]
Internet-Draft IS-IS Spine-Leaf Overheads Reduction January 2017
3. Discussions
The AID checking mechanism described in this document will put little
effect on the current usage of the IS-IS protocol because of two
reasons:
a. In usual cases, an IS-IS router is assigned no more than one AID.
Therefore no LSP will be blocked and the IS-IS protocol runs as
normal.
b. An IS-IS router is assigned more than one AIDs only when 1) it is
desirable to change the AID of an area, 2) to merge two areas
into one area, or 3) to partition an area into two areas.
Apparently, the AID checking mechanism does not impact these
operations.
4. IANA Considerations
TBD.
5. Security Considerations
TBD.
6. Acknowledgements
TBD.
7. Normative References
[IS-IS-SL-Extension]
Shen, N. and S. Thyamagundalu, "IS-IS Routing for Spine-
Leaf Topology", draft-shen-isis-spine-leaf-ext-02 (work in
progress) , October 2016.
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195 , December 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Chen & Xu Expires July 10, 2017 [Page 7]
Internet-Draft IS-IS Spine-Leaf Overheads Reduction January 2017
Zhe Chen
Huawei Technologies
No. 156 Beiqing Rd
Beijing 100095
China
Email: chenzhe17@huawei.com
Xiaohu Xu
Huawei Technologies
No. 156 Beiqing Rd
Beijing 100095
China
Email: xuxiaohu@huawei.com
Chen & Xu Expires July 10, 2017 [Page 8]